Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

[Clint Adams]

> This is very simple. zsh is not to be considered a ksh.
> This simple command fails using zsh as ksh (I did update-alternatives) :
> 
> 	trap 'echo alert-an-error-occured' ERR
> 
> This simple command succeeds with `normal/standard' ksh, tested with :
> 	Solaris ksh,
> 	OSF1 ksh,
> 	AIX ksh,
> 	pdksh (debian sarge),
> 	www.kornshell.com ksh.
> 
> I hope you will remove this alternative before too many scripts break...

Recently, the Debian packages for ksh93, pdksh, and zsh cooperated to
provide alternatives for /bin/ksh.  This was done without defining any
exact requirements, so at the present time, it is de facto "the
intersection of ksh93, pdksh, and zsh".

Unless this bug is deemed release-critical (I doubt it will be), the
upcoming Debian release will allow zsh to easily be /bin/ksh.

P.S., someone left conflict cruft in ChangeLog.

Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

[Bart Schaefer]

On May 26,  3:15pm, Clint Adams wrote:
} Subject: Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).
}
} > This simple command fails using zsh as ksh (I did update-alternatives) :
} > 
} > 	trap 'echo alert-an-error-occured' ERR

Zsh does not provide an ERR trap because some platforms on which zsh can be
compiled actually have SIGERR defined, which is a real OS-level signal and
not interchangeable with the ksh et al. use of ERR as a magic trap.

The zsh equivalent is

	trap 'echo alert-an-error-occured' ZERR

A possible workaround would be

	(( $signals[(I)ERR] )) || alias -g ERR=ZERR

} P.S., someone left conflict cruft in ChangeLog.

"cvs annotate" is great for finding someones.

I deleted the cruft.

Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

[Christophe Martin]

Clint Adams a écrit :

> Recently, the Debian packages for ksh93, pdksh, and zsh cooperated to
> provide alternatives for /bin/ksh.  This was done without defining any
> exact requirements, so at the present time, it is de facto "the
> intersection of ksh93, pdksh, and zsh".
IMHO, this can only lead to confusion. if one installs zsh as ksh, he
might use commands that are not supported by "historical" ksh,
and "historical" scripts may not run.

Why not add ash, dash, bash and so on, into the ksh pool, until
only "a=foo" and "echo bar" are the common points ? surely because
all of us have an idea of what ksh should be, only this idea is a
bit different for each of us.

I realize there are many differences between implementations of
shells. There must be some incompatibilities between pdksh and ksh.
But this trap ERR thing seems to be a basic ksh functionnality.

Last, zsh is such a special shell, with all its exotic and powerful
functionalities, that when you need/want it, it is unlikely
you want it as a ksh. Debian already have 2 ksh...

>
> Unless this bug is deemed release-critical (I doubt it will be), the
> upcoming Debian release will allow zsh to easily be /bin/ksh.

I definitely hope that the alternative will be removed...

	Have a nice weekend,
	Christophe
-- char*p="c+)1+)I1+++(Y1)I1)1)I1)19Y(QII1)1)I1)19Q(K)K+)I1+9I(a)I1)II1))AA(91)I\
1)II1)199(3+)1)K+)19;(";main(_){while(*p){for(_=*p-32>>3;_;--_)putchar(' ');if
(!(_=*p++-32&7))putchar('\n');else while(_--)printf("_/");}}

Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

[Christophe Martin]

Hi,

Bart Schaefer a écrit :
>
> Zsh does not provide an ERR trap because some platforms on which zsh can be
> compiled actually have SIGERR defined, which is a real OS-level signal and
> not interchangeable with the ksh et al. use of ERR as a magic trap.
>
> The zsh equivalent is
>
> 	trap 'echo alert-an-error-occured' ZERR
Don't you think it's strange to trap a Zsomething in Ksh ??

>
> A possible workaround would be
>
> 	(( $signals[(I)ERR] )) || alias -g ERR=ZERR
>
Waow ! That's knowing zsh !

But, If i keep zsh as ksh
I have to rewrite every script to put this workaround in.

On the other hand, if I ever run the modified script with the more
traditionnal ksh, the workaround fails.

So, for this particular problem of trap ERR, there are only problems
in using zsh as a ksh, at least on platform where ksh ERR does not
conflict with OS SIGERR. (By the way, what are the platform with OS
SIGERR ? And do some ksh run on them ?)

	Regards,
	Christophe
-- 
char*p="c+)1+)I1+++(Y1)I1)1)I1)19Y(QII1)1)I1)19Q(K)K+)I1+9I(a)I1)II1))AA(91)I\
1)II1)199(3+)1)K+)19;(";main(_){while(*p){for(_=*p-32>>3;_;--_)putchar(' ');
if (!(_=*p++-32&7))putchar('\n');else while(_--)printf("_/");}}

Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

[Bart Schaefer]

On May 27,  2:50pm, Christophe Martin wrote:
} Subject: Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).
}
} Bart Schaefer a écrit :
} >
} > A possible workaround would be
} >
} > 	(( $signals[(I)ERR] )) || alias -g ERR=ZERR
} 
} But, If i keep zsh as ksh
} I have to rewrite every script to put this workaround in.

No, you just have to put the above in /etc/zshenv, which is read by all
instances of zsh, whether script or interactive.

} So, for this particular problem of trap ERR, there are only problems
} in using zsh as a ksh

That's not the only incompatibility, by a long shot.  Don't try scripts
using namerefs or discipline functions, for example.

} (By the way, what are the platform with OS
} SIGERR ? And do some ksh run on them ?)

UNICOS, according to the Zsh FAQ.  I have no idea whether ksh has been
ported to that.

Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

[Christophe Martin]

Bart Schaefer a écrit :
> No, you just have to put the above in /etc/zshenv, which is read by all
> instances of zsh, whether script or interactive.

I wish you were right, this would solve the problem. but according
to zsh man page :
       In sh and ksh compatibility modes
       [snip...]
       The  usual zsh startup/shutdown scripts are not executed.

I just tried to put ": > /tmp/zsh.$$" in /etc/zsh/zshenv and run ksh (the
symlink to zsh)... No file were present in /tmp :-(

> That's not the only incompatibility, by a long shot.  Don't try scripts
> using namerefs or discipline functions, for example.
No doubt. But as I wrote in reply to Clint message, we all have different
idea of what a 'ksh' should be.
I originally sent the report because I *feel* a trap on ERR was such a
basic thing that any ksh should implement it.

I learned life is not that simple, and one OS uses SIGERR just to make life
harder for every one.

Now, unless you have another workaround, it seems there is no
simple way to solve this.

I can only hope Debian maintainers will agree with me, and perhaps some
zsh-workers too ;-)

> } (By the way, what are the platform with OS
> } SIGERR ? And do some ksh run on them ?)
> 
> UNICOS, according to the Zsh FAQ.  I have no idea whether ksh has been
> ported to that.
Thanks for the info.

Going back to real life,
Regards.
-- 
char*p="c+)1+)I1+++(Y1)I1)1)I1)19Y(QII1)1)I1)19Q(K)K+)I1+9I(a)I1)II1))AA(91)I\
1)II1)199(3+)1)K+)19;(";main(_){while(*p){for(_=*p-32>>3;_;--_)putchar(' ');if
(!(_=*p++-32&7))putchar('\n');else while(_--)printf("_/");}}

Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

[Clint Adams]

> Why not add ash, dash, bash and so on, into the ksh pool, until
> only "a=foo" and "echo bar" are the common points ? surely because
> all of us have an idea of what ksh should be, only this idea is a
> bit different for each of us.

None of those shells purport to emulate ksh.  zsh does.

> I realize there are many differences between implementations of
> shells. There must be some incompatibilities between pdksh and ksh.
> But this trap ERR thing seems to be a basic ksh functionnality.

I don't have enough knowledge of ksh to evaluate that statement.

> Last, zsh is such a special shell, with all its exotic and powerful
> functionalities, that when you need/want it, it is unlikely
> you want it as a ksh. Debian already have 2 ksh...

The zsh alternative was suggested by the Debian ksh93
maintainer.

> I definitely hope that the alternative will be removed...

It's not a high-priority alternative.  That means that it won't be
selected automatically over either pdksh or ksh93.  One would need
to either only have zsh installed or override the defaults.  Since
the Debian zsh package is frozen for a June 6 release, the severity
of your problem will not justify a change to the package.

After that, we can do one of three things: leave things the way they
are; remove the alternative; patch the source or cause zsh to understand
the ERR pseudo-signal within ksh emulation in another manner.

If the wise people on zsh-workers think that not understanding ERR is
acceptable for ksh emulation, I'm inclined to do nothing.

Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

[Bart Schaefer]

On May 30, 10:06am, Clint Adams wrote:
} Subject: Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).
}
} If the wise people on zsh-workers think that not understanding ERR is
} acceptable for ksh emulation, I'm inclined to do nothing.

Please note that I was not making any sort of judgement about whether
zsh *ought* to treat ERR differently in ksh mode.  I merely explained
why zsh behaves the way it does.  (Google indicates that ksh does run
on UNICOS; I wonder what it does with ERR in that case.)

I note in passing that "trap" in zsh doesn't understand all the same
signals that "kill" does.  For example, when the OS defines both, "kill"
understands SIGIO as a synonym for SIGPOLL and SIGCLD for SIGCHLD, but
"trap" only knows CHLD and POLL.

Perhaps the "alt_sigs" code should be factored out of jobs.c [*] and
extended to cover SIGERR as well.  Whether that's enabled only in ksh
emulation is a second question.

[*] Or perhaps bin_trap() should be moved *to* jobs.c.

Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

[Oliver Kiddle]

Bart wrote:
> (Google indicates that ksh does run
> on UNICOS; I wonder what it does with ERR in that case.)

I tried asking on ast-users and received the following answer from Glenn
Fowler:

| ksh does not currently handle this
| but I talked with David Korn and the next release will do the following
| 
| the "SIG" prefix is optional for trap and kill, e.g., "HUP" == "SIGHUP"
| the change will be to do only a signal lookup when a "SIG" prefix is specified,
| and a shell trap name lookup followed by a signal lookup otherwise
| 
| so, on systems like unicos that have SIGERR, the trap name "SIGERR" refers
| to the signal, and "ERR" refers to the shell trap on error
| "SIGERR" on systems with no SIGERR signal will fail
| 
| this approach will handle all future non-posix signal/shell-trap clashes,
| e.g., if some system invents SIGEXIT

That would seem a far better solution to me than having a separate ZERR,
especially as it deals with future conflicts. Would it be hard for us to
do that same in zsh? We can always keep ZERR for backward compatibility.

Oliver


This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

[Peter Stephenson]

Bart Schaefer wrote:
> I note in passing that "trap" in zsh doesn't understand all the same
> signals that "kill" does.  For example, when the OS defines both, "kill"
> understands SIGIO as a synonym for SIGPOLL and SIGCLD for SIGCHLD, but
> "trap" only knows CHLD and POLL.

How did you work this out?

% grep SIGIO /usr/include/asm/signal.h
#define SIGIOT           6
#define SIGIO           29
#define SIGPOLL         SIGIO
% trap 'echo foo' POLL
% trap
trap -- 'echo foo' POLL
% trap 'echo bar' IO
% trap
trap -- 'echo bar' POLL

Currently SIGPOLL is always the basic signal because there isn't an easy
way of deciding, although the form of the header suggests SIGIO is more
basic here.  With the existing code this causes the trap always to be
listed as POLL.  I've fixed this in the patch below.  It doesn't help
with the $signals array, however.  (Function traps always showed up
under the original name.)

Adding SIGERR as an alias where there's no system signal is trivial.
Now it should show up in the trap lists under ERR, too.  I've removed
the ALT_SIGS definition because there isn't really any justification for
making the mechanism optional now.

Index: Doc/Zsh/func.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/func.yo,v
retrieving revision 1.9
diff -u -r1.9 func.yo
--- Doc/Zsh/func.yo	1 Apr 2005 12:04:22 -0000	1.9
+++ Doc/Zsh/func.yo	1 Jun 2005 10:25:59 -0000
@@ -222,11 +222,14 @@
 or when the current function exits if defined inside a function.
 )
 findex(TRAPZERR)
+findex(TRAPERR)
 item(tt(TRAPZERR))(
 Executed whenever a command has a non-zero exit status.  However, the
 function is not executed if the command occurred in a sublist followed by
 `tt(&&)' or `tt(||)'; only the final command in a sublist of this type
