Re: Bug or feature?

Re: Bug or feature?

[Peter Stephenson]

> > ii  zsh            3.1.6.pws21-1  A shell with lots of features.
> 
> Agreed :-)
> 
> That's pretty old. Could you install at least 3.1.9? In any case, I presume i
> t
> was a bug, since it works in current version.

I don't know if it's that simple, but I don't know if it isn't either.
We've got an old 3.1.6-dev-19 here and it works there, too.  But there was
no such version as 3.1.6.pws21 since I'd switched to using dev by then.  So
I don't know what this version is.  (It would be helpful if people
indicated the local part of their version numbers like Mandrake do by
sticking `mdk' at the point where their part of the number starts.)  I can
only guess it's a really old 3.1.6 and the 21 means something different.  I
know there were bugs with exit traps way back when (though probably
pre-3.1.6).  I'd certainly like to know if it's there with the latest
version.

-- 
Peter Stephenson <pws@csr.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: Bug or feature?

[Bart Schaefer]

On Jul 28,  1:40pm, Peter Stephenson wrote:
}
} > > ii  zsh            3.1.6.pws21-1  A shell with lots of features.
} > 
} > That's pretty old. Could you install at least 3.1.9? In any case, I
} > presume it was a bug, since it works in current version.
} 
} I don't know if it's that simple, but I don't know if it isn't either.
} We've got an old 3.1.6-dev-19 here and it works there, too.  But there was
} no such version as 3.1.6.pws21 since I'd switched to using dev by then.

We could find out for sure if Juhapekka would run `echo $ZSH_VERSION'.  The
Debian package number is only of interest in figuring out if they made a
change that broke something.

On Jul 28,  3:51pm, Juhapekka Tolvanen wrote:
}
} Well, Potato is frozen state right now and it will go to stable state very
} soon. No single package in stable Debian distribution is allowed to have so
} called release critical bugs. And that means, that zsh provided with Potato
} has no release critical bugs.

It means no package in Potato has a release-critical bug that the Debian
team knows about.  Not quite the same thing.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Bug or feature?

[Juhapekka Tolvanen]

On Fri, 28 Jul 2000, Bart Schaefer wrote:

> On Jul 28,  1:40pm, Peter Stephenson wrote:
> }
> } > > ii  zsh            3.1.6.pws21-1  A shell with lots of features.
> } > 
> } > That's pretty old. Could you install at least 3.1.9? In any case, I
> } > presume it was a bug, since it works in current version.
> } 
> } I don't know if it's that simple, but I don't know if it isn't either.
> } We've got an old 3.1.6-dev-19 here and it works there, too.  But there was
> } no such version as 3.1.6.pws21 since I'd switched to using dev by then.
 
> We could find out for sure if Juhapekka would run `echo $ZSH_VERSION'.  The
> Debian package number is only of interest in figuring out if they made a
> change that broke something.

juhtolv@heresy : /home/juhtolv
% echo $ZSH_VERSION                                                7717 | pts/5
3.1.6-dev-21
juhtolv@heresy : /home/juhtolv
% zsh --version                                                    7718 | pts/5
juhtolv@heresy : /home/juhtolv
%                                                                  7713 | pts/5

Whatta fsck??? Grrrr.....

http://www.math.fu-berlin.de/user/guckes/version/
 
> On Jul 28,  3:51pm, Juhapekka Tolvanen wrote:

> } Well, Potato is frozen state right now and it will go to stable state very
> } soon. No single package in stable Debian distribution is allowed to have so
> } called release critical bugs. And that means, that zsh provided with Potato
> } has no release critical bugs.
 
> It means no package in Potato has a release-critical bug that the Debian
> team knows about.  Not quite the same thing.
 
I don't think, they will consider that bug "release critical". AFAIK
"critical" and "grave" bugs are considered "release critical bugs". If I will
send a bug report and put "grave" to Severity:-field, I think I'll be flamed
by that Debian developer, that maintains Debian package of zsh.

http://www.debian.org/Bugs/Reporting

http://www.debian.org/Bugs/Developer#severities

critical 
    makes unrelated software on the system (or the whole system) break, or
causes serious data loss, or introduces a security hole on systems where you
install the package. 

grave 
    makes the package in question unuseable or mostly so, or causes data
loss, or introduces a security hole allowing access to the accounts of users
who use the package. 

important 
    any other bug which makes the package unsuitable for release. 

normal 
    the default value, for normal bugs. 

wishlist 
    for any feature request, and also for any bugs that are very difficult
to fix due to major design considerations.  

fixed 
    for bugs that are fixed but should not yet be closed. Bugs fixed by
non-maintainer-uploads have their severity set to fixed. 


-- 
Juhapekka "naula" Tolvanen * U of Jyväskylä * juhtolv@st.jyu.fi
http://www.cc.jyu.fi/~juhtolv/ * * "STRAIGHT BUT NOT NARROW !!" 
---------------------------------------------------------------
"if i was twice the man i could be, i'd still be half of what
you need"                                       Nine Inch Nails

Re: Bug or feature?

[Bart Schaefer]

On Jul 28,  7:30pm, Juhapekka Tolvanen wrote:
}
} % zsh --version

Hmm, I'm a little surprised that zsh silently ignored that.  I believe
it's treating it the same as `--' (end of options).  Zsh is not a GNU
package and doesn't understand any "long options".

} http://www.math.fu-berlin.de/user/guckes/version/

