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.
> 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:
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:
> 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].
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:
