`-c` argument handling

[lloeki]

Typical of sh shells is to have a -c flag that takes all the remainder arguments as a command. This allows for stuff like bash -l -c foo "$@" to work and splat the arguments properly, including strings with spaces.

Fish does not do this:

$ fish -l -c ls -1
fish: invalid option -- 1
$ fish -l -c "ls -1"
foo
bar
baz

While this allows to put -c anywhere as an argument, this isn't quite as useful as passing actual arguments to the command to run within fish.

[ridiculousfish]

I can't get it to work:

> bash -c echo abc
(no output)
> bash -c 'echo abc'
abc

Which version of bash are you testing with? I have GNU bash, version 4.3.30

[lloeki]

OMG you're so right. Sorry. I was basing myself on the man page though:

   -c string If  the  -c  option  is  present, then commands are read from
             string.  If there are arguments after the  string,  they  are
             assigned to the positional parameters, starting with $0.

[ridiculousfish]

Heh:

> bash -c 'echo $@' 1 2 3
2 3

Like one would expect of course.

In fish:

> fish -c 'echo $argv' 1 2 3
(no output)

The 1, 2, 3 are just ignored in the presence of -c. (Otherwise they would be interpreted as filenames).

Any suggestions for what we ought to do with them?

[lloeki]

Like one would expect of course.

Dammit. Like, for once, if I actually read the thing in front of me 😭. Thanks for foolproofing me.

Any suggestions for what we ought to do with them?

Well, the thing being useful there is preserving the array-ness of the args, thus saving the caller from having to interpolate it into the command string and thus from escaping the strings, so that's definitely a useful feature to have (behaving like bash I mean), all the more than it seems pretty consistent across shells (zsh, bash, dash, even csh).

[ridiculousfish]

Oh geez, that wasn't my intent! I was mocking bash for echo $@ 1 2 3 outputting only 2 3.

[lloeki]

Ah, ok :-) 1 is set as argv[0] so it replaces the command in ps output. That can be useful too, actually.

[cbarrett]

Hm, drat, I just ran into a case where I need this. Consider the following snippet:

case ${SHELL##*/} in
    bash)	exec -l "${SHELL}" --login -c 'exec "$@"' - "$@" ;;
    ksh|sh|zsh)	exec -l "${SHELL}" -c 'exec "$@"' - "$@" ;;
    csh|tcsh)	exec -l "${SHELL}" -c 'exec $argv:q' "$@" ;;
    es|rc)	exec -l "${SHELL}" -l -c 'exec $*' "$@" ;;
esac

# Fall back on bash.
exec -l /bin/bash --login -c 'exec "$@"' - "$@"

The intention here is to re-exec underneath a login shell. (I can explain why it's doing this, I think.) Maybe I just need more coffee but I'm struggling to think of a workaround that won't blow-up on paths with spaces.

In addition to this issue, other shells' execs supports the -l option which - to the argv[0] like login(1).

[faho]

I can explain why it's doing this, I think.

@cbarrett: I'd love that explanation. Usually, you do not want to run anything under an arbitrary shell. The reason being of course that there's no guarantee that $SHELL is compatible with whatever script you have. And in fact fish will be incompatible with all but the most trivial.

I'm assuming you're trying to get "the user's environment"?

[Pysis868]

I expected this capability today, trying to use xargs but split the piped input around using several variables in a fish subshell instead of a simple -I'{}' ... '{}' strategy.

So fish just ignores arguments for -c unlike the other shells?

[floam]

So fish just ignores arguments for -c unlike the other shells?

Basically yes, except for the very particular case of exec $@... we have a hackey hack hack to make fish compatible with an XDM configuration SuSE shipped with. This actually probably would have satisfied @cbarrett.

$ fish -l -c 'exec "$@"' foo asd

... will exec asd.

[floam]

(Please, for the love of God, do not rely on this behavior. We will remove it without notice sometime.)

[faho]

(This is encapsulated in a function called fish_xdm_login_hack_hack_hack_hack)