Re: possible bug with $@ and and non-standard IFS

2009-08-04 Thread JR Rothschild
Apparently, I have run into an area of some controversy (or at least some disagreement) On my Solaris 10 box, ksh thinks that the expected output should be smith::0.0 sh -> smith:0.0 (an old version of bash) -> smith: 0.0 dtksh-> smith: 0.0 I don't think this will get solved anytime soon. :) T

Re: bash treats SIGSTOP in child process as child termination?

2009-08-04 Thread Sven Mascheck
On Tue, Aug 04, 2009 at 02:04:31PM -0500, Mike Coleman wrote: > This scenario is not something that will happen accidentally, since > there's really no way to SIGSTOP the child without doing it from > another shell, so the prospect of a user ending up in front of a > "hung" shell doesn't seem like

Re: bash treats SIGSTOP in child process as child termination?

2009-08-04 Thread Mike Coleman
On Tue, Aug 4, 2009 at 12:44 PM, Chet Ramey wrote: >> It seems to me that this loop should just wait until the process is >> 'kill -CONT'ed and keep right on going as if nothing had happened.  Is >> there any reason not to do this? > > Ummm...yes.  It renders job control useless.  If we have the sh

Re: bash treats SIGSTOP in child process as child termination?

2009-08-04 Thread Chet Ramey
Mike Coleman wrote: > I notice that if I do this in one (interactive) shell > > $ for n in 1 2 3 4 5; do /bin/sleep 60; echo $n; done > > and then 'kill -STOP' the sleep process (from another window), that > bash will proceed to run the next loop iteration. That is, it echos > '1' and starts

bash treats SIGSTOP in child process as child termination?

2009-08-04 Thread Mike Coleman
I notice that if I do this in one (interactive) shell $ for n in 1 2 3 4 5; do /bin/sleep 60; echo $n; done and then 'kill -STOP' the sleep process (from another window), that bash will proceed to run the next loop iteration. That is, it echos '1' and starts a new /bin/sleep, even while the

Re: Bash does not read up the whole script which it is currently executing

2009-08-04 Thread Greg Wooledge
On Tue, Aug 04, 2009 at 08:23:16AM -0700, John Reiser wrote: > On 08/04/2009 12:48 AM, fam...@icdsoft.com wrote: > > The problem is that Bash does not read up the whole script which it > > is currently executing. > > As a result of this, if we update the script file with a newer > >

Re: Bash does not read up the whole script which it is currently executing

2009-08-04 Thread John Reiser
On 08/04/2009 12:48 AM, fam...@icdsoft.com wrote: First I would like to say that I'm not sure if this is a bug or a feature of Bash. If it is a feature, please let me know how to turn it off; or better make it disabled by default... The problem is that Bash does

Bash does not read up the whole script which it is currently executing

2009-08-04 Thread famzah
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='ba

Re: possible bug with $@ and and non-standard IFS

2009-08-04 Thread Chet Ramey
JR Rothschild wrote: > Hi, > In either version 3.1.17 (SUSE 10) or 3.2.25 (RHEL 5.3), with $DISPLAY > set to :0.0 > the following script gives unexpected results.(It works with version > 3.0.15 - RHEL4.6) The echo should print out > > smith:0.0 It shouldn't display that; there are different bugs