-causes the trap to be executed.
+causes the trap to be executed.  The function tt(TRAPERR) acts the same as
+tt(TRAPZERR) on systems where there is no tt(SIGERR) (this is the usual
+case).
 )
 enditem()
 
Index: Src/builtin.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v
retrieving revision 1.137
diff -u -r1.137 builtin.c
--- Src/builtin.c	25 Apr 2005 10:18:33 -0000	1.137
+++ Src/builtin.c	1 Jun 2005 10:26:00 -0000
@@ -4978,13 +4978,14 @@
 		    shfunctab->printnode(hn, 0);
 		DPUTS(!hn, "BUG: I did not find any trap functions!");
 	    } else if (sigtrapped[sig]) {
+		char *name = getsigname(sig);
 		if (!siglists[sig])
-		    printf("trap -- '' %s\n", sigs[sig]);
+		    printf("trap -- '' %s\n", name);
 		else {
 		    s = getpermtext(siglists[sig], NULL);
 		    printf("trap -- ");
 		    quotedzputs(s, stdout);
-		    printf(" %s\n", sigs[sig]);
+		    printf(" %s\n", name);
 		    zsfree(s);
 		}
 	    }
@@ -5017,14 +5018,25 @@
     /* set traps */
     for (; *argv; argv++) {
 	Eprog t;
+	int flags;
 
 	sig = getsignum(*argv);
 	if (sig == -1) {
 	    zwarnnam(name, "undefined signal: %s", *argv, 0);
 	    break;
 	}
+	if (!strcmp(sigs[sig], *argv))
+	    flags = 0;
+	else {
+	    /*
+	     * Record that the signal is used under an assumed name.
+	     * If we ever have more than one alias per signal this
+	     * will need improving.
+	     */
+	    flags = ZSIG_ALIAS;
+	}
 	t = dupeprog(prog, 0);
-	if (settrap(sig, t, 0))
+	if (settrap(sig, t, flags))
 	    freeeprog(t);
     }
     return *argv != NULL;