Sven's a good guy, but I think he's misguided in this case.  (It also
hadn't stopped him from being a zsh user, last time I talked to him.)

Furthermore, zsh attempts to give a reasonable impersonation of a number
of older standard shells, none of which would do what Sven wants when
given --version as an argument.

I also note:

zagzig[265] bash --version
bash: --: bad option

Given that `--' is a perfectly good option on its own, it's pretty clear
that bash is treating `--version' as `-' followed by eight individual
single-letter options.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Bug or feature?

[Juhapekka Tolvanen]

On Fri, 28 Jul 2000, Bart Schaefer wrote:

> On Jul 28,  7:30pm, Juhapekka Tolvanen wrote:

> } % zsh --version
 
> Hmm, I'm a little surprised that zsh silently ignored that.  I believe
> it's treating it the same as `--' (end of options).  Zsh is not a GNU
> package and doesn't understand any "long options".

Is it too much work to teach zsh to understand long-options?
 
How about adding some single-letter option, that makes zsh to output its
version-number and then exit succesfully? -v,  -V, -r and -R are already
reserved, though.

> I also note:
> 
> zagzig[265] bash --version
> bash: --: bad option

juhtolv@heresy : /home/juhtolv
% bash --version                                                   7720 | pts/5
GNU bash, version 2.03.0(1)-release (i386-pc-linux-gnu)
Copyright 1998 Free Software Foundation, Inc.

Which version of bash you have? BTW In Red Hat Linux bash version 2.0.* is
in package bash2.

-- 
Juhapekka "naula" Tolvanen * U of Jyväskylä * juhtolv@st.jyu.fi
http://www.cc.jyu.fi/~juhtolv/ * * "STRAIGHT BUT NOT NARROW !!" 
---------------------------------------------------------------
"if i was twice the man i could be, i'd still be half of what
you need"                                       Nine Inch Nails

Re: Bug or feature?

[Bart Schaefer]

On Jul 28,  8:45pm, Juhapekka Tolvanen wrote:
}
} Is it too much work to teach zsh to understand long-options?

The whole option system is pretty tightly tied to single-letter option
representation (both for shell options and for switches of builtins).
The best we could do is some kind of one-to-one translation.
 
} Which version of bash you have?

I don't know, it won't tell me.  (Grin)



Sorry, couldn't resist.  BASH_VERSION says 1.14.7(1).

} BTW In Red Hat Linux bash version 2.0.* is in package bash2.

Only if you have a much newer version of Red Hat than I do.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Bug or feature?

[Trond Eivind Glomsrød]

"Bart Schaefer" <schaefer@candle.brasslantern.com> writes:

> } BTW In Red Hat Linux bash version 2.0.* is in package bash2.
> 
> Only if you have a much newer version of Red Hat than I do.

That's not a recent change - it's been that way for some time 
(all 6.x)

This has since been changed, and in Rawhide you'll find /bin/bash
is bash 2.
-- 
Trond Eivind Glomsrød
Red Hat, Inc.

PATCH (?): GNU-style long options for zsh

[Bart Schaefer]

On Jul 28,  8:45pm, Juhapekka Tolvanen wrote:
}
} Is it too much work to teach zsh to understand long-options?

Actually, it wasn't hard at all, for the shell itself (I'm not going to
touch the builtin command option parser).  It was fairly simple to make
`--blahblahblah' mean the same as `-o blahblahblah', and then I just
special-cased `--version'.

(Normally I wouldn't use a goto, but given there was another already ...)

This patch is not committed, pending a more thorough commentary from the
rest of zsh-workers.  The whole parseargs() loop could probably be written
better than it is.  Some things of note that result from code that I did
NOT change:

Zsh accepts `-opts-junk' where "opts" are any valid option letters and
"junk" gets ignored.  Thus `--sh-option-letters' and `-sh-option-letters'
mean significantly different things ....

