Announcement draft

Announcement draft

[Zoltan Hidvegi]

I'd like to announce zsh-3.0-pre5 in a few newsgroups.  Here is my proposed
announcement.  Please tell me your opinions about that.

Zoltan


-----BEGIN PGP SIGNED MESSAGE-----

 Zsh version 3.0 is going to be released soon!
 ---------------------------------------------

The latest version is zsh-3.0-pre5.  It is much more stable than the last
production release, zsh-2.5.0.  More than a thousand bugs have been fixed
since the release of zsh-2.5.0 (although none counted) and several new
features were added.  Everyone using zsh-2.5.0 or earlier is encouraged to
upgrade.  Note that some incompatible changes have been made to zsh so
old scripts may have to be modified to run with zsh-3.0.

For those who do not know what it is:

The Z-shell, zsh is the most powerful freely available Unix command
interpreter.  It most resembles the Korn shell (ksh).  It includes

 * a very powerful command-line editor which can even be used to edit
   files

 * 102 options for customizing its behavior

 * very powerful filename globing which can do almost everything that
   find can do

 * fully programmable completion

 * spelling correction

 * powerful substitution features which can often be used instead of cut
   or sed

 * features to make C-shell (csh) users feel more at home and extra
   features drawn from tcsh (another `custom' shell).

Additionally zsh is probably one of the most portable program available
for Unix.  It uses GNU autoconf and it builds out of the box on most
systems.

Zsh can emulate the POSIX shell and the Korn shell quite well when it is
invoked as sh or ksh respectively.  /bin/sh can be safely linked to zsh.

The latest release, the zsh FAQ and documentation is available from the
following anonymous ftp sites.  The first is the official archive site.
The rest are mirror sites which are kept frequently up to date.  The sites
marked with a star may mirror ftp.math.gatech.edu instead of the primary
site.

   HUNGARY
      ftp://ftp.cs.elte.hu/pub/zsh/

   Australia
    * ftp://ftp.ips.oz.au/pub/packages/zsh/

   France
      ftp://ftp.cenatls.cena.dgac.fr/pub/shells/zsh/

   Germany
      ftp://ftp.uni-trier.de/pub/unix/shell/zsh/
      ftp://ftp.prz.tu-berlin.de/pub/unix/shells/zsh/
    * ftp://ftp.fu-berlin.de/pub/unix/shells/zsh/

   Japan
      ftp://ftp.tohoku.ac.jp/mirror/zsh/
    * ftp://ftp.iij.ad.jp/pub/misc/zsh/

   Norway
    * ftp://ftp.uit.no/pub/unix/shells/zsh/

   Sweden
      ftp://ftp.lysator.liu.se/pub/unix/zsh/

   UK
      ftp://ftp.net.lut.ac.uk/zsh/

   USA
      ftp://ftp.math.gatech.edu/pub/zsh/
      ftp://uiarchive.cso.uiuc.edu/pub/packages/shells/zsh/
    * ftp://ftp.sterling.com/zsh/
    * ftp://ftp.rge.com/pub/shells/zsh/


Zoltan Hidvegi
Coordinator of the zsh development

My PGP public key is available from the above ftp sites (in pubring.pgp),
via finger -l hzoli@cs.elte.hu or from the key servers.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBMf/LUAupSCiLN749AQGxngP+ODNsh6ZTmILDasUJgYSDReHxSfE1bC6m
I9kOh2Cmd11Rr1VY/EGvTxFhNByW8kfxsJpTcJgQtbXZTFW5f7ysFIg7GqzkfDLR
vfpqVww6JsbVQ94vTjhlFROsMlDDfuiuHSUHPDIxu/V0S34UpkdoYoDJKg9qQ2my
CRsesNSH8HY=
=osRE
-----END PGP SIGNATURE-----

Re: Announcement draft

[Zefram]

>The latest version is zsh-3.0-pre5.  It is much more stable than the last
>production release, zsh-2.5.0.  More than a thousand bugs have been fixed
>since the release of zsh-2.5.0 (although none counted)

What do you mean by "none counted"?  Should that be "no one counted"?

> * a very powerful command-line editor which can even be used to edit
>   files

Binary files too, now.  I think that's worth a mention.

> * very powerful filename globing which can do almost everything that
>   find can do

Does someone want to implement find as a zsh script?  It wouldn't
usually be practically useful, but it would be a great demonstration of
zsh's generality.

You didn't mention the enormous number of builtins.

>Additionally zsh is probably one of the most portable program available
>for Unix.  It uses GNU autoconf and it builds out of the box on most
>systems.

Remove "probably".

If it's not in yet, some mention of the swapping of -1 and -C should be
added to the FAQ.

-zefram

Re: Announcement draft

[Bas V. de Bakker]

Zoltan Hidvegi <hzoli@cs.elte.hu> writes:

> More than a thousand bugs have been fixed since the release of
> zsh-2.5.0

This makes 2.5.0 sound quite unusable, which it wasn't.  Are you also
counting the bugs introduced after 2.5.0?

> Additionally zsh is probably one of the most portable program
> available for Unix.  It uses GNU autoconf and it builds out of the
> box on most systems.

Considering the amount of system calls a shell uses, it is surely very
portable.  But I tend to doubt whether this is true when compared to
all kinds of programs that do not need to depend on system specific
features.

> /bin/sh can be safely linked to zsh.

This sounded too good to be true, so I just tested this on the perl
Configure script and it failed, sorry.  (To be slightly more precise:
when typing '& -d' at a prompt to make it use the defaults zsh gives
me a parse error, while /bin/sh (POSIX, not traditional Bourne) has no
problems.  This on HPUX 10.10.)

Bas.

Re: Announcement draft

[Peter Stephenson]

bas@astro.uva.nl wrote:
> > /bin/sh can be safely linked to zsh.
> 
> This sounded too good to be true, so I just tested this on the perl
> Configure script and it failed, sorry.  (To be slightly more precise:
> when typing '& -d' at a prompt to make it use the defaults zsh gives
> me a parse error, while /bin/sh (POSIX, not traditional Bourne) has no
> problems.  This on HPUX 10.10.)

Irix, too.  I think I've pinpointed this: it happens when the `myread'
file for later sourcing is set up as a here document.

% <testscr
cat <<EOSC >test.out
eval "ans=\"\$answ\""
EOSC
% zsh -fc 'emulate sh; . ./testscr' 
% <test.out
eval "ans="$answ""
% sh -c '. ./testscr'
% <test.out
eval "ans=\"$answ\""

Zsh is stripping the backslash from the double quotes.  This looks
wrong to me.  `answ' contains the user input, here "& -d", which is
causing the problem.  (I didn't look into the specific nature of the
problem, but the errors is reported on that line, which is the only
one which is significantly different from the sh version of myread.)

Anyone know the proper backslash rules for here documents?


By the way: some time after 3.0 is released and stable (preferably not
in that order :-/) it would be quite nice to have ksh/sh emulation as
a command line option, to avoid what I had to do above (linking zsh
under sh, when there's a real sh on the machine, is no nicer).

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77330
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Running zsh as sh (Was: Announcement draft)

[Bas V. de Bakker]

Peter Stephenson <pws@ifh.de> writes:

> By the way: some time after 3.0 is released and stable (preferably
> not in that order :-/) it would be quite nice to have ksh/sh
> emulation as a command line option, to avoid what I had to do above
> (linking zsh under sh, when there's a real sh on the machine, is no
> nicer).

I agree that a command line option would be useful, but you can
already do this quite easily using:

% ARGV0=sh zsh script

Bas.

Re: Announcement draft

[Andrej Borsenkow]

On Thu, 1 Aug 1996, Peter Stephenson wrote:

> 
> Anyone know the proper backslash rules for here documents?
> 

It depends on what "proper" rules are ;)

Here is relevant part form XPG4 Shell:

1. Section 2.7.4 (Here-document)

...
If no character in word are qouted, all lines of the here-document will be
expanded for parameter expansion, command substitution and arithmetic
expansion. In this case, the backslash in the input will behave as the
backslash inside double-quotes (see Section 2.2.3) However, the
double-quote character (") will not be treated specially within a
here-document, except when the double-quote appears within $(), ``, or
${}.

...

2. Section 2.2.3 (Double-quoting)

Characters to be treated specially in double-quotes:

$ - dollar sign
` - backquote
\ - backslash *only when followed by one of characters $ ` " \ <newline>*

...
In double-quote, if a backslash is immediately followed by a character
that would be interpreted as having special meaning, the backslash is
deleted and the subsequent character is taken literally. If a backslash
does not precede a character, that would have a special meaning, it is
left in place unmodified and the character immediately following it is
also left unmodified.
...

=== End of citation

It implies, that \" and \\" are the same in here-document. Wonder.

If it helps ...

greetings

-------------------------------------------------------------------------
Andrej Borsenkow 		Fax:   +7 (095) 252 01 05
SNI ITS Moscow			Tel:   +7 (095) 252 13 88

NERV:  borsenkow.msk		E-Mail: borsenkow.msk@sni.de
-------------------------------------------------------------------------

Here docs

[Peter Stephenson]

I expect Zoltan's already fixed this, but anyway...

borsenkow.msk@sni.de wrote:
> On Thu, 1 Aug 1996, Peter Stephenson wrote:
> 
> > Anyone know the proper backslash rules for here documents?
> 
> Here is relevant part form XPG4 Shell:
> 
> 1. Section 2.7.4 (Here-document)
> 
> ...
> In this case, the backslash in the input will behave as the
> backslash inside double-quotes (see Section 2.2.3) However, the
> double-quote character (") will not be treated specially within a
> here-document, except when the double-quote appears within $(), ``, or
> ${}.

That's clear enough for here documents... the question is what should
happen at other times when zsh is parsing something in the same way.
This is usually when tokenising a string that hadn't already been
through the lexer, but is going to have some substitution arrangement
performed on it (this does not include many obvious cases like
$(...)).  If the answer is that \" should be left in this case too,
the fix is easy.

I believe this fix is right in all those cases for the following
reason: the code in dquote_parse() is specifically set up not to treat
unbackslashed " specially in these circumstances (test at line 1095 of
lex.c), so should not treat backslashed " specially either.

This should make Configure happier, any chance that it might work now?

There's a very minor difference left:
% cat <<EOS
> ${not_set:-\}}
> EOS

ksh gives \} and zsh gives } as output.  I like zsh's better.

*** Src/lex.c.bsqt	Wed Jul 24 16:34:31 1996
--- Src/lex.c	Thu Aug  1 15:29:18 1996
***************
*** 1001,1007 ****
  	    c = hgetc();
  	    if (c != '\n')
  		add(c == '$' || c == '\\' || (c == '}' && !intick && bct) ||
! 		    c == '\"' || c == '`' ? Bnull : '\\');
  	    else if (sub || unset(CSHJUNKIEQUOTES) || endchar != '"')
  		continue;
  	    break;
--- 1001,1007 ----
  	    c = hgetc();
  	    if (c != '\n')
  		add(c == '$' || c == '\\' || (c == '}' && !intick && bct) ||
! 		    (endchar && c == '\"') || c == '`' ? Bnull : '\\');
  	    else if (sub || unset(CSHJUNKIEQUOTES) || endchar != '"')
  		continue;
  	    break;


-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77330
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Re: Here docs

[Zoltan Hidvegi]

Peter wrote:
> I expect Zoltan's already fixed this, but anyway...

Yes :-).

