"." not recognising "--" as the end-of-options

"." not recognising "--" as the end-of-options

[Stephane Chazelas]

Hiya,

$ zsh -c '. -- --help'
zsh:.:1: no such file or directory: --
$ ARGV0=sh zsh -c '. -- --help'
zsh:.:1: no such file or directory: --

The handling of "--" is mandated by POSIX I beleive.

With ksh, pdksh, bash you have to use:

. -- "$1"

if you can't guarantee that "$1" won't start with a "-".

Unfortunately, that code doesn't work with zsh at the moment.

-- 
Stéphane

Re: "." not recognising "--" as the end-of-options

[Peter Stephenson]

On Tue, 28 Oct 2008 16:43:19 +0000
Stephane Chazelas <Stephane_Chazelas@yahoo.fr> wrote:
> $ zsh -c '. -- --help'
> zsh:.:1: no such file or directory: --
> $ ARGV0=sh zsh -c '. -- --help'
> zsh:.:1: no such file or directory: --
> 
> The handling of "--" is mandated by POSIX I beleive.
> 
> With ksh, pdksh, bash you have to use:
> 
> . -- "$1"
> 
> if you can't guarantee that "$1" won't start with a "-".
> 
> Unfortunately, that code doesn't work with zsh at the moment.

This happens with builtins that are declared not to have any options.
I've noticed it before and thought it a bit flakey but been too craven
to fix it.  We don't document option processing rules anywhere that I
can find, so sticking with the standard is the only sensible bet.  It's
probably best to change for all such builtins.

We already changed this for the functionally similar case of "exec"
when that acquired options, so this should probably be considered
unfinished business.

This has probably missed 4.3.7, although that seems to be lost in the
post at the moment.

Index: README
===================================================================
RCS file: /cvsroot/zsh/zsh/README,v
retrieving revision 1.55
diff -u -r1.55 README
--- README	26 Oct 2008 17:59:48 -0000	1.55
+++ README	28 Oct 2008 20:45:41 -0000
@@ -35,6 +35,12 @@
 This section documents incompatibilities in the shell since the 4.2
 series of releases.
 
+In previous releases of the shell, builtin commands and precommand
+modifiers that did not accept options also did not recognize the
+argument "--" as marking the end of option processing without being
+considered an argument.  This was not documented and was incompatible
+with other shells.  All such commands now handle this syntax.
+
 The configuration option --enable-lfs to enable large file support has
 been replaced by autoconf's standard --enable-largefile mechanism.
 As this is usually used whenever necessary, this won't usually
Index: Src/builtin.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v
retrieving revision 1.213
diff -u -r1.213 builtin.c
--- Src/builtin.c	18 Oct 2008 14:13:16 -0000	1.213
+++ Src/builtin.c	28 Oct 2008 20:45:43 -0000
@@ -391,6 +391,9 @@
 		if (ops.ind['-'])
 		    break;
 	    }
+	} else if (*argv && !strcmp(*argv, "--")) {
+	    ops.ind['-'] = 1;
+	    argv++;
 	}
 
 	/* handle built-in options, for overloaded handler functions */



-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: "." not recognising "--" as the end-of-options

[Stephane Chazelas]

On Tue, Oct 28, 2008 at 09:49:52PM +0000, Peter Stephenson wrote:
[...]
> > . -- "$1"
> > 
> > if you can't guarantee that "$1" won't start with a "-".
> > 
> > Unfortunately, that code doesn't work with zsh at the moment.
> 
> This happens with builtins that are declared not to have any options.
> I've noticed it before and thought it a bit flakey but been too craven
> to fix it.  We don't document option processing rules anywhere that I
> can find, so sticking with the standard is the only sensible bet.  It's
> probably best to change for all such builtins.
[...]

Thanks Peter!

note that I've filed the same bug report to ash, so I suspect
Net/FreeBSD shs are affected as well, which means we can't use
. -- "$1" portably anyway even though it's POSIX.

Cheers,
Stéphane