Zsh accepts `+-' and `+b' as end of options; this is necessary for `+b'
but not for `+-' (and could be changed by moving the `action' test in the
patch up one `if' level).  Also, therefore, `+opts-junk' turns off "opts"
and ingores "junk".

Index: Src/init.c
===================================================================
@@ -34,6 +34,8 @@
 
 #include "init.pro"
 
+#include "version.h"
+
 /**/
 int noexitct = 0;
 
@@ -207,13 +209,15 @@
     while (*argv && (**argv == '-' || **argv == '+')) {
 	char *args = *argv;
 	action = (**argv == '-');
-	if(!argv[0][1])
+	if (!argv[0][1])
 	    *argv = "--";
 	while (*++*argv) {
 	    /* The pseudo-option `--' signifies the end of options. *
 	     * `-b' does too, csh-style, unless we're emulating a   *
 	     * Bourne style shell.                                  */
 	    if (**argv == '-' || (!bourne && **argv == 'b')) {
+		if (action && argv[0] == &args[1] && **argv == '-' && *++*argv)
+		    goto longoptions;
 		argv++;
 		goto doneoptions;
 	    }
@@ -230,7 +234,12 @@
 		    zerr("string expected after -o", NULL, 0);
 		    exit(1);
 		}
-		if(!(optno = optlookup(*argv)))
+	    longoptions:
+		if (!strcmp(*argv, "version")) {
+		    fprintf(stderr, "zsh %s (%s-%s-%s)\n",
+			    ZSH_VERSION, MACHTYPE, VENDOR, OSTYPE);
+		    exit(0);
+		} else if (!(optno = optlookup(*argv)))
 		    zerr("no such option: %s", *argv, 0);
 		else if (optno == RESTRICTED)
 		    restricted = action;

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

PATCH: Re: GNU-style long options for zsh

[zefram]

The patch below is a modified version of Bart's long options patch.
Things that have changed from Bart's version:

1.

Bart wrote:
>Zsh accepts `-opts-junk' where "opts" are any valid option letters and
>"junk" gets ignored.  Thus `--sh-option-letters' and `-sh-option-letters'
>mean significantly different things ....

This always annoyed me about zsh, and other programs that parse options
that way.  I've fixed that such that `zsh -sh-word-split' (for example)
is an error.  An error seems a much more appropriate response than
ignoring the extra letters.

2. Specifying an invalid option name on the command line causes zsh
to exit, rather than continuing with an error message.  This makes it
consistent with the handling of single-letter option names.  It also
fixes a bug probably caused by using zerr() rather than zwarn(): do
"zsh -o wibble" with an unpatched zsh and look at $SHLVL.

3. "-" characters are permitted in GNU-style long option names --
they get transformed into "_" characters -- so that the usual
style "--sh-word-split" is permitted (Bart's version required
"--sh_word_split").

4. Options can be turned off with "+-option-name" just like "+o
option_name".

5. Fixed a dependency: init.o now depends on version.h.

6. Moved the "--version" special casing so that "-o version" *doesn't*
work.

7. Added handling of "--help"; it lists the supported options (with
the appropriate set of option letters), so it'll provide the necessary
information to a completion function when we write one.

8. "--version" and "--help" output goes to stdout, which seems to be
standard, rather than stderr.

9. Documented the long options.

10. Corrected the documentation about -c.  (The command argument is
what would otherwise be the first positional argument, *not* an extra
argument after the option.)

11.

>Zsh accepts `+-' and `+b' as end of options

I left this intact, seeing no reason to change it.  But I documented it.

-zefram

Index: Doc/Zsh/invoke.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/invoke.yo,v
retrieving revision 1.2
diff -c -r1.2 invoke.yo
*** Doc/Zsh/invoke.yo	2000/05/22 15:01:35	1.2
--- Doc/Zsh/invoke.yo	2000/07/30 16:23:24
***************
*** 4,37 ****
  sect(Invocation Options)
  cindex(flags, shell)
  cindex(shell flags)
! If the tt(-s) flag is not present and an argument is given,
! the first argument is taken to be the pathname of a script to
! execute.  The remaining arguments are assigned to the positional
! parameters.  The following flags are interpreted by the shell
! when invoked:
  
  startitem()
! item(tt(-c) var(string))(
! Read commands from var(string).
  )
  item(tt(-i))(
  Force shell to be interactive.
  )
  item(tt(-s))(
! Read command from the standard input.
  )
  enditem()
  
  For further options, which are common to invocation and the tt(set)
  builtin, see
  ifzman(zmanref(zshoptions))\
  ifnzman(noderef(Options))\
! .  Flags may be specified by name using the tt(-o) option.  For example,
  
  example(zsh -x -o shwordsplit scr)
  
  runs the script tt(scr), setting the tt(XTRACE) option by the corresponding
  letter `tt(-x)' and the tt(SH_WORD_SPLIT) option by name.
  
  startmenu()
  menu(Compatibility)
--- 4,79 ----
  sect(Invocation Options)
  cindex(flags, shell)
  cindex(shell flags)
! The following flags are interpreted by the shell when invoked to determine
! where the shell will read commands from:
  
  startitem()
! item(tt(-c))(
! Take the first argument as a command to execute, rather than reading commands
! from a script or standard input.  If any further arguments are given, the
! first one is assigned to tt($0), rather than being used as a positional
! parameter.
  )
  item(tt(-i))(
  Force shell to be interactive.
  )
  item(tt(-s))(
! Force shell to read commands from the standard input.
! If the tt(-s) flag is not present and an argument is given,
! the first argument is taken to be the pathname of a script to
! execute.
  )
  enditem()
  
+ After the first one or two arguments have been appropriated as described above,
+ the remaining arguments are assigned to the positional parameters.
+ 
  For further options, which are common to invocation and the tt(set)
  builtin, see
  ifzman(zmanref(zshoptions))\
  ifnzman(noderef(Options))\
! .
  
+ Options may be specified by name using the tt(-o) option.  tt(-o) acts like
+ a single-letter option, but takes a following string as the option name.
+ For example,
+ 
  example(zsh -x -o shwordsplit scr)
  
  runs the script tt(scr), setting the tt(XTRACE) option by the corresponding
  letter `tt(-x)' and the tt(SH_WORD_SPLIT) option by name.
+ Options may be turned em(off) by name by using tt(PLUS()o) instead of tt(-o).
+ tt(-o) can be stacked up with preceding single-letter options, so for example
+ `tt(-xo shwordsplit)' or `tt(-xoshwordsplit)' is equivalent to
+ `tt(-x -o shwordsplit)'.
+ 
+ Options may also be specified by name in GNU long option style,
+ `tt(--)var(option-name)'.  When this is done, `tt(-)' characters in the
+ option name are permitted: they are translated into `tt(_)', and thus ignored.
+ So, for example, `tt(zsh --sh-word-split)' invokes zsh with the
+ tt(SH_WORD_SPLIT) option turned on.  Like other option syntaxes, options can
+ be turned off by replacing the initial `tt(-)' with a `tt(PLUS())'; thus
+ `tt(+-sh-word-split)' is equivalent to `tt(--no-sh-word-split)'.
+ Unlike other option syntaxes, GNU-style long options cannot be stacked with
+ any other options, so for example `tt(-x-shwordsplit)' is an error,
+ rather than being treated like `tt(-x --shwordsplit)'.
+ 
+ The special GNU-style option `tt(--version)' is handled; it sends to standard
+ output the shell's version information, then exits successfully.
+ `tt(--help)' is also handled; it sends to standard output a list of options
+ that can be used when invoking the shell, then exits successfully.
+ 
+ Option processing may be finished, allowing following arguments that start with
+ `tt(-)' or `tt(PLUS())' to be treated as normal arguments, in two ways.
+ Firstly, a lone `tt(-)' (or `tt(PLUS())') as an argument by itself ends option
+ processing.  Secondly, a special option `tt(--)' (or `tt(PLUS()-)'), which may
+ be specified on its own (which is the standard POSIX usage) or may be stacked
+ with preceding options (so `tt(-x-)' is equivalent to `tt(-x --)').  Options
+ are not permitted to be stacked after `tt(--)' (so `tt(-x-f)' is an error),
+ but note the GNU-style option form discussed above, where `tt(--shwordsplit)'
+ is permitted and does not end option processing.
+ Except when emulating sh or ksh, the option `tt(-b)' is treated the same way
+ as `tt(--)' for the purpose of ending option processing.
  
  startmenu()
  menu(Compatibility)
Index: Src/init.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/init.c,v
retrieving revision 1.7
diff -c -r1.7 init.c
*** Src/init.c	2000/07/19 21:09:40	1.7
--- Src/init.c	2000/07/30 16:23:24
***************
*** 34,39 ****
--- 34,41 ----
  
  #include "init.pro"
  
+ #include "version.h"
+ 
  /**/
  int noexitct = 0;
  
***************
*** 207,221 ****
      while (*argv && (**argv == '-' || **argv == '+')) {
  	char *args = *argv;
  	action = (**argv == '-');
! 	if(!argv[0][1])
  	    *argv = "--";
  	while (*++*argv) {
  	    /* The pseudo-option `--' signifies the end of options. *
  	     * `-b' does too, csh-style, unless we're emulating a   *
  	     * Bourne style shell.                                  */
  	    if (**argv == '-' || (!bourne && **argv == 'b')) {
! 		argv++;
! 		goto doneoptions;
  	    }
  
  	    if (**argv == 'c') {         /* -c command */
--- 209,243 ----
      while (*argv && (**argv == '-' || **argv == '+')) {
  	char *args = *argv;
  	action = (**argv == '-');
! 	if (!argv[0][1])
  	    *argv = "--";
  	while (*++*argv) {
  	    /* The pseudo-option `--' signifies the end of options. *
  	     * `-b' does too, csh-style, unless we're emulating a   *
  	     * Bourne style shell.                                  */
  	    if (**argv == '-' || (!bourne && **argv == 'b')) {
! 		if(!argv[0][1]) {
! 		    argv++;
! 		    goto doneoptions;
! 		}
! 		if(*argv != args+1 || **argv != '-')
! 		    goto badoptionstring;
! 		/* GNU-style long options */
! 		++*argv;
! 		if (!strcmp(*argv, "version")) {
! 		    printf("zsh %s (%s-%s-%s)\n",
! 			    ZSH_VERSION, MACHTYPE, VENDOR, OSTYPE);
! 		    exit(0);
! 		}
! 		if (!strcmp(*argv, "help")) {
! 		    printhelp();
! 		    exit(0);
! 		}
! 		/* `-' characters are allowed in long options */
! 		for(args = *argv; *args; args++)
! 		    if(*args == '-')
! 			*args = '_';
! 		goto longoptions;
  	    }
  
  	    if (**argv == 'c') {         /* -c command */
***************
*** 230,238 ****
  		    zerr("string expected after -o", NULL, 0);
  		    exit(1);
  		}
! 		if(!(optno = optlookup(*argv)))
  		    zerr("no such option: %s", *argv, 0);
! 		else if (optno == RESTRICTED)
  		    restricted = action;
  		else
  		    dosetopt(optno, action, 1);
--- 252,262 ----
  		    zerr("string expected after -o", NULL, 0);
  		    exit(1);
  		}