> > In this case, the backslash in the input will behave as the
> > backslash inside double-quotes (see Section 2.2.3) However, the
> > double-quote character (") will not be treated specially within a
> > here-document, except when the double-quote appears within $(), ``, or
> > ${}.
> 
> That's clear enough for here documents... the question is what should
> happen at other times when zsh is parsing something in the same way.
> This is usually when tokenising a string that hadn't already been

Here is my patch, a bit different from yours.  It fixes some other
inconsistencies and it also handles " in ${...} as reuired above.  When I
read POSIX I was pleased to know that here ducuments should be parsed the
same way as double-quoted strings, and relaxed knowing that zsh does
exactly that.  And indeed the problem was not really in the here-document
code.  I did not notice this problem because configure coming with zsh
always ran fine.

Zoltan


*** Src/lex.c	1996/07/24 14:39:19	2.40
--- Src/lex.c	1996/08/01 13:47:44
***************
*** 996,1008 ****
      while (((c = hgetc()) != endchar || bct ||
  	    (math && ((pct > 0) || (brct > 0))) ||
  	    intick) && !lexstop) {
  	switch (c) {
  	case '\\':
  	    c = hgetc();
! 	    if (c != '\n')
! 		add(c == '$' || c == '\\' || (c == '}' && !intick && bct) ||
! 		    c == '\"' || c == '`' ? Bnull : '\\');
! 	    else if (sub || unset(CSHJUNKIEQUOTES) || endchar != '"')
  		continue;
  	    break;
  	case '\n':
--- 996,1015 ----
      while (((c = hgetc()) != endchar || bct ||
  	    (math && ((pct > 0) || (brct > 0))) ||
  	    intick) && !lexstop) {
+       cont:
  	switch (c) {
  	case '\\':
  	    c = hgetc();
! 	    if (c != '\n') {
! 		if (c == '$' || c == '\\' || (c == '}' && !intick && bct) ||
! 		    c == endchar || c == '`')
! 		    add(Bnull);
! 		else {
! 		    /* lexstop is implicitely handled here */
! 		    add('\\');
! 		    goto cont;
! 		}
! 	    } else if (sub || unset(CSHJUNKIEQUOTES) || endchar != '"')
  		continue;
  	    break;
  	case '\n':
***************
*** 1092,1098 ****
  	    err = (!brct-- && math);
  	    break;
  	case '"':
! 	    if (intick || !endchar)
  		break;
  	    if (bct) {
  		add(Dnull);
--- 1099,1105 ----
  	    err = (!brct-- && math);
  	    break;
  	case '"':
! 	    if (intick || (!endchar && !bct))
  		break;
  	    if (bct) {
  		add(Dnull);

Re: Announcement draft

[Zoltan Hidvegi]

> Zoltan Hidvegi <hzoli@cs.elte.hu> writes:
> 
> > More than a thousand bugs have been fixed since the release of
> > zsh-2.5.0
> 
> This makes 2.5.0 sound quite unusable, which it wasn't.  Are you also

Well I tend to think that 2.5.0 is almost unusably buggy.  At least as I
remember each time I wanted to write a shell script more complicated than
average it turned out that I have to figure out how to circumvent the bugs
which prevented the script running.  Especially in subst.c and params.c
there were really ridiculous bugs.  Things like

if (...) {
	char *s = zalloc(10);
}

It lookd as if someone started something and forgot to finish.  I started
to hack the code exactly because of these bugs.

For interactive use 2.5.0 is quite fine but it was a pain to use it with
scripts.

I thinkg I'll thant `more than a thousand' to `several hundred' but that
does not sound much better either.  I'm sure that if you read the ChangeLog
you'll really find several hundred fixes relative to 2.5.0 and note that
not all fixes mentioned there.

Zoltan

More Configure problems

[Peter Stephenson]

Next problem with Configure... actually with the makedepend script
that comes with it:  this assignment is failing:

    defrule=`<$mf sed -n		\
	-e '/^\.c\(\$(OBJ_EXT)\|\.o\):.*;/{'	\
	-e    's/\$\*\.c//'		\
	-e    's/^[^;]*;[	 ]*//p'	\
	-e    q				\
	-e '}'				\
	-e '/^\.c\(\$(OBJ_EXT)\|\.o\): *$/{'	\
	-e    N				\
	-e    's/\$\*\.c//'		\
	-e    's/^.*\n[	 ]*//p'		\
	-e    q				\
	-e '}'`

That first interestingly positioned <$mf (sometimes I wonder if people
do this deliberately) is supposed to be a redirection, but zsh is
treating it like $(<...).  ksh behaves like sh here, i.e. only $(<...)
has that behaviour.  Perhaps we should follow suit.

Zoltan will know what to do.

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77330
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Re: More Configure problems

[Peter Stephenson]

I wrote:
> Next problem with Configure... actually with the makedepend script
> that comes with it:  this assignment is failing:
> 
>     defrule=`<$mf sed -n		\
> ...
> 
> That first interestingly positioned <$mf (sometimes I wonder if people
> do this deliberately) is supposed to be a redirection, but zsh is
> treating it like $(<...).  ksh behaves like sh here, i.e. only $(<...)
> has that behaviour.  Perhaps we should follow suit.

Well, there's only about one possible fix, as follows.  The manual
page mentions $(<...) and specifically fails to mention `<...`, so I
think we're in line with that after the patch.  No other Configure
problems that I've noticed.  (This is actually non-trivial, if you
want to install perl on Linux without having to have bash around.)

*** Src/exec.c.go	Thu Aug  1 19:14:53 1996
--- Src/exec.c	Thu Aug  1 19:19:00 1996
***************
*** 1986,1998 ****
  
  /**/
  LinkList
! getoutput(char *cmd, int qt)
  {
      List list;
      int pipes[2];
      pid_t pid;
  
!     if (*cmd == '<') {
  	int stream, l;
  	char *fi, *s;
  
--- 1986,1998 ----
  
  /**/
  LinkList
! getoutput(char *cmd, int qt, int stringpar)
  {
      List list;
      int pipes[2];
      pid_t pid;
  
!     if (*cmd == '<' && stringpar) {
  	int stream, l;
  	char *fi, *s;
  
*** Src/subst.c.go	Thu Aug  1 19:14:58 1996
--- Src/subst.c	Thu Aug  1 19:22:25 1996
***************
*** 92,105 ****
  LinkNode
  stringsubst(LinkList list, LinkNode node, int ssub)
  {
!     int qt;
      char *str3 = (char *)getdata(node);
      char *str  = str3;
  
      while (!errflag && *str) {
  	if ((qt = *str == Qstring) || *str == String)
  	    if (str[1] == Inpar) {
  		str++;
  		goto comsub;
  	    } else if (str[1] == Inbrack) {
  		/* $[...] */
--- 92,107 ----
  LinkNode
  stringsubst(LinkList list, LinkNode node, int ssub)
  {
!     int qt, stringpar;
      char *str3 = (char *)getdata(node);
      char *str  = str3;
  
      while (!errflag && *str) {
+ 	stringpar = 0;
  	if ((qt = *str == Qstring) || *str == String)
  	    if (str[1] == Inpar) {
  		str++;
+ 		stringpar = 1;
  		goto comsub;
  	    } else if (str[1] == Inbrack) {
  		/* $[...] */
***************
*** 161,167 ****
  		       (qt && str[1] == '"'))))
  		    *str = ztokens[*str - Pound];
  	    str++;
! 	    if (!(pl = getoutput(str2 + 1, qt || ssub))) {
  		zerr("parse error in command substitution", NULL, 0);
  		return NULL;
  	    }
--- 163,169 ----
  		       (qt && str[1] == '"'))))
  		    *str = ztokens[*str - Pound];
  	    str++;
! 	    if (!(pl = getoutput(str2 + 1, qt || ssub, stringpar))) {
  		zerr("parse error in command substitution", NULL, 0);
  		return NULL;
  	    }

-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77330
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Re: More Configure problems

[Zoltan Hidvegi]

Peter wrote:
> > Next problem with Configure... actually with the makedepend script
> > that comes with it:  this assignment is failing:
> > 
> >     defrule=`<$mf sed -n		\
> > ...
> > 
> > That first interestingly positioned <$mf (sometimes I wonder if people
> > do this deliberately) is supposed to be a redirection, but zsh is
> > treating it like $(<...).  ksh behaves like sh here, i.e. only $(<...)
> > has that behaviour.  Perhaps we should follow suit.
> 
> Well, there's only about one possible fix, as follows.  The manual
> page mentions $(<...) and specifically fails to mention `<...`, so I
> think we're in line with that after the patch.  No other Configure
> problems that I've noticed.  (This is actually non-trivial, if you
> want to install perl on Linux without having to have bash around.)

I'd prefer a different fix.  I think it is better to parse each command
substitution lexically and if it consists of a single redirection to stdin
than behave as $(< file) behaves now.  This is really preferrable since $(<
file command) should execute the given command.  That's the ksh behaviour
and that's what required by POSIX.  I'll try to write a patch for that.

Zoltan

Re: More Configure problems

[Zoltan Hidvegi]

I wrote:
> Peter wrote:
> > > Next problem with Configure... actually with the makedepend script
> > > that comes with it:  this assignment is failing:
> > > 
> > >     defrule=`<$mf sed -n		\
> > > ...
> > > 
> > > That first interestingly positioned <$mf (sometimes I wonder if people
> > > do this deliberately) is supposed to be a redirection, but zsh is
> > > treating it like $(<...).  ksh behaves like sh here, i.e. only $(<...)
> > > has that behaviour.  Perhaps we should follow suit.
> > 
> > Well, there's only about one possible fix, as follows.  The manual
> > page mentions $(<...) and specifically fails to mention `<...`, so I
> > think we're in line with that after the patch.  No other Configure
> > problems that I've noticed.  (This is actually non-trivial, if you
> > want to install perl on Linux without having to have bash around.)
> 
> I'd prefer a different fix.  I think it is better to parse each command
> substitution lexically and if it consists of a single redirection to stdin
> than behave as $(< file) behaves now.  This is really preferrable since $(<
> file command) should execute the given command.  That's the ksh behaviour
> and that's what required by POSIX.  I'll try to write a patch for that.

I made the patch below.  It really makes the code cleaner but unfortunately
the change is not trivial because it removes pushheap()/popheap() from
parse_string().  So far parse_string() used pushheap() before starting the
parser and it did not pop the heap if the parsing was successful.  Of
course this increases the possibility of a forgotten popheap() and indeed
I've found that there was no popheap() after calling getshunc() which
called getfpfunc() which called parse_string().  So this only happened when
getshfunc used on an autoloaded function, e.g. when chpwd was autoloaded.
Of course this did not cause any noticable problem except that it was a
memory leak.

The change below would be more difficult without removing this heap stuff
because the parsed list must be preserved somehow after popheap (it would
not be much more difficult, just 2 more lines I think).

I did not test this patch, since I'd like to catch the last but home from
the university so it may be buggy.  Please test it.

Zoltan


*** Src/exec.c	1996/07/31 14:05:25	2.78
--- Src/exec.c	1996/08/01 20:59:39
***************
*** 48,61 ****
      lexsave();
      inpush(s, 0);
      strinbeg();
-     pushheap();
      stophist = 2;
      l = parse_list();
      strinend();
      inpop();
      lexrestore();
-     if (!l)
- 	popheap();
      return l;
  }
  
--- 48,58 ----
***************
*** 475,484 ****
  {
      List list;
  
!     if ((list = parse_string(s))) {
  	execlist(list, dont_change_job, exiting);
! 	popheap();
!     }
  }
  
  /* Main routine for executing a list.                                *
--- 472,481 ----
  {
      List list;
  
!     pushheap();
!     if ((list = parse_string(s)))
  	execlist(list, dont_change_job, exiting);
!     popheap();
  }
  
  /* Main routine for executing a list.                                *
***************
*** 1991,2033 ****
      List list;
      int pipes[2];
      pid_t pid;
  
!     if (*cmd == '<') {
! 	int stream, l;
! 	char *fi, *s;
! 
! 	for (cmd++; *cmd == ' '; cmd++);
! 	for (fi = s = cmd + strlen(cmd); s > cmd && s[-1] == ' '; s--);
! 	if (s > cmd && s < fi && (s[-1] == '\\' || s[-1] == Meta))
! 	    s++;
! 	l = s - cmd;
! 	fi = ncalloc(l + 1);
! 	strncpy(fi, cmd, l);
! 	fi[l] = '\0';
! 	if (parsestr(fi))
! 	    return NULL;
! 	if (*fi == '~')
! 	    *fi = Tilde;
! 	else if (*fi == '=')
! 	    *fi = Equals;
! 	singsub(&fi);
  	if (errflag)
  	    return NULL;
! 	stream = open(unmeta(fi), O_RDONLY);
! 	if (stream == -1) {
! 	    zerr("%e: %s", fi, errno);
! 	    return NULL;
! 	}
  	return readoutput(stream, qt);
      }
!     if (!(list = parse_string(cmd)))
! 	return NULL;
      mpipe(pipes);
      child_block();
      cmdoutval = 0;
      if ((cmdoutpid = pid = zfork()) == -1) {
  	/* fork error */
- 	popheap();
  	zclose(pipes[0]);
  	zclose(pipes[1]);
  	errflag = 1;
--- 1988,2021 ----
      List list;
      int pipes[2];
      pid_t pid;
+     Cmd c;
+     Redir r;
  
!     if (!(list = parse_string(cmd)))
! 	return NULL;
!     if (list != &dummy_list && !list->right && !list->left->flags &&
! 	list->left->type == END && list->left->left->type == END &&
! 	(c = list->left->left->left)->type == SIMPLE && empty(c->args) &&
! 	empty(c->vars) && nonempty(c->redir) &&
! 	!nextnode(firstnode(c->redir)) &&
! 	(r = (Redir) getdata(firstnode(c->redir)))->fd1 == 0 &&
! 	r->type == READ) {
! 	/* $(< word) */
! 	int stream;
! 	char *s = r->name;
! 
! 	singsub(&s);
  	if (errflag)
  	    return NULL;
! 	stream = open(unmeta(s), O_RDONLY);
  	return readoutput(stream, qt);
      }
! 
      mpipe(pipes);
      child_block();
      cmdoutval = 0;
      if ((cmdoutpid = pid = zfork()) == -1) {
  	/* fork error */
  	zclose(pipes[0]);
  	zclose(pipes[1]);
  	errflag = 1;
***************
*** 2037,2043 ****
      } else if (pid) {
  	LinkList retval;
  
- 	popheap();
  	zclose(pipes[1]);
  	retval = readoutput(pipes[0], qt);
  	fdtable[pipes[0]] = 0;
--- 2025,2030 ----
***************
*** 2159,2172 ****
  
      if (fd < 0 || (cmdoutpid = pid = zfork()) == -1) {
  	/* fork or open error */
- 	popheap();
  	child_unblock();
  	return nam;
      } else if (pid) {
  	int os;
  
  	close(fd);
- 	popheap();
  	os = jobtab[thisjob].stat;
  	waitforpid(pid);
  	cmdoutval = 0;
--- 2146,2157 ----
***************
*** 2248,2254 ****
  	zclose(pipes[out]);
  	fdtable[pipes[!out]] = 2;
  #endif
- 	popheap();
  	return pnam;
      }
  #ifndef HAVE_DEV_FD
--- 2233,2238 ----
***************
*** 2285,2291 ****
  	return -1;
      mpipe(pipes);
      if (zfork()) {
- 	popheap();
  	zclose(pipes[out]);
  	return pipes[!out];
      }
--- 2269,2274 ----
***************
*** 2412,2418 ****
  	    shf->flags &= ~PM_UNDEFINED;
  	    funcdef = shf->funcdef = (List) dupstruct(funcdef);
  	} LASTALLOC;
- 	popheap();
  
  	/* Execute the function definition, we just retrived */
  	doshfunc(shf->funcdef, cmd->args, shf->flags, 0);
--- 2395,2400 ----
*** Src/builtin.c	1996/07/31 15:45:25	2.71
--- Src/builtin.c	1996/08/01 20:24:46
***************
*** 5501,5508 ****
  	if (settrap(sig, t))
  	    freestruct(t);
      }
-     if (l)
- 	popheap();
      return *argv != NULL;
  }
  
--- 5501,5506 ----

Re: More Configure problems

[Zoltan Hidvegi]

> I did not test this patch, since I'd like to catch the last but home from
> the university so it may be buggy.  Please test it.

I've found one problem with that so far: I forgot an untokenize().  Patch
included below.

Zoltan


*** /tmp/exec.c	Fri Aug  2 00:26:38 1996
--- Src/exec.c	Fri Aug  2 00:36:20 1996
***************
*** 2007,2012 ****
--- 2007,2013 ----
  	singsub(&s);
  	if (errflag)
  	    return NULL;
+ 	untokenize(s);
  	stream = open(unmeta(s), O_RDONLY);
  	return readoutput(stream, qt);
      }

Re: More Configure problems

[Zefram]

>That first interestingly positioned <$mf (sometimes I wonder if people
>do this deliberately) is supposed to be a redirection, but zsh is
>treating it like $(<...).  ksh behaves like sh here, i.e. only $(<...)
>has that behaviour.  Perhaps we should follow suit.

I think we should treat $(< x) and `< x` the same, as a special case of
null redirection.  If there's a command as well as the redirection,
execute the command.  zsh already gets it right if there's a space
before the <.

-zefram

Re: More Configure problems

[Peter Stephenson]

hzoli@cs.elte.hu wrote:
> I did not test this patch, since I'd like to catch the last but home from
> the university so it may be buggy.  Please test it.

With this set of patches perl built OK with zsh linked to sh and
passed all tests, the process including & -d, shell escapes, etc.  I
couldn't rewire /bin/sh, but most shell scripts during the build are
called with an explicit `sh', so this is quite a good test.

I'm planning on including a clearer summary of compatiblity in the
appropriate section of the FAQ, B1; here is a preview.


  As a summary of the status:
    i) because of all the options it is not safe to assume a general
       zsh run by a user will behave as if sh or ksh compatible;
   ii) invoking zsh as sh or ksh (including if either is a symbolic
       link to zsh) sets appropriate options and improves
       compatibility;
  iii) from version 3.0 onward the degree of compatibility with sh
       under these circumstances is very high:  zsh can now be used
       with GNU configure or perl's Configure, for example;
   iv) the degree of compatibility with ksh is also high, but a few
       things are missing:  for example the more sophisticated
       pattern-matching expressions are different --- see the detailed
       list below;
    v) also from 3.0, the command `emulate' is available: `emulate
       ksh' and `emulate sh' set various options as well as changing the
       effect of single-letter option flags as if the shell had been
       invoked with the appropriate name.  Including the commands
       `emulate sh; setopt localoptions' in a shell function will
       turn on sh emulation for that function only.


-- 
Peter Stephenson <pws@ifh.de>       Tel: +49 33762 77366
WWW:  http://www.ifh.de/~pws/       Fax: +49 33762 77330
Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen
DESY-IfH, 15735 Zeuthen, Germany.

Re: More Configure problems

[Andrej Borsenkow]

On Fri, 2 Aug 1996, Peter Stephenson wrote:

> 
> With this set of patches perl built OK with zsh linked to sh and
> passed all tests, the process including & -d, shell escapes, etc.  I
> couldn't rewire /bin/sh, but most shell scripts during the build are
> called with an explicit `sh', so this is quite a good test.
> 

I did link /bin/sh to zsh and ran pel 5.003 Configure; it was O.K.,
including & -d, makedepend and make ;-)

But small problem with command substitution anyway. The following:

% : `
bquote> cat > foo << eof
bquote> a
bquote> eof
bquote> `
>        <-- !!!

runs perfectly on my /bin/sh (and should according to POSIX :)) but not
under zsh. (Including last three patches to heredoc an $(< ...) fix). It
wants something after the last backtick. The same problem with $() form.
If the heredoc delimiter is quoted, it is O.K. 

% : `
bquote> cat > foo << \eof
bquote> a
bquote> eof
bquote> `
%

Again in `` or $() form.

The example is probably perverse; so it just FYI

greetings

-------------------------------------------------------------------------
Andrej Borsenkow 		Fax:   +7 (095) 252 01 05
SNI ITS Moscow			Tel:   +7 (095) 252 13 88

NERV:  borsenkow.msk		E-Mail: borsenkow.msk@sni.de
-------------------------------------------------------------------------

Re: More Configure problems

[Zoltan Hidvegi]

> But small problem with command substitution anyway. The following:
> 
> % : `
> bquote> cat > foo << eof
> bquote> a
> bquote> eof
> bquote> `
> >        <-- !!!
> 
> runs perfectly on my /bin/sh (and should according to POSIX :)) but not
> under zsh. (Including last three patches to heredoc an $(< ...) fix). It
> wants something after the last backtick. The same problem with $() form.
> If the heredoc delimiter is quoted, it is O.K. 
> 
> % : `
> bquote> cat > foo << \eof
> bquote> a
> bquote> eof
> bquote> `
> %
> 
> Again in `` or $() form.

Yes, it is a problem, and I think it may cause problems in other
circumstances as well.  The patch below fixes that.  This bug is really
fixed by the hist.c patch below but it also contains a lex.c fix because I
first thought that the problem is there.

Zoltan


*** Src/hist.c	1996/07/21 00:05:50	2.22
--- Src/hist.c	1996/08/02 13:07:29
***************
*** 567,573 ****
  void
  strinbeg(void)
  {
!     strin = 1;
      hbegin();
      lexinit();
  }
--- 567,573 ----
  void
  strinbeg(void)
  {
!     strin++;
      hbegin();
      lexinit();
  }
***************
*** 579,585 ****
  strinend(void)
  {
      hend();
!     strin = 0;
      isfirstch = 1;
      histdone = 0;
  }
--- 579,586 ----
  strinend(void)
  {
      hend();
!     DPUTS(!strin, "BUG: strinend() called without strinbeg()");
!     strin--;
      isfirstch = 1;
      histdone = 0;
  }
*** Src/lex.c	1996/08/01 17:56:17	2.41
--- Src/lex.c	1996/08/02 13:16:25
***************
*** 65,70 ****
--- 65,71 ----
      int chwordlen;
      int chwordpos;
      int hwgetword;
+     int lexstop;
      struct heredocs *hdocs;
  
      unsigned char *cstack;
***************
*** 117,122 ****
--- 118,124 ----
      ls->chwordlen = chwordlen;
      ls->chwordpos = chwordpos;
      ls->hwgetword = hwgetword;
+     ls->lexstop = lexstop;
      ls->hdocs = hdocs;
      cmdsp = 0;
      inredir = 0;
***************
*** 162,171 ****
      chwordlen = lstack->chwordlen;
      chwordpos = lstack->chwordpos;
      hwgetword = lstack->hwgetword;
      hdocs = lstack->hdocs;
      clearalstack();
      hlinesz = lstack->hlinesz;
!     lexstop = errflag = 0;
  
      ln = lstack->next;
      free(lstack);
--- 164,174 ----
      chwordlen = lstack->chwordlen;
      chwordpos = lstack->chwordpos;
      hwgetword = lstack->hwgetword;
+     lexstop = lstack->lexstop;
      hdocs = lstack->hdocs;
      clearalstack();
      hlinesz = lstack->hlinesz;
!     errflag = 0;
  
      ln = lstack->next;
      free(lstack);
***************
*** 370,375 ****
--- 373,380 ----
    beginning:
      tokstr = NULL;
      while (iblank(c = hgetc()) && !lexstop);
+     if (lexstop)
+ 	return (errflag) ? LEXERR : ENDINPUT;
      isfirstln = 0;
      wordbeg = inbufct - (qbang && c == bangchar);
      hwbegin(-1);		/* word includes the last character read */
***************
*** 390,400 ****
  	return DOUTPAR;
      } else if (idigit(c)) {	/* handle 1< foo */
  	d = hgetc();
- 	hungetc(d);
- 	lexstop = 0;
  	if (d == '>' || d == '<') {
  	    peekfd = c - '0';
! 	    c = hgetc();
  	}
      }
  
--- 395,406 ----
  	return DOUTPAR;
      } else if (idigit(c)) {	/* handle 1< foo */
  	d = hgetc();
  	if (d == '>' || d == '<') {
  	    peekfd = c - '0';
! 	    c = d;
! 	} else {
! 	    hungetc(d);
! 	    lexstop = 0;
  	}
      }
  
