Re: [Help-bash] backgrounding a process sends it into a tailspin

[Cook, Rich]

Aha, 
Using exec fixes the problem but trap does not work with it apparently.  The 
script becomes: 

#!/usr/bin/env bash
logger()
  if [[ -x $IMG_TRACK ]]; then 
      "$IMG_TRACK" "$1" gnuplot-4.4.3 "$BASH_SOURCE" "$@"
  fi

IMG_TRACK=${IMG_TRACK:-/usr/local/tools/imgtrack-1.0/bin/imgtrack}
trap "logger END" EXIT  # THIS does not work
logger BEGIN
# using exec avoids a problem with gnuplot spinning up 100% CPU usage, but 
disables the "EXIT" trap above.  C'est la vie
exec /usr/local/tools/gnuplot-4.4.3/bin/gnuplot.real "$@"

On Sep 8, 2012, at 10:27 AM, Cook, Rich wrote:

> Hi, thanks. 
> I'm very interested in the bash-specific quirks you mentioned.  Do you have 
> more information about them?  I'm thinking there is something about job 
> control under bash that causes select() to return something unexpected that 
> gnuplot is not handling well.  This is the part of the stack trace I find 
> interesting:  
>   rl_cleanup_after_signal, FP=7fffffffd0a0
>   rl_reset_after_signal, FP=7fffffffd140
>   rl_read_key,         FP=7fffffffd160
>   readline_internal_char, FP=7fffffffd180
> 
> What signal is gnuplot getting again and again when it tries to read a 
> keystroke?  Why does bash cause this?  
> 
> I cannot redirect stdin from /dev/null.  Most users are going to want stdin 
> to be available.  I just have a user that likes to background gnuplot and 
> wants to know why my script is breaking that.  
> 
> It occurs to me I could try using csh for my wrapper script.  Hmm... I'll try 
> that on Monday
> 
> -- Rich 
> 
> On Sep 7, 2012, at 7:52 PM, Dan Douglas <address@hidden> wrote:
> 
>> Here is the same script with various issues corrected:
>> 
>> #!/usr/bin/env bash
>> 
>> logger()
>>   if [[ -x $IMG_TRACK ]]; then 
>>       "$IMG_TRACK" "$1" gnuplot-4.4.3 "$BASH_SOURCE" "$@"
>>   fi
>> 
>> IMG_TRACK=${IMG_TRACK:-/usr/local/tools/imgtrack-1.0/bin/imgtrack}
>> trap 'logger END' EXIT
>> logger BEGIN
>> /usr/local/tools/gnuplot-4.4.3/bin/gnuplot.real "$@"
>> 
>> --
>> 
>> These are very unlikely the source of the problem.
>> 
>> Another unlikely possibility: I don't know what gnuplot does with stdin, but 
>> there are a couple bash-specific quirks involving background jobs reading 
>> from 
>> stdin. You might try adding a redirect to the line that runs gnuplot, i.e.
>> 
>> .../gnuplot.real "$@" </dev/null
>> 
>> It would also be helpful to know what OS is being used, and on what arch.
>> 
>> -- 
>> Dan Douglas
> 
> Rich Cook
> ========================
> ...if everyone does a little, we’ll achieve only a little -- DavidJ.C.MacKay.
> 
> 
> 
> 
> 
> 

-- 
✐Richard Cook   
✇ Lawrence Livermore National Laboratory
Bldg-453 Rm-4024, Mail Stop L-557        
7000 East Avenue,  Livermore, CA, 94550, USA
☎ (office) (925) 423-9605    
☎ (fax) (925) 423-6961
---
Information Management & Graphics Grp., Services & Development Div., Integrated 
Computing & Communications Dept.
(opinions expressed herein are mine and not those of LLNL)