Hello, the "rm" POSIX spec currently says:
> If either of the files dot or dot-dot are specified as the
> basename portion of an operand (that is, the final pathname
> component) [...] rm shall write a diagnostic message to
> standard error and do nothing more with such operands.
AFAIK, that's to
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 option
On Tue, Jun 06, 2017 at 01:09:09PM +0100, Stephane CHAZELAS wrote:
> 2017-06-06 13:46:33 +0200, Joerg Schilling:
> > 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 th
2017-06-06 12:47:19 -0400, shwares...@aol.com:
> 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 ke
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 nonopt
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 fi
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1142
==
Reported By:dancol
Assigned To:
===
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 --
being
>--
> (0003753) shware_systems (reporter) - 2017-06-06 12:14
> http://austingroupbugs.net/view.php?id=1142#c3753
>--
>While this looks reasonable, the restric
If the text wasn't explicit it was to be considered an operand that gets
eaten,
not a switch option value, I'd agree that's how "sh -o -" should be
construed;
the '-' would be an illegal option value. Because it is required to be
eaten, this
leaves -o without a following value at all in the
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1142
==
Reported By:dancol
Assigned To:
===
2017-06-06 13:46:33 +0200, Joerg Schilling:
> 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
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 an idea where the first part
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,
> possibly empty of option le
14 matches
Mail list logo