***************
*** 423,430 ****
  	}
  	return peek;
      }
-     if (lexstop)
- 	return (errflag) ? LEXERR : ENDINPUT;
      switch (lexact1[STOUC(c)]) {
      case LX1_BKSLASH:
  	d = hgetc();
--- 429,434 ----

sh compatibility again :->

[Andrej Borsenkow]

On Wed, 31 Jul 1996, Zoltan Hidvegi wrote:

> 
> Zsh can emulate the POSIX shell and the Korn shell quite well when it is
> invoked as sh or ksh respectively.  /bin/sh can be safely linked to zsh.
>                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I wouldn't put it in. I dared to link zsh to /bin/sh and reboot the
system. It did come up - without /proc, /dev/fd and network ;-<

Here are some points, where zsh choked.

1. It doesn't like malformed constructs like

A="`cat /some/file"    (note missed backtick)

zsh tries to parse command substitution behind closing double-quote, and
ends up with `missing "' at the end of script. Our /bin/sh stops at
closing double-quote. In POSIX the result is undefined - thus, techically
neither violate it. 

2. Our /bin/sh silently ignores break's in case statement (I mean it; it
doesn't break out of case). zsh loudly complaints (well, it is rather
cosmetic).

3. The last bit, when I stopped this experiment. Our sh starts complex
command with redirections in subshell; that is

while read;
do
....
done < /some/file

is evaluated in subshell. The problem is, that some scripts use EXIT!!
rather than break to such loop. Well, I could do nothing against it.


These are just FYI; in no way would I suggest to mimic every historical
(broken?) sh; but it still means, that it is *not* safe to link /bin/sh to
zsh on *every* system. Probably, statement about POSIX conformance is
enough?

But the following things could probably be fixed 

4. Traditional /bin/sh interprets `set -' as set +xv. It could be well
undocumented (it is not on our system) but still is so. Could anybody test
it on more than one systems? zsh silently sets positional parameters to
null. At least on our system many startup scripts include 

set -$DEBUG

at the script start (intent is to set DEBUG=x somewhere in /etc/rc2 to see
what's going on). Under zsh, script just loses its arguments and ends up
with error (it is SVR4 startup scripts are called with
/bin/sh /etc/rc2.d/S*something start
if `start' is not there, script just exits). 

5. Currently zsh sets BSD_ECHO when running as sh. Our sh does support
escapes in echo; I recall that SCO sh does it as well. I don't know about
others. What about relaxing it? If scripts doesn't rely upon escapes in
echo, it would make no harm.


Sorry for long mail. Actually (apart from echo) I found *no* problems,
caused by zsh; so it is more our /bin/sh to blame ;)

greetings

-------------------------------------------------------------------------
Andrej Borsenkow 		Fax:   +7 (095) 252 01 05
SNI ITS Moscow			Tel:   +7 (095) 252 13 88

NERV:  borsenkow.msk		E-Mail: borsenkow.msk@sni.de
-------------------------------------------------------------------------

Re: sh compatibility again :->

[Zoltan Hidvegi]

Andrej Borsenkow wrote:
[...]
> 1. It doesn't like malformed constructs like
> 
> A="`cat /some/file"    (note missed backtick)
> 
> zsh tries to parse command substitution behind closing double-quote, and
> ends up with `missing "' at the end of script. Our /bin/sh stops at
> closing double-quote. In POSIX the result is undefined - thus, techically
> neither violate it. 

I copied the behaviour of bash here.  pdksh also behaves this way.

> But the following things could probably be fixed 
> 
> 4. Traditional /bin/sh interprets `set -' as set +xv. It could be well
> undocumented (it is not on our system) but still is so. Could anybody test
> it on more than one systems? zsh silently sets positional parameters to
> null. At least on our system many startup scripts include 
> 
> set -$DEBUG
> 
> at the script start (intent is to set DEBUG=x somewhere in /etc/rc2 to see
> what's going on). Under zsh, script just loses its arguments and ends up
> with error (it is SVR4 startup scripts are called with
> /bin/sh /etc/rc2.d/S*something start
> if `start' is not there, script just exits). 

OK.  I've changed that.  set - will be the same as set +xv and
set - args will be the same as set +xv -- args.  This will not be
documented since it is just an obsolecent compatibility feature and
noone should use that.

> 5. Currently zsh sets BSD_ECHO when running as sh. Our sh does support
> escapes in echo; I recall that SCO sh does it as well. I don't know about
> others. What about relaxing it? If scripts doesn't rely upon escapes in
> echo, it would make no harm.

I'll try to write a configure check for the echo style of /bin/sh and use
that.

Zoltan

Re: sh compatibility again :->

[Bart Schaefer]

On Aug 12,  4:18am, Zoltan Hidvegi wrote:
} Subject: Re: sh compatibility again :->
}
} Andrej Borsenkow wrote:
} [...]
} > 1. It doesn't like malformed constructs like
} > 
} > A="`cat /some/file"    (note missed backtick)
} > 
} > zsh tries to parse command substitution behind closing double-quote, and
} > ends up with `missing "' at the end of script. Our /bin/sh stops at
} > closing double-quote. In POSIX the result is undefined - thus, techically
} > neither violate it. 
} 
} I copied the behaviour of bash here.  pdksh also behaves this way.

Right; if I recall correctly, bash and ksh both permit stuff like:

$ echo "foo `echo "bar baz"` boing"

That is, bash and ksh nest double quotes inside backticks.  Old-fashioned
Bourne shell, on the other hand, does NOT permit nesting of double quotes,
even inside backticks.  So in bash/ksh the above is parsed as

	(echo) (foo `echo "bar baz"` boing)

but in sh it is

	(echo) (foo `echo bar) (baz` boing)

The only way to resolve this would be with yet another option, SH_QUOTES
or some such.  Worth it?  Dunno.

} > But the following things could probably be fixed 
} > 
} > 4. Traditional /bin/sh interprets `set -' as set +xv.
} 
} OK.  I've changed that.  set - will be the same as set +xv and
} set - args will be the same as set +xv -- args.

