[Brian May] zsh random behaviour

[Brian May] zsh random behaviour

[Brian May]

[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]

Hello,

I found this weird behavior of zsh, when using the version in Debian
stable. Version 4.2.5-7.

As I have no reason to suspect this is Debian specific, so I am
reporting it here.

I recently reported it to my local Linux mailing list just in case
anybody could explain it, but so far everyone appears to be stumped.

The full details are in the attached email.

Any ideas? Is this a zsh bug or a bug sitting at the console?

The same thing works with bash. I also tried zsh-beta
(4.3.0-dev-1+20050424-1) from Debian stable, and got similar
results. I suspect a zsh bug.

Its totally weird. Even the weird parts are weird. The parts that
aren't weird are also weird.

I have copied the screen output verbatim, I have not omitted anything
except for the hundreds of tests I conducted (repeat: press up arrow;
press enter). I didn't dare try to automate the process in case this
altered the results (the initial problem was in a zsh script though;
the entire script aborted for no good reason).

For the moment I have changed my executable (used by the script) to
return 1 instead of 255, and it works fine.

Is a return value of 255 treated specially by zsh?

Please CC responses to me, thanks.


[-- Attachment #2: Type: message/rfc822, Size: 3137 bytes --]

From: Brian May <bam@snoopy.apana.org.au>
To: luv-main@luv.asn.au
Subject: zsh random behaviour
Date: Fri, 08 Jul 2005 18:58:13 +1000
Message-ID: <sa4u0j5llne.fsf@snoopy.microcomaustralia.com.au>

Hello,

Before I file a bug report against zsh, I want a second opinion.

If I compile this code:

--- cut ---
int main() {
        return -1;
}
--- cut ---

like so:

--- cut ---
[663] [snoopy:bam] ~/tree/diary-data >gcc -Wall -otest test.c
--- cut ---

and run the following command numerous times:

--- cut ---
[662] [snoopy:bam] ~/tree/diary-data >set -x; ./test | read -r i; echo $?
+zsh:898> set -x
+zsh:898> ./test
+zsh:898> read -r i
[662] [snoopy:bam] ~/tree/diary-data >set -x; ./test | read -r i; echo $?
+zsh:899> set -x
+zsh:899> ./test
+zsh:899> read -r i
+zsh:899> echo 1
1
--- cut ---

I get different behavior every time. Two versions are shown above.

This only seems to happen if test.c returns 250, 254, 255 or -1 and I
pipe the output the read. If it return 1 it works. I haven't checked
other values.

The zsh documentation says that only the return code from the last
command in a pipe statement matters.

If I try to do the same thing with "false", "sh false", or "sh -c
false", so far it works every time.
 
The -r parameter (raw mode) is not important. It happens anyway.

No, I didn't set -e, it is off. The shell should always execute the
echo statement regardless of if the previous commands fail or not.

also:

--- cut ---
[673] [snoopy:bam] ~/tree/diary-data >myread() { sleep 10; read -r $1; }
[678] [snoopy:bam] ~/tree/diary-data >set -x; ./test | myread i; echo $?
+zsh:988> set -x
+zsh:988> ./test
+zsh:988> myread i
+myread:0> sleep 10
--- cut ---

if I change the definition of myread to only include the sleep
command:

--- cut ---
[679] [snoopy:bam] ~/tree/diary-data >myread() { sleep 1;  }
[681] [snoopy:bam] ~/tree/diary-data >set -x; ./test | myread i; echo $?
+zsh:996> set -x
+zsh:996> ./test
+zsh:996> myread i
+myread:0> sleep 10
--- cut ---

... I was going to say it works every time, but apparently not
anymore. Maybe I was confused.

If I replace the myread with the sleep command directly, it works.

The 10 seconds always seems closer to 0 seconds. i.e there is no
delay.

Occasionally the sleep command will executes in the background!

--- cut ---
[683] [snoopy:bam] ~/tree/diary-data >set -x; ./test | myread i; echo $?
+zsh:1014> set -x
+zsh:1014> ./test
+zsh:1014> myread i
[683] [snoopy:bam] ~/tree/diary-data >+myread:0> sleep 10
--- cut ---

Success rate varies remarkably depending on the phase of the moon,
number of people reading this mailing list at a given time, direction
and speed of the wind above the Rialto, etc.

I can't get that last command to execute the echo instruction at all
though.

I was about to start pulling my hair out, but I will let you pull your
hair out instead <grin>.

The same thing seems OK with bash.

ii  zsh            4.2.5-7        A shell with lots of features
-- 
Brian May <bam@snoopy.apana.org.au>

[-- Attachment #3: Type: text/plain, Size: 42 bytes --]



-- 
Brian May <bam@snoopy.apana.org.au>

Re: [Brian May] zsh random behaviour

[Bart Schaefer]

On Jul 11, 11:32am, Brian May wrote:
}
} Is a return value of 255 treated specially by zsh?

A return value > 127 is interpreted as "killed by a signal" where the
signal number is the return value minus 127.  This is pretty standard
for shells, though not well-documented by any of them.

} I was about to start pulling my hair out, but I will let you pull your
} hair out instead <grin>.

See the "subtle 'echo' bug" thread from last month in the zsh-workers
archive, finishing with the patch in article 21391.

Re: [Brian May] zsh random behaviour

[Brian May]

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

    Bart> On Jul 11, 11:32am, Brian May wrote:
    Bart> }
    Bart> } Is a return value of 255 treated specially by zsh?

    Bart> A return value > 127 is interpreted as "killed by a signal"
    Bart> where the signal number is the return value minus 127.  This
    Bart> is pretty standard for shells, though not well-documented by
    Bart> any of them.

    Bart> } I was about to start pulling my hair out, but I will let
    Bart> you pull your } hair out instead <grin>.

    Bart> See the "subtle 'echo' bug" thread from last month in the
    Bart> zsh-workers archive, finishing with the patch in article
    Bart> 21391.

I assume you mean the thread starting at
<URL:http://www.zsh.org/mla/workers/2005/msg00690.html>.

I am not sure how it is related, in this case there appears to be a
process (echo) writing its output to another process (echo) that never
reads it's stdin.

In my case though, one process is writing (or maybe not) to another
process (read) that always reads it's stdin. This second process is
suppose to return 1 if it gets EOF. So, AFAIK, SIGPIPE should not be
getting generated.

Or is it a matter that zsh is getting confused when the first process
returns 255, and aborts because it thinks the program was killed due
to a signal?

Also, there was the comment "...this only effects interactive shells",
but it my case I first encountered the problem in a shell script.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: [Brian May] zsh random behaviour

[Bart Schaefer]

On Jul 14,  1:44pm, Brian May wrote:
} Subject: Re: [Brian May] zsh random behaviour
}
} I assume you mean the thread starting at
} <URL:http://www.zsh.org/mla/workers/2005/msg00690.html>.

Yes.

} Or is it a matter that zsh is getting confused when the first process
} returns 255, and aborts because it thinks the program was killed due
} to a signal?

Yes, again.

} Also, there was the comment "...this only effects interactive shells",
} but it my case I first encountered the problem in a shell script.

It extends from interactive shells to processes run by interactive shells.
It depends on zsh's notion of what process is "in the foreground".