Procmail rejects zsh as being "broken"

Procmail rejects zsh as being "broken"

[Andrej Borsenkow]

Hi!

I recently installed procmail-3.11pre4 under zsh-3.0pre4. When running
'make init' procmail gave me warning, that `/opt/local/bin/zsh is broken'.
I checked initmake script and here is relevant part:

case "$SHELL" in
 ...
       *zsh*) $RM src/_autotst
            $SHELL <<HERE
            O="echo test >src/_autotst"
            exec 2>$DEVNULL
            \$O
HERE                                                                            
           if test ! -f src/_autotst                                            
           then
              echo "Warning: your $SHELL is broken, avoiding it"; SHELL=""
           fi ;;

The test seems to imply, that in
% foo="echo test > test"
% $foo

the line is to be rescanned for I/O redirections *after* foo is expanded. 
I am not aware of any shell to behave this way. 

Do I  miss something? What is the sense of this test? And why it is done
only for zsh ;)?

thanks in advance

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: Procmail rejects zsh as being "broken"

[Peter Stephenson]

borsenkow.msk@sni.de wrote:
> Hi!
> 
> I recently installed procmail-3.11pre4 under zsh-3.0pre4. When running
> 'make init' procmail gave me warning, that `/opt/local/bin/zsh is broken'.
> I checked initmake script and here is relevant part:
> 
> case "$SHELL" in
>  ...
>        *zsh*) $RM src/_autotst
>             $SHELL <<HERE
>             O="echo test >src/_autotst"
>             exec 2>$DEVNULL
>             \$O
> HERE                                                                         
>    
>            if test ! -f src/_autotst                                         
>    
>            then
>               echo "Warning: your $SHELL is broken, avoiding it"; SHELL=""
>            fi ;;
> 
> The test seems to imply, that in
> % foo="echo test > test"
> % $foo
> 
> the line is to be rescanned for I/O redirections *after* foo is expanded. 
> I am not aware of any shell to behave this way. 
> 
> Do I  miss something? What is the sense of this test? And why it is done
> only for zsh ;)?

No, I think it's an incorrect test:  it should probably be something like
O="touch src/_autost"
if what they're doing is testing for word splitting.  But if that *is*
the point, since the test is only for zsh, why don't they simply issue
`setopt shwordsplit' which works in every single version of zsh?

-- 
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: Procmail rejects zsh as being "broken"

[Stephen R. van den Berg]

borsenkow.msk@sni.de <borsenkow.msk@sni.de> wrote:
>I recently installed procmail-3.11pre4 under zsh-3.0pre4. When running
>'make init' procmail gave me warning, that `/opt/local/bin/zsh is broken'.
>I checked initmake script and here is relevant part:

>case "$SHELL" in
> ...
>       *zsh*) $RM src/_autotst
>            $SHELL <<HERE
>            O="echo test >src/_autotst"
>            exec 2>$DEVNULL
>            \$O
>HERE                                                                            
>           if test ! -f src/_autotst 
>           then
>              echo "Warning: your $SHELL is broken, avoiding it"; SHELL=""
>           fi ;;

>The test seems to imply, that in
>% foo="echo test > test"
>% $foo

>the line is to be rescanned for I/O redirections *after* foo is expanded. 
>I am not aware of any shell to behave this way. 

You're right.  Sorry, my mistake.  The test is a bit too rigorous, it
now fails on every shell (which just had the effect that it never used
the zsh, which is why I never noticed the problem, of course).  The intent
was to check for something else.

>Do I  miss something? What is the sense of this test? And why it is done
>only for zsh ;)?

The test should have read (fixed in the next release :-):

        *zsh*) $RM src/_autotst
            $SHELL <<HERE
            O="echo test"
            exec 2>$DEVNULL 1>&2
            \$O && echo test >src/_autotst
HERE

As to why it is just being tested on zsh, well, that's the only shell
that (ever) exhibited this (broken) behaviour.
-- 
Sincerely,                                                          srb@cuci.nl
           Stephen R. van den Berg (AKA BuGless).
Auto repair rates: basic labor $40/hour; if you wait, $60; if you watch, $80;
if you ask questions, $100; if you help, $120; if you laugh, $140.

Re: Procmail rejects zsh as being "broken"

[Peter Stephenson]