Hmm.  So what's the approved way of setting $1 to "-x"?  `set -- -x`?
And is `set --` equivalent to `shift $#`, since `set -` is not?

Are you sure `set - args` should act like `set +xv -- args`?

I can't say I'm entirely excited about this change.

} > 5. Currently zsh sets BSD_ECHO when running as sh. Our sh does support
} > escapes in echo; I recall that SCO sh does it as well. I don't know about
} > others. What about relaxing it? If scripts doesn't rely upon escapes in
} > echo, it would make no harm.
} 
} I'll try to write a configure check for the echo style of /bin/sh and use
} that.

Eww, no.  Let's pick one behavior and stick with it, please.  The default
options, even in an emulation mode, shouldn't vary from one installation
to the next!  It's been a long time since I encountered an sh that didn't
have a builtin SysV-style echo -- BSD_ECHO is needed mostly for csh
compatibility.  I'd vote for leaving BSD_ECHO off when run as "sh".

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: sh compatibility again :->

[Zefram]

>Right; if I recall correctly, bash and ksh both permit stuff like:
>
>$ echo "foo `echo "bar baz"` boing"
>
>That is, bash and ksh nest double quotes inside backticks.  Old-fashioned
>Bourne shell, on the other hand, does NOT permit nesting of double quotes,
>even inside backticks.
...
>The only way to resolve this would be with yet another option, SH_QUOTES
>or some such.  Worth it?  Dunno.