Index: Src/jobs.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/jobs.c,v
retrieving revision 1.38
diff -u -r1.38 jobs.c
--- Src/jobs.c	28 Feb 2005 14:29:12 -0000	1.38
+++ Src/jobs.c	1 Jun 2005 10:26:00 -0000
@@ -1819,18 +1819,6 @@
     return retval;
 }
 
-#if defined(SIGCHLD) && defined(SIGCLD)
-#if SIGCHLD == SIGCLD
-#define ALT_SIGS 1
-#endif
-#endif
-#if defined(SIGPOLL) && defined(SIGIO)
-#if SIGPOLL == SIGIO
-#define ALT_SIGS 1
-#endif
-#endif
-
-#ifdef ALT_SIGS
 const struct {
     const char *name;
     int num;
@@ -1845,9 +1833,15 @@
     { "IO", SIGIO },
 #endif
 #endif
+#if !defined(SIGERR)
+    /*
+     * If SIGERR is not defined by the operating system, use it
+     * as an alias for SIGZERR.
+     */
+    { "ERR", SIGZERR },
+#endif
     { NULL, 0 }
 };
-#endif
 
 /* kill: send a signal to a process.  The process(es) may be specified *
  * by job specifier (see above) or pid.  A signal, defaulting to       *
@@ -1879,7 +1873,6 @@
 			    for (sig = 1; sig <= SIGCOUNT; sig++)
 				if (!cstrpcmp(sigs + sig, &signame))
 				    break;
-#ifdef ALT_SIGS
 			    if (sig > SIGCOUNT) {
 				int i;
 
@@ -1890,7 +1883,6 @@
 					break;
 				    }
 			    }
-#endif
 			    if (sig > SIGCOUNT) {
 				zwarnnam(nam, "unknown signal: SIG%s",
 					 signame, 0);
@@ -1953,7 +1945,6 @@
 			break;
 		if (*signame == '0' && !signame[1])
 		    sig = 0;
-#ifdef ALT_SIGS
 		if (sig > SIGCOUNT) {
 		    int i;
 
@@ -1964,7 +1955,6 @@
 			    break;
 			}
 		}
-#endif
 		if (sig > SIGCOUNT) {
 		    zwarnnam(nam, "unknown signal: SIG%s", signame, 0);
 		    zwarnnam(nam, "type kill -l for a List of signals", NULL, 0);
@@ -2042,18 +2032,40 @@
 	if (!strcmp(s, sigs[i]))
 	    return i;
 
-#ifdef ALT_SIGS
     for (i = 0; alt_sigs[i].name; i++)
     {
 	if (!strcmp(s, alt_sigs[i].name))
 	    return alt_sigs[i].num;
     }
-#endif
 
     /* no matching signal */
     return -1;
 }
 