! 	    longoptions:
! 		if (!(optno = optlookup(*argv))) {
  		    zerr("no such option: %s", *argv, 0);
! 		    exit(1);
! 		} else if (optno == RESTRICTED)
  		    restricted = action;
  		else
  		    dosetopt(optno, action, 1);
***************
*** 241,246 ****
--- 265,271 ----
  		/* zsh's typtab not yet set, have to use ctype */
  		while (*++*argv)
  		    if (!isspace(STOUC(**argv))) {
+ 		    badoptionstring:
  			zerr("bad option string: `%s'", args, 0);
  			exit(1);
  		    }
***************
*** 292,297 ****
--- 317,343 ----
      argzero = ztrdup(argzero);
  }
  
+ /**/
+ static void
+ printhelp(void)
+ {
+     int bourne = (emulation == EMULATE_KSH || emulation == EMULATE_SH);
+ 
+     printf("Usage: %s [<options>] [<argument> ...]\n", argzero);
+     printf("\nSpecial options:\n");
+     printf("  --help     show this message, then exit\n");
+     printf("  --version  show zsh version number, then exit\n");
+     if(!bourne)
+ 	printf("  -b         end option processing, like --\n");
+     printf("  -c         take first argument as a command to execute\n");
+     printf("  -o OPTION  set an option by name (see below)\n");
+     printf("\nNormal options are named.  An option may be turned on by\n");
+     printf("`-o OPTION', `--OPTION', `+o no_OPTION' or `+-no-OPTION'.  An\n");
+     printf("option may be turned off by `-o no_OPTION', `--no-OPTION',\n");
+     printf("`+o OPTION' or `+-OPTION'.  Options are listed below only in\n");
+     printf("`--OPTION' or `--no-OPTION' form.\n");
+     printoptionlist();
+ }
  
  /**/
  mod_export void