Not worth it.  POSIX leaves the behaviour undefined IIRC, and there's
no advantage in the traditional behaviour.

>} I'll try to write a configure check for the echo style of /bin/sh and use
>} that.
>
>Eww, no.  Let's pick one behavior and stick with it, please.  The default
>options, even in an emulation mode, shouldn't vary from one installation
>to the next!  It's been a long time since I encountered an sh that didn't
>have a builtin SysV-style echo -- BSD_ECHO is needed mostly for csh
>compatibility.  I'd vote for leaving BSD_ECHO off when run as "sh".

I also recommend against a configure check, but for a different reason:
some widespread shs (notably SunOS and Solaris) vary their echo
behaviour depending on $PATH, trying to emulate what would happen if
echo weren't a builtin.  It's really quite difficult to reliably detect
this behaviour.  I suggest that the behaviour should remain as it is.

-zefram

Re: sh compatibility again :->

[Bart Schaefer]

On Aug 12,  6:00am, Zefram wrote:
} Subject: Re: sh compatibility again :->
}
} >The only way to resolve this would be with yet another option, SH_QUOTES
} >or some such.  Worth it?  Dunno.
} 
} Not worth it.  POSIX leaves the behaviour undefined IIRC, and there's
} no advantage in the traditional behaviour.

You're right about POSIX, but since it makes a pretty radical difference
to the parse of a script containing unbalanced backticks, the advantage
to the traditional behavior is to be able to execute traditional scripts.
We can decide that's not very important, but it is something.

