[Gnuplot-info] gnuplot stuck at 100% CPU when put in background in a shell script

[Cook, R. <co...@ll...>]

Hello, 
I'm sorry for such an odd question as a newbie poster. 
I have built and installed gnuplot and wrapped it in a wrapper script.  The script simply makes a usage entry in a database, calls gnuplot, then notes that it exits.  I'm including the script below.  

Anyhow, when the user runs this script and puts it into the background, gnuplot immediately starts taking up 100% of a CPU, spinning in readline.  This only happens when gnuplot is wrapped in this way, not when it's called directly.  I would like to avoid this behavior, obviously, but I would also like to continue using a wrapper script.  What is it about being called from a script that is causing this odd behavior on gnuplot's part?  

Thanks.  

Here's a stack trace from a debugger of gnuplot when it's hammering our CPU:  
Stack Trace
     tcsetattr,           FP=7fffffffd060
     rl_tty_unset_default_bindings, FP=7fffffffd080
     rl_deprep_terminal,  FP=7fffffffd090
     rl_cleanup_after_signal, FP=7fffffffd0a0
     rl_reset_after_signal, FP=7fffffffd140
     rl_read_key,         FP=7fffffffd160
     readline_internal_char, FP=7fffffffd180
     readline,            FP=7fffffffd190
C    read_line,           FP=7fffffffd1e0
C    com_line,            FP=7fffffffd1f0
C    main,                FP=7fffffffd3e0
     __libc_start_main,   FP=7fffffffd4a0
     _start,              FP=7fffffffd4b0


Here's the wrapper script:  

#!/usr/bin/env bash

IMG_TRACK=${IMG_TRACK:-/usr/local/tools/imgtrack-1.0/bin/imgtrack}
if [ -f $IMG_TRACK ]; then 
    $IMG_TRACK BEGIN gnuplot-4.4.3 $0 "$@"
fi
/usr/local/tools/gnuplot-4.4.3/bin/gnuplot.real "$@"
_value=$?
if [ -f $IMG_TRACK ]; then 
    $IMG_TRACK END gnuplot-4.4.3 $0 "$@"
fi
exit $_value



-- 
✐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)