Index: Src/options.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/options.c,v
retrieving revision 1.4
diff -c -r1.4 options.c
*** Src/options.c	2000/05/15 18:48:21	1.4
--- Src/options.c	2000/07/30 16:23:24
***************
*** 694,696 ****
--- 694,741 ----
      *val = '\0';
      return buf;
  }
+ 
+ /* Print option list for --help */
+ 
+ /**/
+ void
+ printoptionlist(void)
+ {
+     short *lp;
+     char c;
+ 
+     printf("\nNamed options:\n");
+     scanhashtable(optiontab, 1, 0, OPT_ALIAS, printoptionlist_printoption, 0);
+     printf("\nOption aliases:\n");
+     scanhashtable(optiontab, 1, OPT_ALIAS, 0, printoptionlist_printoption, 0);
+     printf("\nOption letters:\n");
+     for(lp = optletters, c = FIRST_OPT; c <= LAST_OPT; lp++, c++) {
+ 	if(!*lp)
+ 	    continue;
+ 	printf("  -%c  ", c);
+ 	printoptionlist_printequiv(*lp);
+     }
+ }
+ 
+ /**/
+ static void
+ printoptionlist_printoption(HashNode hn, int ignored)
+ {
+     Optname on = (Optname) hn;
+ 
+     if(on->flags & OPT_ALIAS) {
+ 	printf("  --%-19s  ", on->nam);
+ 	printoptionlist_printequiv(on->optno);
+     } else
+ 	printf("  --%s\n", on->nam);
+ }
+ 
+ /**/
+ static void
+ printoptionlist_printequiv(int optno)
+ {
+     int isneg = optno < 0;
+ 
+     optno *= (isneg ? -1 : 1);
+     printf("  equivalent to --%s%s\n", isneg ? "no-" : "", optns[optno-1].nam);
+ }
Index: Src/zsh.h
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/zsh.h,v
retrieving revision 1.16
diff -c -r1.16 zsh.h
*** Src/zsh.h	2000/06/22 08:42:37	1.16
--- Src/zsh.h	2000/07/30 16:23:30
***************
*** 1345,1353 ****
      EXTENDEDHISTORY,
      FLOWCONTROL,
      FUNCTIONARGZERO,
      GLOBALEXPORT,
      GLOBALRCS,
