Scripts stopped in the shell

Hi,

I've been wondering about this for a while and I just don't know where to start looking. Some of my scripts always get stopped when I start them with

$ script.plx &

in the shell (bash, on Debian lenny, logged in via ssh from a Mac OS machine using Terminal.app). After a few seconds I keep on getting

[1]+  Stopped                 ./script.plx

If I do "fg" it goes on running, but I have to open another shell to work in until it's done. Not a "problem", but annoying. The particular script I'm working on at the moment (this may have nothing to do with it, I don't know) opens a bunch of windows on an X desktop using VNC, but I don't really care what happens there (I don't work directly in an xterm in the VNC window for speed issues and because there is a long standing keyboard mapping bug involving VNC and Gnome).

The problem is just so general it's difficult to google ("script stopped shell"???) :-/ If anyone can help me guess where to start, it would be really great. Thanks!

Try to send it into background instead of fg:

bg

That's how I send into background running jobs, to reclaim my terminal prompt in bash: ctrl+z stops the job, and then bg will send it running but in background.
You can also use

bg %1

to background job number 1, which you can read from here:

[1]+  Stopped                 ./script.plx

What puzzles me is that running it with & should run it in the bg.

So, what shell are you using? On what platform?

A background job that tries to read from its teriminal is sent a signal which suspends it (SIGTTIN). The same may happen when trying to write to the terminal (SIGTTOU), but that depends on terminal settings (tostop).

If that job requires some input, if it is known ahead of time what it needs, you can redirect it. If it's trying to write to stdout or stderr, you may need to redirect those (or fiddle with your terminal's settings, if an attempt to write is the problem).

You probably want to use nohup. Not only will it redirect all the standard file streams, but it will ensure that your script will survive should the terminal go away and cause the shell to send SIGHUP to its jobs.

Regards,
Alister

1 Like

Sorry for being unresponsive - I'm still working on that script :-/

When I do that, it gets stopped again after a few seconds :-/

I use bash, on Debian lenny, logged in via ssh from a Mac OS X machine using Terminal.app

---------- Post updated at 06:27 AM ---------- Previous update was at 06:22 AM ----------

Thanks for the ideas. I just wanted to stay I'm still working on that script and investigating what the problem might be. I've used nohup in the past and I can't remember whether there were problems with that too or not.

Try

nohup ./myscript.sh &

as suggested by alister