exit status problem

exit status problem

[Vincent Lefevre]

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

I show the exit status in the prompt, and I have the following
reproducible problem when I do:

1. I type "false".
2. I type "sleep 1 &".
3. I increase the window width.
4. I type [Enter].

Until step 3, no problem (attached snapshot zshprompt1.png).
But after 4 (attached snapshot zshprompt2.png), the prompt has been
redisplayed with exit status 0. But the new prompt is OK.

My precmd function starts with:

  psvar[1]=$?
  if [[ $psvar[1] -gt 128 ]] then
    local sig=$signals[$(($psvar[1]-127))]
    [[ -n $sig ]] && psvar[1]=$sig
  fi

and I have:

  TRAPCLD() { [[ -o interactive && -n $TTY ]] && precmd }

and

  PS1="%m:%20<...<%~%<<%(?..${prefail}[%1v]${postfail})%2v%(#.#.>) "

Is this a zsh bug?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

[-- Attachment #2: zshprompt1.png --]
[-- Type: image/png, Size: 3660 bytes --]

[-- Attachment #3: zshprompt2.png --]
[-- Type: image/png, Size: 3867 bytes --]

Re: exit status problem

[Peter Stephenson]

On Fri, 3 Dec 2010 16:24:38 +0100
Vincent Lefevre <vincent@vinc17.net> wrote:
> I show the exit status in the prompt, and I have the following
> reproducible problem when I do:
> 
> 1. I type "false".
> 2. I type "sleep 1 &".
> 3. I increase the window width.
> 4. I type [Enter].
> 
> Until step 3, no problem (attached snapshot zshprompt1.png).
> But after 4 (attached snapshot zshprompt2.png), the prompt has been
> redisplayed with exit status 0. But the new prompt is OK.

I don't understand why you don't get status 0 after 2. "sleep 1 &"
should reset it.

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


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: exit status problem

[Vincent Lefevre]

On 2010-12-03 16:09:16 +0000, Peter Stephenson wrote:
> I don't understand why you don't get status 0 after 2. "sleep 1 &"
> should reset it.

It doesn't:

xvii:~> zsh -f
xvii% false
xvii% sleep 1&
[1] 8693
xvii% 
[1]  + done       sleep 1
xvii% 
xvii% echo $?
1
xvii% 

The observed behavior doesn't follow the documentation.
The zsh man pages say:

  A backgrounded pipeline returns a status of zero.

It seems to be a bug in zsh 4.3.10 that has been fixed in the latest
dev versions. Do you have more information?

Back to my original problem, I can reproduce it with the dev version,
using:

1. I type "false".
2. I type "sleep 5 &".
3. I type "false".
4. I increase the window width.
5. I type [Enter].

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: exit status problem

[Bart Schaefer]

On Dec 4,  2:03am, Vincent Lefevre wrote:
}
}   A backgrounded pipeline returns a status of zero.
} 
} It seems to be a bug in zsh 4.3.10 that has been fixed in the latest
} dev versions. Do you have more information?

It was a bug at least as far back as 4.2.0.  Backgrounded jobs appear
not to have changed the foreground status until sometime post-4.3.10,
but I'm not finding a likely-looking ChangeLog entry unless this fix
was a side-effect of adding POSIX_JOBS behavior.  Or maybe it's this:

	* users/15217: Src/Zle/zle_main.c: use top-level status
	when redrawing prompt.

} Back to my original problem, I can reproduce it with the dev version,
} using:
} 
} 1. I type "false".
} 2. I type "sleep 5 &".
} 3. I type "false".
} 4. I increase the window width.
} 5. I type [Enter].

The status you're displaying is $? stored in psvar[1], correct?  And
that's set by precmd, and you're explicitly calling precmd again on
TRAPCLD, rather than allowing it to be called in the proper context
with global status manipulated as it would be at hook time.

If I use %? instead, I get consistent behavior, that is, the status
shown in the prompt never changes on window resize.  So I have to
conclude that this is an effect you've introduced.

It's too bad it's necessary to construct such a ridiculously elaborate
chain of %?(.t.f) conditions to get the effect your precmd creates in
psvar[1].