+/* Get the name for a signal. */
+
+/**/
+mod_export const char *
+getsigname(int sig)
+{
+    if (sigtrapped[sig] & ZSIG_ALIAS)
+    {
+	int i;
+	for (i = 0; alt_sigs[i].name; i++)
+	    if (sig == alt_sigs[i].num)
+		return alt_sigs[i].name;
+    }
+    else
+	return sigs[sig];
+
+    /* shouldn't reach here */
+#ifdef DEBUG
+    dputs("Bad alias flag for signal");
+#endif
+    return "";
+}
+
+
 /* Get the function node for a trap, taking care about alternative names */
 /**/
 HashNode
@@ -2062,9 +2074,7 @@
     char fname[20];
     HashNode hn;
     HashNode (*getptr)(HashTable ht, char *name);
-#ifdef ALT_SIGS
     int i;
-#endif
     if (ignoredisable)
 	getptr = shfunctab->getnode2;
     else
@@ -2074,7 +2084,6 @@
     if ((hn = getptr(shfunctab, fname)))
 	return hn;
 
-#ifdef ALT_SIGS
     for (i = 0; alt_sigs[i].name; i++) {
 	if (alt_sigs[i].num == sig) {
 	    sprintf(fname, "TRAP%s", alt_sigs[i].name);
@@ -2082,7 +2091,6 @@
 		return hn;
 	}
     }