srb@cuci.nl wrote:
> The test should have read (fixed in the next release :-):
> 
>         *zsh*) $RM src/_autotst
>             $SHELL <<HERE
>             O="echo test"
>             exec 2>$DEVNULL 1>&2
>             \$O && echo test >src/_autotst
> HERE
> 
> As to why it is just being tested on zsh, well, that's the only shell
> that (ever) exhibited this (broken) behaviour.

It's *not* broken.  See the FAQ.  Zsh has arrays if you want the
variable to have separate words.  Having it splitting on every single
space in every single variable is the broken behaviour, inherited from
the time when arrays didn't exist.  None of the developers think this
should be the default behaviour (I have never heard any dissenters,
feel free to speak out).  The default behaviour is different in more
subtle ways anyway.  The object is to make a usable shell, not one
with every builtin historical limitation.

To more practical matters:  I suggest the test be

        *zsh*) $RM src/_autotst
	    setopt shwordsplit
            $SHELL <<HERE
            O="echo test"
            exec 2>$DEVNULL 1>&2
            \$O && echo test >src/_autotst
HERE

(i.e. with the added setopt line) since it's zsh-specific anyway.
This works in all versions of zsh to implement the sh behaviour.

-- 
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: Procmail rejects zsh as being "broken"

[Zefram]

>        *zsh*) $RM src/_autotst
>	    setopt shwordsplit
>            $SHELL <<HERE
>            O="echo test"
>            exec 2>$DEVNULL 1>&2
>            \$O && echo test >src/_autotst
>HERE

Shouldn't the setopt be inside the here document?  Or, more simply,
drop the test and just use the setopt.

-zefram

Re: Procmail rejects zsh as being "broken"

[Peter Stephenson]

a.main@dcs.warwick.ac.uk wrote:
> >        *zsh*) $RM src/_autotst
> >	    setopt shwordsplit
> >            $SHELL <<HERE
> >            O="echo test"
> >            exec 2>$DEVNULL 1>&2
> >            \$O && echo test >src/_autotst
> >HERE
> 
> Shouldn't the setopt be inside the here document?  Or, more simply,
> drop the test and just use the setopt.

Having not seen the rest of the script, I was assuming this got
executed for any zsh and hence turns the option on globally.  The test
is then just for paranoia.

-- 
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: Procmail rejects zsh as being "broken"

[Zefram]

>Having not seen the rest of the script, I was assuming this got
>executed for any zsh and hence turns the option on globally.  The test
>is then just for paranoia.

The test appears to invoke another copy of the shell, which won't
necessarily have the option set.

-zefram

Re: Procmail rejects zsh as being "broken"

[Peter Stephenson]

a.main@dcs.warwick.ac.uk wrote:
> The test appears to invoke another copy of the shell, which won't
> necessarily have the option set.

Yup, srb's last message put me right on this score.  Seems there's
nothing to be done in this case.

-- 
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: Procmail rejects zsh as being "broken"

[Stephen R. van den Berg]

Peter Stephenson <pws@ifh.de> wrote:
>It's *not* broken.  See the FAQ.  Zsh has arrays if you want the
>variable to have separate words.  Having it splitting on every single
>space in every single variable is the broken behaviour, inherited from
>the time when arrays didn't exist.

In zsh's eyes, it's a feature, no doubt.  If zsh pretends to be Bourne
shell compatible, it's a bug.

During the installation, I'm trying to determine if the shell that's being
used is at least basically Bourne shell compatible.  The zsh doesn't qualify,
at least not when it exhibits this behaviour by default.

>feel free to speak out).  The default behaviour is different in more
>subtle ways anyway.  The object is to make a usable shell, not one
>with every builtin historical limitation.

I have no problems with that, but if that is the case, the make utility
should *not* be allowed to pass on SHELL=/bin/zsh, because it's not Bourne
shell compatible.

>To more practical matters:  I suggest the test be

>        *zsh*) $RM src/_autotst
>	    setopt shwordsplit
>            $SHELL <<HERE
>            O="echo test"
>            exec 2>$DEVNULL 1>&2
>            \$O && echo test >src/_autotst
>HERE

>(i.e. with the added setopt line) since it's zsh-specific anyway.
>This works in all versions of zsh to implement the sh behaviour.

