I use "--" because I like the way it looks but the first parameter goes in argv[0] which doesn't expand in "$@" so IMO something other than an argument should go there for clarity.
Note that bash specifically has printf %q which could alternatively be used, but I prefer to use bourne-compatible things when the bash version isn't significantly cleaner.
Double hyphens ('--') has a very specific meaning to bash and most every Unix/Linux CLI program. From getopts(1p)[0]:
Any of the following shall identify the end of options: the
first "--" argument that is not an option-argument, finding
an argument that is not an option- argument and does not
begin with a '-', or encountering an error.
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:
Note that bash specifically has printf %q which could alternatively be used, but I prefer to use bourne-compatible things when the bash version isn't significantly cleaner.