-#endif
 
     return NULL;
 }
Index: Src/zsh.h
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/zsh.h,v
retrieving revision 1.73
diff -u -r1.73 zsh.h
--- Src/zsh.h	12 Apr 2005 15:11:12 -0000	1.73
+++ Src/zsh.h	1 Jun 2005 10:26:00 -0000
@@ -1852,7 +1852,8 @@
 /* Mask to get the above flags */
 #define ZSIG_MASK	(ZSIG_TRAPPED|ZSIG_IGNORED|ZSIG_FUNC)
 /* No. of bits to shift local level when storing in sigtrapped */
-#define ZSIG_SHIFT	3
+#define ZSIG_ALIAS	(1<<3)  /* Trap is stored under an alias */
+#define ZSIG_SHIFT	4
 
 /**********************************/
 /* Flags to third argument of zle */


-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

[Bart Schaefer]

On Jun 1, 11:31am, Peter Stephenson wrote:
} Subject: Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).
}
} Bart Schaefer wrote:
} > I note in passing that "trap" in zsh doesn't understand all the same
} > signals that "kill" does.  For example, when the OS defines both, "kill"
} > understands SIGIO as a synonym for SIGPOLL and SIGCLD for SIGCHLD, but
} > "trap" only knows CHLD and POLL.
} 
} How did you work this out?

I was basing it on an observation of the awk-generated list of trap names
on my system and the lack of any explicit mention of CLD and IO elsewhere
in the trap code, vs. the presence of alt_sigs in jobs.c.

} Adding SIGERR as an alias where there's no system signal is trivial.
} Now it should show up in the trap lists under ERR, too.  I've removed
} the ALT_SIGS definition because there isn't really any justification for
} making the mechanism optional now.

I can't tell by reading the patch: does this do as Oliver suggested and
prefer the ZERR equivalent for ERR, requiring SIGERR to get the actual
signal?  If not -- that is, if SIGERR is preferred when available --
then we still don't have ksh compatibility.

Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

[Bart Schaefer]

On Jun 1, 11:31am, Peter Stephenson wrote:
} Subject: Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).
}
} Adding SIGERR as an alias where there's no system signal is trivial.
} Now it should show up in the trap lists under ERR, too.  I've removed
} the ALT_SIGS definition because there isn't really any justification for
} making the mechanism optional now.

I just discovered another reason why we use ZERR:

In file included from ../../../zsh-4.0/Src/Modules/terminfo.c:53:
/usr/include/curses.h:195: warning: `ERR' redefined
/usr/include/sys/ucontext.h:74: warning: this is the location of the previous
definition

Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

[Peter Stephenson]

Bart Schaefer wrote:
> I just discovered another reason why we use ZERR:
> 
> In file included from ../../../zsh-4.0/Src/Modules/terminfo.c:53:
> /usr/include/curses.h:195: warning: `ERR' redefined
> /usr/include/sys/ucontext.h:74: warning: this is the location of the previous
> definition

There's wouldn't be anything defined as ERR.  There would be a SIGERR
if it we did it that way.

pws


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

Re: Bug#310872: zsh can't be a ksh replacement (can't trap ERR).

[Bart Schaefer]

On Jun 1,  1:57pm, Bart Schaefer wrote:
}
} I just discovered another reason why we use ZERR:

Urk, never mind that; I'm not awake yet.  Unrelated ERR.