BTW:  Zoltan:  Welcome back. ;-)

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: sh compatibility again :->

[Andrej Borsenkow]

On Sun, 11 Aug 1996, Bart Schaefer wrote:

> 
> } > But the following things could probably be fixed 
> } > 
> } > 4. Traditional /bin/sh interprets `set -' as set +xv.
> } 
> } OK.  I've changed that.  set - will be the same as set +xv and
> } set - args will be the same as set +xv -- args.
> 
> Hmm.  So what's the approved way of setting $1 to "-x"?  `set -- -x`?
> And is `set --` equivalent to `shift $#`, since `set -` is not?
> 
> Are you sure `set - args` should act like `set +xv -- args`?
> 

Well, /bin/sh behaves execatly this way.

> I can't say I'm entirely excited about this change.
> 

It is lonely `set -' which have this effect. Just the same, as lonely `set
+' does *not* sets $1 to + but rather outputs all parameter names. If I
try `set + foo', it sets $1 to `foo'. So `set -' could just follow the
suit.

Greetings

-------------------------------------------------------------------------
Andrej Borsenkow 		Fax:   +7 (095) 252 01 05
SNI ITS Moscow			Tel:   +7 (095) 252 13 88

NERV:  borsenkow.msk		E-Mail: borsenkow.msk@sni.de
-------------------------------------------------------------------------

