-
Notifications
You must be signed in to change notification settings - Fork 277
Add "--" pseudo-argument to end option parsing #261
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
LGTM |
cgwalters
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very minor comments, also is fine as is.
tests/test-run.sh
Outdated
| PATH="${srcd}:$PATH" $RUN -- sh -c "echo hello" > stdout | ||
| assert_file_has_content stdout hello | ||
| echo "ok - we can run with --" | ||
| PATH="${srcd}:$PATH" $RUN -- --inadvisable-executable-name-- > stdout |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's also test that passing say --chdir /enoent or something isn't parsed by bwrap.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
| @@ -0,0 +1,2 @@ | |||
| #!/bin/sh | |||
| echo hello | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about generating this dynamically rather than shipping it in the source to be nice to other tools that might process source code and not be prepared to handle such a filename? (Some license checker, sloccount, etc.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense
|
Thanks! |
This shouldn't matter unless someone wants to run an inadvisably-named
executable, but it's best-practice for commands that pass on some
of their arguments to a subsequent command.
It allows an invocation like:
bwrap --ro-bind /container / -- "$@"
to search PATH in the container for an executable named according to
"$1", even if $1 has a pathological value like
"--this-has-a-stupid-name--", or even a value that might be
deliberately trying to break bwrap's parsing like "--bind".
Fixes: containers#259
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
In addition to responding to @cgwalters' review, I edited the commit message to reflect what @AltGr said on #259 - this is not just for completeness, but also for correctness when wrapping arbitrary commands. |
|
☀️ Test successful - status-papr |
This shouldn't matter unless someone wants to run an inadvisably-named
executable, but it's best-practice for commands that pass on some
of their arguments to a subsequent command.
It allows an invocation like:
to search PATH in the container for an executable named according to
"$1", even if $1 has a pathological value like
"--this-has-a-stupid-name--", or even a value that might be
deliberately trying to break bwrap's parsing like "--bind".
(Commit message edited to reflect @AltGr's concerns on #259)