Behavior of "sh -c +c"

[Vincent Lefevre via austin-group-l at The Open Group]

On 2021-10-30 14:33:04 +0100, Stephane Chazelas via austin-group-l at The Open 
Group wrote:
> POSIX ended up mandating that bug (mandating that system("+c")
> should run an interactive shell for instance), because, like the
> the Unix libc implementors, they overlooked the issue. It is
> clearly a bug in the standard.

It doesn't mandate that system("+c") should run an interactive shell.

With dash:

$ sh -c +c
sh: 0: -c requires an argument

Ditto with bash:

$ bash -c +c
bash: -c: option requires an argument

ksh93 and mksh run an interactive shell, but I wonder whether this
should be regarded as a bug.

The sh utility has the following in SYNOPSIS:

  sh −c [−abCefhimnuvx] [−o option]... [+abCefhimnuvx] [+o option]...
  command_string [command_name [argument...]]

i.e. "+c" doesn't seem to be allowed to "cancel" the "-c".

Or perhaps "+c" can be seen as a command to run an interactive shell,
a bit like "sh -c sh", in which case I do not see any issue (the user
may also have a command "+c" that runs sh in his path, in which case
adding "--" would not change the ksh behavior).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Behavior of "sh -c +c"

[Stephane Chazelas via austin-group-l at The Open Group]

2021-11-03 17:06:07 +0100, Vincent Lefevre via austin-group-l at The Open Group:
> On 2021-10-30 14:33:04 +0100, Stephane Chazelas via austin-group-l at The 
> Open Group wrote:
> > POSIX ended up mandating that bug (mandating that system("+c")
> > should run an interactive shell for instance), because, like the
> > the Unix libc implementors, they overlooked the issue. It is
> > clearly a bug in the standard.
> 
> It doesn't mandate that system("+c") should run an interactive shell.

Yes, I agree it looks like the behaviour of sh -c +c is
unspecified.

[...]
> ksh93 and mksh run an interactive shell, but I wonder whether this
> should be regarded as a bug.
> 
> The sh utility has the following in SYNOPSIS:
> 
>   sh −c [−abCefhimnuvx] [−o option]... [+abCefhimnuvx] [+o option]...
>   command_string [command_name [argument...]]
> 
> i.e. "+c" doesn't seem to be allowed to "cancel" the "-c".
[...]

I can't see why that wouldn't be allowed as an extension.

Just like bash's

sh -c +O xpg_echo 'echo -e "\b\c"'

would be allowed as an extension (and not be required to
interpret the +O script with xpg_echo in $0 and echo -e "\b\c"
in $1).

As the -O / +O option is not among the options POSIX specifies.

-- 
Stephane

Re: Behavior of "sh -c +c"

[Vincent Lefevre via austin-group-l at The Open Group]

On 2021-11-03 16:41:40 +, Stephane Chazelas via austin-group-l at The Open 
Group wrote:
> 2021-11-03 17:06:07 +0100, Vincent Lefevre via austin-group-l at The Open 
> Group:
> [...]
> > ksh93 and mksh run an interactive shell, but I wonder whether this
> > should be regarded as a bug.
> > 
> > The sh utility has the following in SYNOPSIS:
> > 
> >   sh −c [−abCefhimnuvx] [−o option]... [+abCefhimnuvx] [+o option]...
> >   command_string [command_name [argument...]]
> > 
> > i.e. "+c" doesn't seem to be allowed to "cancel" the "-c".
> [...]
> 
> I can't see why that wouldn't be allowed as an extension.
> 
> Just like bash's
> 
> sh -c +O xpg_echo 'echo -e "\b\c"'
> 
> would be allowed as an extension (and not be required to
> interpret the +O script with xpg_echo in $0 and echo -e "\b\c"
> in $1).
> 
> As the -O / +O option is not among the options POSIX specifies.

Since options can take arguments, I think that this is OK. The
question is whether extensions may change the usage described
by the synopsis. 2.1.1 says "Additional options for standard
utilities", so this would go beyond options.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)