That's exactly the point.  I can't go in and change *every* shell script
to use "setopt shwordsplit" at the start just to make sure that it
works with a zsh (and generates an error with every other shell).
I intend to check if the default behaviour of the shell is Bourne
shell compatible.  And if the test fails, it isn't.
-- 
Sincerely,                                                          srb@cuci.nl
           Stephen R. van den Berg (AKA BuGless).
Auto repair rates: basic labor $40/hour; if you wait, $60; if you watch, $80;
if you ask questions, $100; if you help, $120; if you laugh, $140.

Re: Procmail rejects zsh as being "broken"

[Zoltan Hidvegi]

Stephen R. van den Berg <srb@cuci.nl> wrote:
> Peter Stephenson <pws@ifh.de> wrote:
> >It's *not* broken.  See the FAQ.  Zsh has arrays if you want the
> >variable to have separate words.  Having it splitting on every single
> >space in every single variable is the broken behaviour, inherited from
> >the time when arrays didn't exist.
> 
> In zsh's eyes, it's a feature, no doubt.  If zsh pretends to be Bourne
> shell compatible, it's a bug.

Well, when zsh is invoked as zsh it does not pretend to be Bourne shell
compatible.  That's not a bug.  Zsh is really Bourne compatible if called
as sh.  The complicated *zsh* test in procmail is unnecessary.  It'll never
work.  The problem is that procmail tells that zsh is broken.  Zsh is not
broken, it is simply different from a Bourne shell when invoked as zsh.
Procmail should just inform the user that it uses /bin/sh or whatever
instead of zsh and should not spread misinformation about zsh.

Zoltan

Re: Procmail rejects zsh as being "broken"

[Bruce Stephens]

> Well, when zsh is invoked as zsh it does not pretend to be Bourne shell
> compatible.  That's not a bug.  Zsh is really Bourne compatible if called
> as sh.  The complicated *zsh* test in procmail is unnecessary.  It'll never
> work.  The problem is that procmail tells that zsh is broken.  Zsh is not
> broken, it is simply different from a Bourne shell when invoked as zsh.
> Procmail should just inform the user that it uses /bin/sh or whatever
> instead of zsh and should not spread misinformation about zsh.
> 
> Zoltan

Darn.  I was about to say this.  It's perfectly reasonable for the
package to default to /bin/sh, since I don't care what shell it uses,
for the most part.  And /bin/sh might well be zsh in disguise, but
that's OK because when invoked as /bin/sh, it'll work as procmail
expects.

--
Bruce Stephens			| email: B.Stephens@math.ruu.nl
Utrecht University              | telephone: +31 30 2534630
Department of Mathematics       | telefax:   +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht |
The Netherlands                 |

Re: Procmail rejects zsh as being "broken"

[Stephen R. van den Berg]

Zoltan Hidvegi <hzoli@cs.elte.hu> wrote:
>Well, when zsh is invoked as zsh it does not pretend to be Bourne shell
>compatible.

Ah, a misconception on my part.  I've always seen zsh "advertised" as
Bourne shell compatible.

>as sh.  The complicated *zsh* test in procmail is unnecessary.  It'll never
>work.

I didn't know that.  I thought it was an oversight of zsh developers in
the default settings of zsh.  Now I know better, of course.

>  The problem is that procmail tells that zsh is broken.  Zsh is not
>broken, it is simply different from a Bourne shell when invoked as zsh.
>Procmail should just inform the user that it uses /bin/sh or whatever
>instead of zsh and should not spread misinformation about zsh.

Fair enough.  The problem in this case transposes itself to "make" then.
"make" *has* to make that SHELL is set to a Bourne shell compatible
shell.  If it leaves it at zsh, it's a bug.

In that light, we'll avoid the test and change the diagnostics to:
===================================================================
RCS file: /var/lib/cvs/procmail/initmake,v
retrieving revision 1.66
diff -u -r1.66 initmake
--- initmake	1996/07/29 18:48:23	1.66
+++ initmake	1996/08/01 14:42:50
@@ -23,7 +23,7 @@
   case "$BSHELL" in
      *zsh*) ;;
      *) echo "(If I wouldn't know better, I'd say you're trying to sell"
-	echo "me a buggy zsh :-)" ;;
+	echo "me an incompatible zsh :-)" ;;
   esac
   echo "Please edit the Makefile and try setting BSHELL to a shell which"
   echo "is more backwards compatible with a Bourne, Korn or POSIX shell."
