Re: "-" operand to "sh"

Stephane CHAZELAS wrote: > Let's face it, a shell that would leave the "m" option "on" when > the user explicitly requested it to be "off" in > > sh +m > > is a bug (and in this case also a conformance bug for shells > that support UP though it may need to be

Re: "-" operand to "sh"

2017-06-08 11:39:31 +0200, Joerg Schilling: > Jilles Tjoelker wrote: > > > > While doing this, I discovered that the Burne Shell first parses the > > > command line options and later decides whether the current shell is > > > interactive. For this reason, I do not see that it

Re: "-" operand to "sh"

Jilles Tjoelker wrote: > > While doing this, I discovered that the Burne Shell first parses the > > command line options and later decides whether the current shell is > > interactive. For this reason, I do not see that it would be possible > > to use "sh +m" in a useful way. >

Re: "-" operand to "sh"

On Wed, Jun 07, 2017 at 01:52:57PM +0200, Joerg Schilling wrote: > Jilles Tjoelker wrote: > > In interactive mode, job control (-m) is enabled automatically. Some > > shells, such as FreeBSD sh, dash, mksh and heirloom-sh-050706, allow > > starting an interactive shell without

Re: "-" operand to "sh"

Jilles Tjoelker wrote: > In interactive mode, job control (-m) is enabled automatically. Some > shells, such as FreeBSD sh, dash, mksh and heirloom-sh-050706, allow > starting an interactive shell without job control using sh +m, while > other shells, such as bash and ksh93, do

Re: "-" operand to "sh"

Jilles Tjoelker wrote: > In interactive mode, job control (-m) is enabled automatically. Some This is true for ksh, but not required by POSIX. > shells, such as FreeBSD sh, dash, mksh and heirloom-sh-050706, allow You are right for FreeBSD sh, dash and mksh, but the beirloom

Re: "-" operand to "sh"

2017-06-06 23:04:43 +0200, Jilles Tjoelker: [...] > > Yes, you're right, it looks like the "-" in: > > > sh +u-e > > > is just ignored (or everything is ignored for all I can tell > > with testing as there's nothing that can be turned off here). > > > More generally, given that there's no

Re: "-" operand to "sh"

I'm not against, as long as it doesn't reopen the trapdoor issue, but think it would have to be explicit the option listing function, -o or +o without value, is not supported by sh, just set; including 'sh -o;' and 'sh +o;' forms to keep it simple. This addresses the ambiguity that -o

Re: "-" operand to "sh"

2017-06-06 14:04:39 +0100, Stephane Chazelas: > OK, going forward, to fix the spec, would we be in agreement > that the spec should guarantee this: > > In: > > sh - > > Where can be any number argument starting with -, +, > being "--", "-" or not. > > Those would be taken as operands (the

Re: "-" operand to "sh"

OK, going forward, to fix the spec, would we be in agreement that the spec should guarantee this: In: sh - Where can be any number argument starting with -, +, being "--", "-" or not. Those would be taken as operands (the first being the script name, the rest its arguments) sh --

Re: "-" operand to "sh"

Stephane CHAZELAS wrote: > I don't think it's that as, in "sh -o -", the - would be an > argument to "-o" (and unspecified as "-" is not one of the POSIX > option names). ksh93 and bosh start an interractive shell that first does "set -o" > I think I have

Re: "-" operand to "sh"

Stephane Chazelas wrote: > AFAICT the historical reason for "-" to also be the > end-of-option marker was that in the Bourne shell, options were > only considered in the first argument if it started with "-" > (and later, "+" as well). What follows the "-" is a list,

Re: "-" operand to "sh"

2017-06-04 08:45:33 +0700, Robert Elz: [...] > | The awk (or sed) case is more broken though. > | Your awk script can't take options or at least not options also > > It was never intended to be a panacea - just a convenience to allow > simple scripts (whose name is known, after all, the

Re: "-" operand to "sh"

Date:Sat, 3 Jun 2017 23:28:24 +0100 From:Stephane CHAZELAS Message-ID: <20170603222824.gc13...@chaz.gmail.com> | If the point was to be "safe"/"pedantic" and allow the script to | be called by any name I see no particular advantage

Re: "-" operand to "sh"

2017-06-04 04:49:29 +0700, Robert Elz: [...] >| which btw means that things like "#! /bin/sh -ue" are no longer safe > > Does anyone really ever do that, rather than > > #! /bin/sh > set -ue Well #! /bin/sh - set -ue If the point was to be "safe"/"pedantic" and allow the

Re: "-" operand to "sh"

Date:Sat, 3 Jun 2017 21:07:10 +0100 From:Stephane CHAZELAS Message-ID: <20170603200710.gb13...@chaz.gmail.com> | Yes, that's it. Looking at the source and testing with a PDP11 | emulator, the initial version of the Bourne shell in

Re: "-" operand to "sh"

2017-06-03 20:39:24 +0100, Stephane CHAZELAS: [...] > In ksh, as I just found out > > set - > > resets the xtrace and verbose options and marks the end of > option. That part is documented. That's probably for > compatibility with the Bourne shell as Solaris 10's /bin/sh > seems to do it (not

Re: "-" operand to "sh"

2017-06-03 10:53:58 -0400, shwares...@aol.com: > I believe the purpose of this relates to when the -o option is specified > it provides a way to use the no operand form to list values set from the > environment at startup, so sh -o - ; or sh -o ; behaves like set -o ; but > still permits

Re: "-" operand to "sh"

I believe the purpose of this relates to when the -o option is specified it provides a way to use the no operand form to list values set from the environment at startup, so sh -o - ; or sh -o ; behaves like set -o ; but still permits something like sh -co - verbose -- arg1 ; to treat

Re: "-" operand to "sh"

2017-06-02 17:18:27 +0100, Geoff Clare: [...] > > or mean stdin (in which case I'd expect "sh - -" to also be a > > problem)? I can't find any. > > I don't think treating '-' as stdin would have been a consideration, > but we need to keep that in mind when we come up with new wording, so > as not

Re: "-" operand to "sh"

Stephane Chazelas wrote, on 02 Jun 2017: > > 2017-06-02 16:33:03 +0100, Geoff Clare: > [...] > > I'm fairly sure the intention is that only: > > > > sh [options]... -- - [operands]... > > > > is undefined, but it's been badly worded and thus also applies to other >

Re: "-" operand to "sh"

Stephane Chazelas wrote, on 02 Jun 2017: > > Hi, > > http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/utilities/sh.html > the "sh" utility > > has: > > > The following operands shall be supported: > > > > - > > A single shall be