-     GLOBOPT,
      GLOBASSIGN,
      GLOBCOMPLETE,
      GLOBDOTS,
--- 1345,1353 ----
      EXTENDEDHISTORY,
      FLOWCONTROL,
      FUNCTIONARGZERO,
+     GLOBOPT,
      GLOBALEXPORT,
      GLOBALRCS,
      GLOBASSIGN,
      GLOBCOMPLETE,
      GLOBDOTS,
Index: Src/zsh.mdd
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/zsh.mdd,v
retrieving revision 1.1.1.13
diff -c -r1.1.1.13 zsh.mdd
*** Src/zsh.mdd	2000/01/14 19:15:00	1.1.1.13
--- Src/zsh.mdd	2000/07/30 16:23:30
***************
*** 27,33 ****
  
  init.o: bltinmods.list zshpaths.h zshxmods.h
  
! params.o: version.h
  
  version.h: $(sdir_top)/Config/version.mk
  	echo '#define ZSH_VERSION "'$(VERSION)'"' > $@
--- 27,33 ----
  
  init.o: bltinmods.list zshpaths.h zshxmods.h
  
! init.o params.o: version.h
  
  version.h: $(sdir_top)/Config/version.mk
  	echo '#define ZSH_VERSION "'$(VERSION)'"' > $@
END

Re: PATCH: Re: GNU-style long options for zsh

[Bart Schaefer]

On Jul 30,  5:49pm, zefram@fysh.org wrote:
} Subject: PATCH: Re: GNU-style long options for zsh
}
} 1.
} 
} Bart wrote:
} >Zsh accepts `-opts-junk' where "opts" are any valid option letters and
} >"junk" gets ignored.
} 
} This always annoyed me about zsh, and other programs that parse options
} that way.  I've fixed that such that `zsh -sh-word-split' (for example)
} is an error.

If we're going to change this from the old behavior:

I don't know for sure how this should work WRT an embedded `-', but an
embedded `b' should work like csh.  Using tcsh as the example, that means
that the NEXT word is no longer taken as an option, but that any other
letters in the CURRENT word still act like option selectors.  E.g.:

zagzig[265] tcsh -xe -foo
Unknown option: `-oo'
Usage: tcsh [ -bcdefilmnqstvVxX ] [ argument ... ].
zagzig[266] tcsh -xbe -foo
-foo: No such file or directory.
zagzig[267] tcsh -xby
Unknown option: `-y'
Usage: tcsh [ -bcdefilmnqstvVxX ] [ argument ... ].

} 2. Specifying an invalid option name on the command line causes zsh
} to exit, rather than continuing with an error message.  This makes it
} consistent with the handling of single-letter option names.

That's a pretty radical change with respect to `-o badlyspeltoption'.

} 3. "-" characters are permitted in GNU-style long option names --
} they get transformed into "_" characters -- so that the usual
} style "--sh-word-split" is permitted (Bart's version required
} "--sh_word_split").