(){
  local x y z
  for x in {1..255}
  do
    if (( x > 128 ))
    then y+="%$x(?.${signals[x-127]:-$x}."
    else y+="%$x(?.$x."
    fi
    z+=")"
  done
  PS1+="$y"0"$z"
}

Re: exit status problem

[Vincent Lefevre]

On 2010-12-04 11:36:17 -0800, Bart Schaefer wrote:
> } 2. I type "sleep 5 &".
> } 3. I type "false".
> } 4. I increase the window width.
> } 5. I type [Enter].
> 
> The status you're displaying is $? stored in psvar[1], correct?  And
> that's set by precmd, and you're explicitly calling precmd again on
> TRAPCLD, rather than allowing it to be called in the proper context
> with global status manipulated as it would be at hook time.
> 
> If I use %? instead, I get consistent behavior, that is, the status
> shown in the prompt never changes on window resize.  So I have to
> conclude that this is an effect you've introduced.

What I don't understand is that if the problem is due to the precmd
call from TRAPCLD, then why do I get

ypig:~[1]>                                                    <12:15:32
[1]  + done       sleep 5
ypig:~[1]>                                                    <12:15:35

and not

ypig:~[1]>                                                    <12:15:32
[1]  + done       sleep 5
ypig:~[0]>                                                    <12:15:35

and why do I get "ypig:~[0]>" only after a window resize *and*
typing [Enter]. If I do not resize the window, the prompt is not
changed.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: exit status problem

[Mikael Magnusson]

On 6 December 2010 12:24, Vincent Lefevre <vincent@vinc17.net> wrote:
> On 2010-12-04 11:36:17 -0800, Bart Schaefer wrote:
>> } 2. I type "sleep 5 &".
>> } 3. I type "false".
>> } 4. I increase the window width.
>> } 5. I type [Enter].
>>
>> The status you're displaying is $? stored in psvar[1], correct?  And
>> that's set by precmd, and you're explicitly calling precmd again on
>> TRAPCLD, rather than allowing it to be called in the proper context
>> with global status manipulated as it would be at hook time.
>>
>> If I use %? instead, I get consistent behavior, that is, the status
>> shown in the prompt never changes on window resize.  So I have to
>> conclude that this is an effect you've introduced.
>
> What I don't understand is that if the problem is due to the precmd
> call from TRAPCLD, then why do I get
>
> ypig:~[1]>                                                    <12:15:32
> [1]  + done       sleep 5
> ypig:~[1]>                                                    <12:15:35
>
> and not
>
> ypig:~[1]>                                                    <12:15:32
> [1]  + done       sleep 5
> ypig:~[0]>                                                    <12:15:35
>
> and why do I get "ypig:~[0]>" only after a window resize *and*
> typing [Enter]. If I do not resize the window, the prompt is not
> changed.

Do you get the same results with an unset RPS1? Maybe recalculating
the position of the right prompt also does something else as a side
effect.

-- 
Mikael Magnusson

Re: exit status problem

[Bart Schaefer]

On Dec 6, 12:24pm, Vincent Lefevre wrote:
}
} > The status you're displaying is $? stored in psvar[1], correct?  And
} > that's set by precmd, and you're explicitly calling precmd
} > 
} > If I use %? instead, I get consistent behavior
} 
} What I don't understand is that if the problem is due to the precmd
} call from TRAPCLD, then why do I get
} 
} ypig:~[1]>                                                    <12:15:32
} [1]  + done       sleep 5
} ypig:~[1]>                                                    <12:15:35

It results from the timing of the trap handling.  The prompt is
reprinted because of the "[1]  + done" output before the CLD trap is
called; zsh does its internal signal handling before user traps.

Then on window resize the prompt is recomputed a second time, but this
time it's after your trap handler has run precmd.

} and why do I get "ypig:~[0]>" only after a window resize *and*
} typing [Enter].

If I poke something into RPS1 in a trap handler and then resize the
window, I see the change from the trap as soon as the window is
resized, not later after typing Enter.  But my xterm sends a stream
of SIGWINCH at the process underneath, it doesn't wait until I stop
resizing and then send the signal once.  Might that matter?

} If I do not resize the window, the prompt is not changed.

