[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Short question



In <Pine.LNX.4.10_heb2.08.9908111814420.528-100000@fireball.tau.ac.il>, Ariel Biener <ariel@fireball.tau.ac.il> writes:

> Second, ftp WILL exit when it loses the control terminal. Try it, from
> bash or tcsh.

I explained this behavior previously.

	When the terminal goes away, the program will start getting
	errors on write()s to the terminal.  Whether it exits or not
	at that point depends on how well it is written.

Simply, if ftp attempts to receive input from the user and fails, it
exits.  This is correct behavior, why should it stick around?  

Therefore, when using a shell with job control, it's quite
straightforward to do the following:

	ftp> get big-file
	150 Opening BINARY mode data connection for big-file (lots of bytes).
	^Z
	Suspended
	% bg
	[1] ftp
	% exit

When ftp finishes the transfer, it'll exit by itself because of the
above mentioned condition.  (It doesn't try reading from the terminal
while transferring the file.)  Come to think of it, I've been doing
this forever!

Because ftp is run in a background process group, the kernel doesn't
send it a SIGHUP when the shell exits.  Had you run something similar
from a shell without job control (which isn't as simple as the example 
above, since you can't suspend and `bg' jobs in a shell WITHOUT job
control!), then ftp would die immediately when the shell exited.

> In fact, most Unix utilities will exit when losing the control terminal.

If the application expects to get input, and it can't do so (because
it lost its terminal), I'd expect it to exit.  Like I said, that's
correct behavior.

To decide based on observing this behavior that job control doesn't
work, which is basically what you were saying... that's quite a
stretch.

> You are welcome to prove me otherwise, and this way I might learn
> something.

I explained what's going on, twice.

Which part were you disputing, exactly?

The fact that background jobs started from a shell with job control
don't die when the shell exits?

	bash$ sleep 666 &
	[1] 31187
	bash$ exit
	Connection to linux-box closed.
	% ssh linux-box
	Last login: Wed Aug 11 19:00:46 1999 from vortex
	You have new mail.
	bash$ ps -p 31187
	  PID TTY          TIME CMD
	31187 ?        00:00:00 sleep


Or my explanation of how job control works?

	$ cat wrapper.c
	#include <sys/types.h>
	#include <unistd.h>
	#include <stdio.h>
	
	int
	main(int argc, char **argv)
	{
	        if (argc < 3) {
	                fprintf(stderr, "usage: wrapper path args\n");
	                return (1);
	        }
	        if (setpgid(0, getpid()) == -1) {
	                perror("setpgid");
	                return (1);
	        }
	        if (execv(argv[1], &argv[2]) == -1) {
	                perror("exec");
	                return (1);
	        }
	        /*NOTREACHED*/
	}
	$ gcc -o setpgid wrapper.c
	$ ./setpgid /usr/bin/sleep sleep 666 &
	9616
	$ exit
	Connection to solaris-box closed.
	% ssh solaris-box
	Last login: Wed Aug 11 11:23:52 1999 from vortex
	Sun Microsystems Inc.   SunOS 5.6       Generic August 1997
	You have mail.
	$ ps -p 9616
	   PID TTY      TIME CMD
	  9616 ?        0:00 sleep
	$ sleep 666 &
	9624
	$ exit
	Connection to solaris-box closed.
	% ssh solaris-box
	Last login: Wed Aug 11 11:33:52 from vortex
	Sun Microsystems Inc.   SunOS 5.6       Generic August 1997
	You have mail.
	$ ps -p 9624
	   PID TTY      TIME CMD
	$ exit
	

=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il