Is there a good reason that `-' is not permitted within optlookup()?
Why not allow `setopt sh-word-split' too, and keep the special case out
of parseargs()?

} 4. Options can be turned off with "+-option-name" just like "+o
} option_name".

I actually originally had it that way, and then decided it wasn't kosher
and threw in the `action &&' test to prevent it.  Do any GNU programs
really accept `+-optionname' like that?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: Re: GNU-style long options for zsh

[Zefram]

Bart Schaefer wrote:
>I don't know for sure how this should work WRT an embedded `-', but an
>embedded `b' should work like csh.  Using tcsh as the example, that means
>that the NEXT word is no longer taken as an option, but that any other
>letters in the CURRENT word still act like option selectors.

Patch below.  I left embedded `-' as an error, because the convention
with -- is that it can't be followed by any more options.  `-b' obviously
has this other precedent which we should follow.  Incidentally I made
-b's meaning depend on SH_OPTION_LETTERS, rather than on the initial
emulation mode; this changes the behaviour of "zsh --sh-option-letters
-b" and similar stuff.

>} 2. Specifying an invalid option name on the command line causes zsh
>} to exit, rather than continuing with an error message.  This makes it
>} consistent with the handling of single-letter option names.
>
>That's a pretty radical change with respect to `-o badlyspeltoption'.

Desirable, I think: if you got the usage wrong, do you really want to
run the shell without that option set?  What if the option the user was
trying to set was RESTRICTED or PRIVILEGED?  Remember, this is only about
shell invocation, "set -o" remains unaffected and won't kill the shell.

>Is there a good reason that `-' is not permitted within optlookup()?
>Why not allow `setopt sh-word-split' too, and keep the special case out
>of parseargs()?

Just a stylistic hint at the semantics.  We've established that option
names look_like_this (or LIKE_THIS); the hyphenated form doesn't look
like at option name.  Other things being equal we could perfectly well
decide that from now on stuff-like-this is going to be option names, but
ZLE widget names already look-like-this.  I thought it better to keep
different types of names having a different style, as far as possible.
The GNU-style long options have their own style, --looking-like-this,
which looks different from both ZLE widget names and zsh option names.