Re: sh compatibility again :->

[Bart Schaefer]

} The only way to resolve this would be with yet another option, SH_QUOTES
} or some such.  Worth it?  Dunno.

This is a ridiculously simple patch, so in case anybody wants it ... note
that this makes live the DPUTS(!*str, "Oops ...") error in the walk-off-
end-of-a-string loop for which I sent a patch last week, so you probably
want that earlier patch as well.

The only question about this patch is whether

+    int shq = (endchar == '"' && isset(SHQUOTES));

ought to be

+    int shq = ((endchar == '\0' || endchar == '"') && isset(SHQUOTES));

I actually think perhaps it should.

--- Src/globals.h.0	Sun Aug  4 21:15:43 1996
+++ Src/globals.h	Sun Aug 11 23:20:21 1996
@@ -764,6 +764,7 @@
     {"shinstdin", 		's',  's',  OPT_SPECIAL},
     {"shoptionletters",		0,    0,    OPT_EMULATE|OPT_BOURNE},
     {"shortloops", 		0,    0,    OPT_ALL},
+    {"shquotes", 		0,    0,    OPT_EMULATE|OPT_SH},
     {"shwordsplit", 		'y',  0,    OPT_EMULATE|OPT_BOURNE},
     {"singlecommand",		't',  't',  OPT_SPECIAL},
     {"singlelinezle", 		'M',  0,    OPT_KSH},
