disassociate controll terminal

[vladimir gershman]

Greetings,

I am trying to run a script and to disassociate it from a terminal, so that the script thinks it is not run interactively. Is there any way to do it with just Unix command and without C-code ( I can use ioctl call with C, but I am not allowed to use C-code).

Thanks,

Vlad

[melvyn burnard]

do you mean you want it to run and be able to logoff?
try doing:
nohup your_command &

[Brian M Rawlings]

You will also need to make sure your script does not expect interaction, and that all paths in it are complete pathnames (including commands).

For debugging, you might elect to redirect output somewhere, since it will be lost in the "nohup" disconnect from the parent process. But the basic form Melvyn describes is commonly used for this, and should work for you.

--bmr

[Paul Sperry · Accepted solution]

nohup yourscript &

will create a nohup.out file
that you can use for debugging

[Artyom Voronchihin]

Also you can use screen command to detach (disconnect) shell and its child processes from terminal. It allow you to connect this shell and see output of shell's running processes at anytime in future. Up to 10 pseudo-terminals are allowed in this command. Ported version for HPUX and discription of screen you can get at
http://hpux.cict.fr/hppd/hpux/Sysadmin/screen-3.9.8/

[Jordan Bean]

If you're going to use nohup, then also make sure to attach standard input, output, and error to the bit bucket. Otherwise the script will inherit the terminal.

nohup script /dev/null 2>&1 &

I find it more convenient to invoke non-interactive scripts as batch jobs:

batch <script&
EOF

[vladimir gershman]

well, here is what i have (nohup did not do it):
a c-shell script s1.csh is doing "tty -s" check to see if it is interactive.
the 2nd shell script s2.sh calls s1.csh, but s1.csh senses that it is interactive and does things as if it was interactive. I want it to think that it is a noninteractive call. I found one way to do it (very dirty). I created a THIRD script s3.sh and in it I do "sh s2.sh &". Now s1.csh thinks it is NOT interactive. Is there a cleaner way? If I do "sh s2.sh &" from a command line, it thinks it is interactive again. Any idea about a CLEAN way of doing it?

Thanks,

Vlad

[Steven E. Protter]

Post the script. If it has input commands, its going to be kind of hard to run in non-interactive mode.

P

[Bill Hassell]

Problems with /etc/profile and .profile are common in batch jobs because many commands expect an interactive terminal. The best way to handle this is to protect commands that need a terminal (tabs, tput, ttytype, tset and so on). All profiles should protect their terminal-sensitive commands.

To determine if a script is running with a controlling tty, you can either ask the shell if it is interactive or use the tty command:

if [ -o interactive ]
then
export INTERACTIVE=/sbin/true
else
export INTERACTIVE=/sbin/false
fi


if tty -s
then
export INTERACTIVE=/sbin/true
else
export INTERACTIVE=/sbin/false
fi

[Frank Slootweg]

Another way to 'disassociate' a script it to run it via at(1)/batch(1)/crontab(1), i.e. for example:

echo /path/to/script | batch

[Ralph Grothe]

Hi Vlad,

I think the answer to your question has already been given by many others.

As posted, if you don't want to (or in fact are prevented from) using syscalls (n.b. in this case it'd be the setsid() call), then you append an Ampersand to have the shell dissociate the process from the terminal.
But then the backgrounded process will still respond to a SIGHUP (or rather the controlling shell will emit them to her forked children).
To prevent this you ought to prepend the command nohup.

If however you are "allowed" to run a Perl script then you can use Perl's adoption of setsid(), which makes writing daemons in Perl unbeatably easy.

first you fork(), then you exit the parent process (that's the one that received the child's PID as return code from fork()), and then you call the POSIX module's setsid()

e.g.

use POSIX 'setsid';
$pid = fork();
exit 0 if $pid;
setsid();

That's basically all that is required, although usually one would do accompaying cleanup like

chdir '/';
# reopen STDIN, STDOUT, STDERR
open STDIN 'open STDOUT '>/dev/null';
open STDERR '>&STDERR';

[Ralph Grothe]

argh, typo on last line,
of course this was meant:

open STDERR, '>&STDOUT';