I actually gave thought to forbidding underscores in the long options
(effectively swapping `-' and `_').  This would have enforced the style
distinction further, and made it more explicit that the GNU long options
are just a different form of the option names, rather than actually
option names plus a bodge.

I'm open to this being changed as you suggest.

>I actually originally had it that way, and then decided it wasn't kosher
>and threw in the `action &&' test to prevent it.  Do any GNU programs
>really accept `+-optionname' like that?

Not that I know of.  I'm fairly neutral on this; like the issue above,
it's a matter that I considered and came up with a weak preference which
is what I implemented.  If we want to keep strictly to the spirit of GNU
long options, we should just have "--option", no "+-option", and rely
on "--no-option" for negation.  (That's the form I had --help output
equivalences in, for this stylistic reason.)  But the rest of the zsh
option parser allows "+" where almost all other commands only allow
"-"; I don't know of any precedent of an option parser that had "+"
for negation and also GNU-style long options.  It seemed more in keeping
with zsh to allow this kind of negation.

This way also means that all the special options are treated the same
way w.r.t. "+": +b and -b are equivalent; similarly +c and -c, +- and --;
and of the GNU options, +-version is equivalent to --version and +-help
to --help.

-zefram

Index: Doc/Zsh/invoke.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/invoke.yo,v
retrieving revision 1.3
diff -c -r1.3 invoke.yo
*** Doc/Zsh/invoke.yo	2000/07/30 17:03:53	1.3
--- Doc/Zsh/invoke.yo	2000/07/30 19:06:50
***************
*** 72,79 ****
  are not permitted to be stacked after `tt(--)' (so `tt(-x-f)' is an error),
  but note the GNU-style option form discussed above, where `tt(--shwordsplit)'
  is permitted and does not end option processing.
! Except when emulating sh or ksh, the option `tt(-b)' is treated the same way
! as `tt(--)' for the purpose of ending option processing.
  
  startmenu()
  menu(Compatibility)
--- 72,82 ----
  are not permitted to be stacked after `tt(--)' (so `tt(-x-f)' is an error),
  but note the GNU-style option form discussed above, where `tt(--shwordsplit)'
  is permitted and does not end option processing.
! 
! Except when the bf(sh)/bf(ksh) emulation single-letter options are in effect,
! the option `tt(-b)' (or `tt(PLUS()b)') ends option processing.
! `tt(-b)' is like `tt(--)', except that further single-letter options can be
! stacked after the `tt(-b)' and will take effect as normal.
  
  startmenu()
  menu(Compatibility)
Index: Src/init.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/init.c,v
retrieving revision 1.8
diff -c -r1.8 init.c
*** Src/init.c	2000/07/30 17:03:53	1.8
--- Src/init.c	2000/07/30 19:06:55
***************
*** 186,195 ****
  void
  parseargs(char **argv)
  {
      char **x;
      int action, optno;
      LinkList paramlist;
-     int bourne = (emulation == EMULATE_KSH || emulation == EMULATE_SH);
  
      argzero = *argv++;
      SHIN = 0;
--- 186,195 ----
  void
  parseargs(char **argv)
  {
+     int optionbreak = 0;
      char **x;
      int action, optno;
      LinkList paramlist;
  
      argzero = *argv++;
      SHIN = 0;
***************
*** 206,222 ****
      opts[SINGLECOMMAND] = 0;
  
      /* loop through command line options (begins with "-" or "+") */
!     while (*argv && (**argv == '-' || **argv == '+')) {
  	char *args = *argv;
  	action = (**argv == '-');
  	if (!argv[0][1])
  	    *argv = "--";
  	while (*++*argv) {
! 	    /* The pseudo-option `--' signifies the end of options. *
! 	     * `-b' does too, csh-style, unless we're emulating a   *
! 	     * Bourne style shell.                                  */
! 	    if (**argv == '-' || (!bourne && **argv == 'b')) {
  		if(!argv[0][1]) {
  		    argv++;
  		    goto doneoptions;
  		}
--- 206,220 ----
      opts[SINGLECOMMAND] = 0;
  
      /* loop through command line options (begins with "-" or "+") */
!     while (!optionbreak && *argv && (**argv == '-' || **argv == '+')) {
  	char *args = *argv;
  	action = (**argv == '-');
  	if (!argv[0][1])
  	    *argv = "--";
  	while (*++*argv) {
! 	    if (**argv == '-') {
  		if(!argv[0][1]) {
+ 		    /* The pseudo-option `--' signifies the end of options. */
  		    argv++;
  		    goto doneoptions;
  		}
***************
*** 240,246 ****
  		goto longoptions;
  	    }
  
! 	    if (**argv == 'c') {         /* -c command */
  		cmd = *argv;
  		opts[INTERACTIVE] &= 1;
  		opts[SHINSTDIN] = 0;
--- 238,248 ----
  		goto longoptions;
  	    }
  
! 	    if (unset(SHOPTIONLETTERS) && **argv == 'b') {
! 		/* -b ends options at the end of this argument */
! 		optionbreak = 1;
! 	    } else if (**argv == 'c') {
! 		/* -c command */
  		cmd = *argv;
  		opts[INTERACTIVE] &= 1;
  		opts[SHINSTDIN] = 0;
***************
*** 321,333 ****
  static void
  printhelp(void)
  {
-     int bourne = (emulation == EMULATE_KSH || emulation == EMULATE_SH);
- 
      printf("Usage: %s [<options>] [<argument> ...]\n", argzero);
      printf("\nSpecial options:\n");
      printf("  --help     show this message, then exit\n");
      printf("  --version  show zsh version number, then exit\n");
!     if(!bourne)
  	printf("  -b         end option processing, like --\n");
      printf("  -c         take first argument as a command to execute\n");
      printf("  -o OPTION  set an option by name (see below)\n");
--- 323,333 ----
  static void
  printhelp(void)
  {
      printf("Usage: %s [<options>] [<argument> ...]\n", argzero);
      printf("\nSpecial options:\n");
      printf("  --help     show this message, then exit\n");
      printf("  --version  show zsh version number, then exit\n");
!     if(unset(SHOPTIONLETTERS))
  	printf("  -b         end option processing, like --\n");
      printf("  -c         take first argument as a command to execute\n");
      printf("  -o OPTION  set an option by name (see below)\n");
END

Re: PATCH: Re: GNU-style long options for zsh

[Peter Stephenson]

The long options look fine, but I think the reason they were never
implemented before is that we (or at least Sven) were vaguely thinking
about putting more general POSIX style options for a lot of builtins into a
module, to make it possible to be more readable.  This was originally
directed at compctl which now won't get that treatment.  But it's still a
possibility elsewhere.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk