3 ms·
> That's what I meant by "I like the way it looks." It doesn't actually work that way with a bash -c invocation (all arguments after the command string go in ar
by AdieuToLogic 1y ago
> That's what I meant by "I like the way it looks." It doesn't actually work that way with a bash -c invocation (all arguments after the command string go in argv, starting with 0), but it "fits in" with other commands that do work that way.
This is not how "--" works in the example you provided:
bash -c 'some command "$1" "$2"' -- "$var1" "$var2"
While the double-hyphens are assigned to `$0` in this example, they also serve to halt bash's interpretation of command line switches once encountered. For example:
bash -c '/bin/ps "$1"' -- "-l"
Behaves as one would expect. However:
bash -c '/bin/ps "$1"' "-l"
Will not.
- aidenn0 1y ago> While the double-hyphens are assigned to `$0` in this example, they also serve to halt bash's interpretation of command line switches once encountered. For example... That is contrary to both the bash manpage and my tests. Here's the simplest test. bash -c 'false; echo hi' -e Will print "hi" because -e is not interpreted as a command line switch despite no "--" being present (nothing after the "-c" is) while bash -e -c 'false; echo hi' Does what one expects. Or another way of putting it: bash -c '/bin/ps "$1"' foo "-l" Will work exactly the same as bash -c '/bin/ps "$1"' -- "-l" Since the "--" has zero function on this commandline except as a placeholder for argv[0].
- AdieuToLogic 1y agoYou are right. The undesired behavior I observed in my example was not related to `bash` and arguments after `-c "command string"`, but instead how `ps` on the platform I use behaves when invoked thusly: /bin/ps ''
- deleted 1y ago[deleted]