Re: sh compatibility again :->

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.

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 :->

[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]

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 :->

[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,  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 :->

[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

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
-------------------------------------------------------------------------