From owner-freebsd-ports  Thu Apr 18 11:05:31 1996
Return-Path: owner-ports
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id LAA25644
          for ports-outgoing; Thu, 18 Apr 1996 11:05:31 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA25607
          Thu, 18 Apr 1996 11:04:57 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id EAA06384; Fri, 19 Apr 1996 04:00:51 +1000
Date: Fri, 19 Apr 1996 04:00:51 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199604181800.EAA06384@godzilla.zeta.org.au>
To: j@uriah.heep.sax.de, ports@freebsd.org
Subject: Re: Interesting bash bug - anyone else see this?
Cc: freebsd-current@freebsd.org
Sender: owner-ports@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>> I just noticed it, myself.  It doesn't happen in sh or csh, so it's
>> definitely one for -bash and -current (if not also -stable; I dunno!).
>> 
>> <go to a directory with many files in it>
>> root@reason-> ls -lt | more
>> ^Z
>> [2]+  Done                    ls -lt | more
>> root@reason-> fg
>> ls -lt | more
>> Broken pipe
>> 
>> Bug #1: Upon suspending, bash erroneously reports the background job's status
>> 	as "Done", not "Suspended"
>> 
>> Bug #2: Upon resuming, we're hosed - the pipe breaks.

This works fine here because my `more' is aliased to `less' like it should
be :-).  `/bin/ls -lt /usr/src/lib/libc/obj/ | /usr/bin/more' fails in much
the under bash, sh and csh.  bash gives better error messages but the pipe
always breaks.  I don't have tcsh installed.

>I can reproduce it.  Depending upon how quickly i pressed ^Z, i could
>even get bash into a totally hosed state, the ^Z has been displayed,
>but ``nichts geht mehr''.  Only a SIGCONT from a different window
>helped.

I can't reproduce this.  Perhaps it is like the bug that causes bash to
hang when starting up (type su and hit ^C; the su often gets stuck in
a loop doing a longjmp to nowhere from a signal handler).

>...  This is your case:

>  107 11252   270   1  10  0   628  700 wait   S     p3    0:00.43 bash
>  107 11267 11252   1  28  0   384  232 -      T     p3    0:00.07 ls -lt

>The `ls' has been stopped, but `more' is already dead.  (That's why
>bash is reporting it as `Done'.)

This seems to be a bug in `more'.  It goes to a lot of trouble to
receive the SIGTSP but seems to always exit if the signal interrupts a
read.  Try stopping:

	(sleep 2; cat /etc/passwd) | ktrace /usr/bin/more

`kdump' shows `more' receiving the signal and exiting without retrying
the read.

Bruce