There is something confusing about the screen shots you first sent.
If those are in fact consecutive shots of the same terminal session,
as they appear to be, then it also appears that your prompt was

ypig:~[1]> 

at 15:59:59 *after* the screen resize, and then was *overwritten* at
16:00:03 by

ypig:~[0]> 

after which at 16:00:37 the prompt with [1] returns.  My question is,
what happened between 15:59:59 and 16:00:03 that caused the prompt to be
"updated in place"?  If all you did was hit Enter, the new prompt should
have appeared *below* the old one, not on top of it.

Re: exit status problem

[Vincent Lefevre]

On 2010-12-06 08:21:42 -0800, Bart Schaefer wrote:
> On Dec 6, 12:24pm, Vincent Lefevre wrote:
> } and why do I get "ypig:~[0]>" only after a window resize *and*
> } typing [Enter].
> 
> If I poke something into RPS1 in a trap handler and then resize the
> window, I see the change from the trap as soon as the window is
> resized, not later after typing Enter.  But my xterm sends a stream
> of SIGWINCH at the process underneath, it doesn't wait until I stop
> resizing and then send the signal once.  Might that matter?

The *old* prompt is redisplayed when the window is resized, but
why not the new prompt (see below)?

> } If I do not resize the window, the prompt is not changed.
> 
> There is something confusing about the screen shots you first sent.
> If those are in fact consecutive shots of the same terminal session,
> as they appear to be, then it also appears that your prompt was
> 
> ypig:~[1]> 
> 
> at 15:59:59 *after* the screen resize, and then was *overwritten* at
> 16:00:03 by
> 
> ypig:~[0]> 
> 
> after which at 16:00:37 the prompt with [1] returns.  My question is,
> what happened between 15:59:59 and 16:00:03 that caused the prompt to be
> "updated in place"?  If all you did was hit Enter, the new prompt should
> have appeared *below* the old one, not on top of it.

15:59:59 was the time the sleep process ended. When I resized the
window at 16:00:03, the prompt contents (as displayed) didn't change.
When I hit [Enter] at 16:00:37, the old prompt was replaced by the
new prompt contents (hence "ypig:~[1]>" changed to "ypig:~[0]>" and
15:59:59 changed to 16:00:03, which was the time of the resize).


-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: exit status problem

[Bart Schaefer]

On Dec 6,  8:09pm, Vincent Lefevre wrote:
}
} 15:59:59 was the time the sleep process ended. When I resized the
} window at 16:00:03, the prompt contents (as displayed) didn't change.

So there's no screenshot of that?  Because the first one ends at :59:59
with [1], and the next screenshot shows :00:03 with [0].  In both the
terminal has already been resized.  For me, zsh does very consistently
update the %* time in RPS1 while resizing -- is the time in your prompt
also coming from a psvar field?

} When I hit [Enter] at 16:00:37, the old prompt was replaced by the
} new prompt contents (hence "ypig:~[1]>" changed to "ypig:~[0]>" and
} 15:59:59 changed to 16:00:03, which was the time of the resize).

But in the second screenshot there's also a prompt where RPS1 says
16:00:37.  Do you mean there were TWO prompts printed at :37, first
the one that says :03 and then another below it that says :37 ?

If that is indeed what you mean, then this is probably a terminal
glitch -- zsh had already written the :03 prompt to the buffer, but
the terminal didn't repaint until it got input.

Re: exit status problem

[Vincent Lefevre]

On 2010-12-06 20:16:38 -0800, Bart Schaefer wrote:
> On Dec 6,  8:09pm, Vincent Lefevre wrote:
> } 15:59:59 was the time the sleep process ended. When I resized the
> } window at 16:00:03, the prompt contents (as displayed) didn't change.
> 
> So there's no screenshot of that?

I hadn't provided a screenshot before the resize because the contents
were the same (except the space between PS1 and RPS1).

> Because the first one ends at :59:59 with [1], and the next
> screenshot shows :00:03 with [0]. In both the terminal has already
> been resized. For me, zsh does very consistently update the %* time
> in RPS1 while resizing --

