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

[Cook, Rich]

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.