You need to start another session not attached to a terminal, so for instance:
$ setsid sh -c 'tty; ps -jp "$$"; echo test' < /dev/null > log 2>&1
$ cat log
not a tty
PID PGID SID TTY TIME CMD
19506 19506 19506 ? 00:00:00 sh
test
See also the start-stop-daemon
command found on some Linux distributions. There's also a daemon
command.
1.)
Yes, although there is more to it. ttys000
is also a character device sitting in /dev
, a user that has permissions to write to the tty
group (most users have) can pipe characters into that device and they will appear on the corresponding terminal. ttys*
are not real teletypes though, they're emulated tty
s, emulated by your (appropriately named) terminal emulator.
I do not have a Mac so I'll use the Linux naming convention for the following example:
Open terminal A as user A and find the emulated tty:
[userA@terminalA]$ tty
/dev/pts/0
Open terminal B as user B and do the same:
[userB@terminalB]$ tty
/dev/pts/3
Now redirect a couple of characters from terminal A to terminal B:
[userA@terminalA]$ echo Hi there > /dev/pts/3
And see them appear on terminal B:
[userB@terminalB]$ Hi there
On a Mac the devices should be /dev/ttys*
, I believe.
2.)
More or less. The ttys000
itself is just the character device, the actual entity that is controlling your java process is the terminal emulator. By controlling I mean that it is the parent off your java process. The parent can interact with its children in an easier fashion than other processes can.
Moreover, if certain precautions are not taken (see man nohup
for an example of such precaution), the death of the parent process will cause the death of all its children processes.
3)
The answer by Karlson already explain that the ?
means a process not associated with a terminal.
Since the terminal itself is just the character device, I believe it is not hard to conclude that it is not necessary for a process to be associated with a terminal device.
Closing notes
The actual terminals /dev/tty
are hardly used on modern *nix OSes (although they're used ensively during the boot process). But that does not mean you cannot use the actual terminals. On a Linux machine (sorry, I have no clue how a Mac performs this) the combination Ctrl + Alt + F1 (and F2, F3, ... up to F7) gives you a real terminal. One of these real terminals is used to perform the graphical display.
Several processes (including graphical applications) on a modern *nix OS are associated with a terminal device because the script that starts them needs to pass extra arguments. The script fires a shell passes the extra arguments and starts the process. Such scripts are often causes for confusion.
Best Answer
With controlling terminal, process is able to tell kernel which process group is foreground process group (in same session). If there is a foreground process group for a terminal, we can control the foreground process group via the terminal, e.g., Ctrl-C/Ctrl-\ to terminate the foreground process group. (A terminal may have only one foreground process group, or may not have any. To put it precisely, a terminal can only be associated with one process session.)
With controlling terminal, even if you already redirect stdin to other places/files, you still be able to read/write from/to controlling terminal, the
/dev/tty
. This special file is a synonym within the kernel for the controlling terminal of current process. If your process has no controlling terminal associated, then open this file will fail. What can you do regarding this file? E.g., some programs need user to input password before doing something, such as programs for login or encryption. These programs may prohibit user from inputting password from stdin, which means even if you redirect their stdin to a random file, they'll still wait for your type. The reason is they all open /dev/tty to read.To sum up, with controlling terminal, kernel is aware of where to deliver terminal-generated signal and terminal input if they are expected by someone. That's all.
So it is unnecessary for a process to associate with a controlling terminal, if it doesn't want to be controlled by any terminal, and doesn't want to read/write from/to "/dev/tty" (like most daemon programs). However, a common process launched from within a shell always have controlling terminal associated, because it is member of shell session, which has already established a controlling terminal when shell starts up. (Actually, a random process cannot attach a terminal as controlling terminal, only session leader process can.)