--- Src/lex.c.0	Sun Aug  4 23:09:29 1996
+++ Src/lex.c	Sun Aug 11 23:16:28 1996
@@ -1000,10 +1000,11 @@
     int c;
     int math = endchar == ')' || endchar == ']';
     int zlemath = math && cs > ll + addedx - inbufct;
+    int shq = (endchar == '"' && isset(SHQUOTES));
 
     while (((c = hgetc()) != endchar || bct ||
 	    (math && ((pct > 0) || (brct > 0))) ||
-	    intick) && !lexstop) {
+	    (intick && !shq)) && !lexstop) {
       cont:
 	switch (c) {
 	case '\\':
--- Src/zsh.h.0	Sun Aug  4 21:15:44 1996
+++ Src/zsh.h	Sun Aug 11 23:17:10 1996
@@ -1146,6 +1146,7 @@
     SHINSTDIN,
     SHOPTIONLETTERS,
     SHORTLOOPS,
+    SHQUOTES,
     SHWORDSPLIT,
     SINGLECOMMAND,
     SINGLELINEZLE,

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: sh compatibility again :->

[whukriede]

Hi!

Zoltan wrote:
> Andrej Borsenkow wrote:
>> 4. Traditional /bin/sh interprets `set -' as set +xv. It could be well
>> undocumented (it is not on our system) but still is so. Could anybody test
>> it on more than one systems? zsh silently sets positional parameters to
...
> OK.  I've changed that.  set - will be the same as set +xv and
> set - args will be the same as set +xv -- args.  This will not be
> documented since it is just an obsolecent compatibility feature and
> noone should use that.

Excerpt from the BSD 4.3 sh(1) manual page:

     set [-eknptuvx [arg ...]]

     ....

     -v Print shell input lines as they are read.
     -x Print commands and their arguments as they are exe-
        cuted.
     -  Turn off the -x and -v options.

Greetings, Wolfgang.