@@ -55,17 +55,7 @@
 case "$SHELL" in
   *sh*)
      case "$SHELL" in
-	*csh*) echo "Warning: really perverted make detected"; SHELL="";;
-	*zsh*) $RM src/_autotst
-	    $SHELL <<HERE
-	    O="echo test >src/_autotst"
-	    exec 2>$DEVNULL
-	    \$O
-HERE
-	   if test ! -f src/_autotst
-	   then
-	      echo "Warning: your $SHELL is broken, avoiding it"; SHELL=""
-	   fi ;;
+	*[zc]sh*) echo "Warning: really perverted make detected"; SHELL="";;
      esac
      if test ! -z "$SHELL"
      then
-- 
Sincerely,                                                          srb@cuci.nl
           Stephen R. van den Berg (AKA BuGless).
Auto repair rates: basic labor $40/hour; if you wait, $60; if you watch, $80;
if you ask questions, $100; if you help, $120; if you laugh, $140.

Re: Procmail rejects zsh as being "broken"

[Zoltan Hidvegi]

> Fair enough.  The problem in this case transposes itself to "make" then.
> "make" *has* to make that SHELL is set to a Bourne shell compatible
> shell.  If it leaves it at zsh, it's a bug.

For exactly that reason GNU make simply ignores the SHELL environment
variable and sets it to /bin/sh.  I do not know how other makes behave but
they should do the same.

Zoltan

Re: Procmail rejects zsh as being "broken"

[Zefram]

>For exactly that reason GNU make simply ignores the SHELL environment
>variable and sets it to /bin/sh.  I do not know how other makes behave but
>they should do the same.

I always set SHELL to /bin/sh explicitly in Makefiles.  GNU standards
recommend this too.  This is really an example of the now deeply
ingrained double usage of SHELL -- to specify the preferred interactive
shell and the standard shell.  Too many programs confuse the two
concepts and end up using $SHELL (zsh in my case) when they really want
a Bourne shell (/bin/sh on every Unix system I've ever heard of).

-zefram

Re: Procmail rejects zsh as being "broken"

[Zefram]

>+	*[zc]sh*) echo "Warning: really perverted make detected"; SHELL="";;

Wouldn't it be better to do the feature tests, ignoring the name in
$SHELL?  Maybe some perverted admin has a copy of sh under the name
zsh.  Or even better, just use /bin/sh, which is Bourne-compatible
everywhere, rather than accepting whatever $SHELL happens to be.

-zefram

Re: Procmail rejects zsh as being "broken"

[Stephen R. van den Berg]

Zefram <A.Main@dcs.warwick.ac.uk> wrote:
>I always set SHELL to /bin/sh explicitly in Makefiles.  GNU standards
>recommend this too.  This is really an example of the now deeply

Well, it's not that easy.
For a real POSIX environment, you could simply omit setting SHELL, since
the make utility will *always* set it to a /bin/sh compatible shell.

For non-posix environments, it gets a bit tricky.  Some makes set it,
some don't, some makes export the SHELL assignment to the environment,
some don't.  Then there is the possibility that the /bin/sh is a buggy
implementation with way too many bugs (some vendors delivered this
with their system).  So the users typically went and got themselves
a different shell (like pdksh, bash, zsh, whatever).  Now, if the
user is using that as his loginshell, and the shell is Bourne shell
compatible, then we'll try to use that one first.

Which is exactly why I was bothering with the zsh (in case it was more
/bin/sh compatible than the original /bin/sh installed on the system; why
wouldn't they replace the /bin/sh with a link to zsh, well, lots of
reasons: he's not the sysadmin, company policy, etc.).

>>+	*[zc]sh*) echo "Warning: really perverted make detected"; SHELL="";;

>Wouldn't it be better to do the feature tests, ignoring the name in
>$SHELL?  Maybe some perverted admin has a copy of sh under the name
>zsh.

Feature tests are difficult to make comprehensive.

>  Or even better, just use /bin/sh, which is Bourne-compatible
>everywhere, rather than accepting whatever $SHELL happens to be.

Not such a good idea, see above.
-- 
Sincerely,                                                          srb@cuci.nl
           Stephen R. van den Berg (AKA BuGless).
Auto repair rates: basic labor $40/hour; if you wait, $60; if you watch, $80;
if you ask questions, $100; if you help, $120; if you laugh, $140.