Here it doesn't. Actually the %* time isn't changed for the *first*
resize, but it is updated for the consecutive ones. Strange.

I can reproduce this problem even with zsh 4.3.10-dev-2-cvs1114
(Debian's zsh-beta package) using "zsh-beta -f" then RPS1="%*".

> is the time in your prompt also coming from a psvar field?

No, %*.

> } When I hit [Enter] at 16:00:37, the old prompt was replaced by the
> } new prompt contents (hence "ypig:~[1]>" changed to "ypig:~[0]>" and
> } 15:59:59 changed to 16:00:03, which was the time of the resize).
> 
> But in the second screenshot there's also a prompt where RPS1 says
> 16:00:37.  Do you mean there were TWO prompts printed at :37, first
> the one that says :03 and then another below it that says :37 ?

Yes, when I hit [Enter], the following two things occurred:
1. the current prompt (shown in Screenshot 1) was *replaced* by
   the one with 16:00:03;
2. a new prompt was printed (the one with 16:00:37).

I think that (1) should have been done at resize time. That would
also solve the problem mentioned above about %*.

> If that is indeed what you mean, then this is probably a terminal
> glitch -- zsh had already written the :03 prompt to the buffer, but
> the terminal didn't repaint until it got input.

Well, there are the same problems with GNOME Terminal. So, I think
that the bug is in zsh. Are you sure that zsh flushes its output?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: exit status problem

[Vincent Lefevre]

On 2010-12-07 13:24:57 +0100, Vincent Lefevre wrote:
> On 2010-12-06 20:16:38 -0800, Bart Schaefer wrote:
> > Because the first one ends at :59:59 with [1], and the next
> > screenshot shows :00:03 with [0]. In both the terminal has already
> > been resized. For me, zsh does very consistently update the %* time
> > in RPS1 while resizing --
> 
> Here it doesn't. Actually the %* time isn't changed for the *first*
> resize, but it is updated for the consecutive ones. Strange.

Not so strange actually: After a resize, the time of the *previous*
resize is displayed. This can be seen by hitting [Enter] after two
resize's, for instance. The behavior is just like the last prompt
output were not flushed.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: exit status problem

[Bart Schaefer]

On Dec 7,  1:24pm, Vincent Lefevre wrote:
}
} Yes, when I hit [Enter], the following two things occurred:
} 1. the current prompt (shown in Screenshot 1) was *replaced* by
}    the one with 16:00:03;
} 2. a new prompt was printed (the one with 16:00:37).
} 
} I think that (1) should have been done at resize time. That would
} also solve the problem mentioned above about %*.
} 
} [...] there are the same problems with GNOME Terminal. So, I think
} that the bug is in zsh. Are you sure that zsh flushes its output?

zrefresh() definitely calls fflush(shout), but refreshline() (which
is sometimes called after the flush) seems ultimately to be relying
on fputc() [at the end of a convoluted path through various macros
and wide character handling].

You could try applying this hunk to Src/Zle/zle_refresh.c to see if
that appears to clear up the problem [this is at the very end of
refreshline()] but I'm not confident that's the best place to call
fflush() for the general case.  (Line numbers may be inaccurate.)

@@ -2069,6 +2124,8 @@
 		 (nl->chr == WEOF && ol->chr));
 #endif
     }
