- with a link to it in the observability page.
- documents the default behavior and add a link to the GA developer guides
Signed-off-by: r.bideau <7304827+rbideau@users.noreply.github.com>
Piping find to xargs is dangerous as xargs will interpret any characters
defined in $IFS (Input Field Separator), usually <space><tab><newline>,
as separators in its input. This might lead to unintented operations
on files if any of the input to xargs containts any of the characters
defined in $IFS, most often this happens if a file contains a space in
its name. The safest way to execute a find | xargs is to force find to
separate its output with null characters and tell xargs to read null
characters as the delimiter AND also tell xargs to put the argument to
the command its supposed to run in quotation marks:
`find ... -print0 | xargs -I {} -0 rm -rf "{}"`
When running with GNU find you most likely also want to add
--no-run-if-empty or -r for short:
`find ... -print0 | xargs -I {} -0 --no-run-if-empty rm -rf "{}"`
This stops the invocation of xargs if there is no input on stdin, this
is however not portable and will break on BSD/macOS, the portability is
not a concern in this case though as the find | xargs happens in docker.
As you can see this gets unwieldly fast and despite using every
precaution, it's still not safe. When xargs is run with -0 to treat null
characters as the delimiter for its input and a file has a null
character in its name, xargs will treat the null character in the file
name as a delimiter and xargs will exhibit the same behaviour as it did
with spaces in file names.
Ahhh, isn't Unix wonderful? Loose APIs defined as untyped strings...
There is a salvation though! Most find xargs pipes are unnecessary and
can be replaced with built in functionality in find, the -exec flag.
Now, -exec comes in 2 flavours, one that is terminated with \; (the most
commonly used) and one terminated with \+ (the one most people actually
want to use). \; spawns a new invocation per found entry, thus creating
some process creation overhead. \+ instead concatenates the found
entries as arguments to the program we want to run, resulting in less
overhead and usually a faster execution.
Since find is smart enough to be aware of what constitutes an entry
(i.e it doesn't treat the entries as just a bunch of random strings to
read from stdin) it makes the whole invocation of the program, rm in
this case, safe even if it contains characters defines in $IFS or null
characters.
And with this overly elaborate commit message I bring you this 1 line
change.
* 'master' of github.com:backstage/backstage: (118 commits)
cli: Fix handling of dynamic imports in esm.js files
minor typo in migration
chore(deps): bump archiver from 5.1.0 to 5.2.0
dockerfile: mention build-image command
Apply suggestions from code review
update backend Dockerfile to use config example and fix comment
docs: add full docker deployment docs
chore: fix code review
chore: fixing syntax
docs: fixing custom implementations of utitiy apis
a small start to the integrations section of the config
TechDocs: Add changeset about Docker permission fix
Updated unit tests for the new UI
TechDocs: Pass user and group ID when invoking docker container
Replace logging erro and return undefined for a throw new Error
@types/react 16 not 17
Use a more strict type for `variant` of cards
docs(TechDocs): Add more context with AWS docs hyperlinks
Added missing dep on @types/react
Removed unused import
...
Tim