+
+    fflush(shout);
 }
 
 /* move the cursor to line ln (relative to the prompt line),

Re: exit status problem

[Vincent Lefevre]

On 2010-12-07 09:30:00 -0800, Bart Schaefer wrote:
> You could try applying this hunk to Src/Zle/zle_refresh.c to see if
> that appears to clear up the problem [this is at the very end of
> refreshline()] but I'm not confident that's the best place to call
> fflush() for the general case.  (Line numbers may be inaccurate.)
> 
> @@ -2069,6 +2124,8 @@
>  		 (nl->chr == WEOF && ol->chr));
>  #endif
>      }
> +
> +    fflush(shout);
>  }
>  
>  /* move the cursor to line ln (relative to the prompt line),

No, this doesn't solve the problem.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: exit status problem

[Vincent Lefevre]

zsh 4.3.10-test-3 still has this problem, which can be summarized
as:

1. Execute "zsh -f".
2. Type RPS1="%*" and [Enter] (to have the time in the prompt).
3. Resize the window.
-> If the width has changed, the right part of the prompt is
   redisplayed at the correct place, but in any case, the time
   displayed in the prompt is not updated, even though zsh has
   updated it internally. This can be seen with:
4. Type [Enter].
-> The time in the current prompt is updated to the time when the
   window has been resized. This shows that the time in the prompt
   was updated internally, but the effect couldn't be seen on the
   terminal.
   A new prompt is also output as expected.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: exit status problem

[Peter Stephenson]

On Mon, 20 Dec 2010 12:34:33 +0100
Vincent Lefevre <vincent@vinc17.net> wrote:
> zsh 4.3.10-test-3 still has this problem, which can be summarized
> as:
> 
> 1. Execute "zsh -f".
> 2. Type RPS1="%*" and [Enter] (to have the time in the prompt).
> 3. Resize the window.
> -> If the width has changed, the right part of the prompt is
>    redisplayed at the correct place, but in any case, the time
>    displayed in the prompt is not updated, even though zsh has
>    updated it internally. This can be seen with:
> 4. Type [Enter].
> -> The time in the current prompt is updated to the time when the
>    window has been resized. This shows that the time in the prompt
>    was updated internally, but the effect couldn't be seen on the
>    terminal.
>    A new prompt is also output as expected.

Hmmm.... I've done exactly that and the time *is* updated at 3.

Obviously that doesn't mean there isn't a problem somewhere, but I'm
going to assume this will rumble on beyond 4.3.11.

Could be terminal specific in some way, but I got this both with urxvt
and xterm.  More likely system-specific and an fflush() is still
missing.

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


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: exit status problem

[Bart Schaefer]

On Dec 20,  2:59pm, Peter Stephenson wrote:
}
} Hmmm.... I've done exactly that and the time *is* updated at 3.

I've tried it as well but it's extremely difficult to tell whether
the time is updated at step 3 or not, because every system where I
try this (including my iMac, though it now occurs to me that may be
a VNC side-effect, so I should check again when I'm physically in
front of it) sends multiple SIGWINCH at the shell, and there's no way
to capture what happens after only one of them.  Vincent seems to be
getting only a single update after the resize is finished.

} Could be terminal specific in some way, but I got this both with urxvt
} and xterm.  More likely system-specific and an fflush() is still
} missing.

I attempted to trace through the prompt computation and printing and
had Vincent try adding a fflush() at a likely-looking spot, but that
didn't change anything.  Someone who has a better handle on how the
prompt display is screen-motion-optimized may have to jump in.

-- 

Re: exit status problem

[Vincent Lefevre]

On 2010-12-20 08:15:47 -0800, Bart Schaefer wrote:
> I've tried it as well but it's extremely difficult to tell whether
> the time is updated at step 3 or not, because every system where I
> try this (including my iMac, though it now occurs to me that may be
> a VNC side-effect, so I should check again when I'm physically in
> front of it) sends multiple SIGWINCH at the shell, and there's no way
> to capture what happens after only one of them.  Vincent seems to be
> getting only a single update after the resize is finished.

It may be related to the window manager: I use fvwm, where the resize
isn't real-time. But the same problem *sometimes* occur with real-time
resize (Style "*" ResizeOpaque); it seems to always occur when one
increases or decreases the width by 1 column only (otherwise the last
two SIGWINCH's generally occur during the same second, so that the
problem is not visible).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: exit status problem

[Vincent Lefevre]

On 2010-12-20 14:59:18 +0000, Peter Stephenson wrote:
> Could be terminal specific in some way, but I got this both with
> urxvt and xterm. More likely system-specific and an fflush() is
> still missing.

I've just tried with xterm, rxvt, mlterm and gnome-terminal under
GNU/Linux (Debian unstable), and get the same problem with all of
them. Thus it doesn't seem to be terminal specific. Perhaps OS
specific?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)