Is there a portable way to do this? On Linux, I can use ps a -N but this option isn't available on other (POSIX) systems. Of course I can use grep '^?' with, say, -o tty,... but is there something more reliable?

How can one get the real name of the controlling terminal (if there is one, else an error) as a pathname? By "real name", I mean not /dev/tty, which cannot be used by other arbitrary processes to refer to the same terminal. I prefer the answer as a simple shell code (like the example below) if possible, otherwise as a C function. Note that this must work even if the standard input is redirected, so that the tty utility cannot be used: one would get a not a tty error in such a case, since tty just prints the file name of the terminal connected to standard input. Under Linux, one can use: echo "/dev/ps -p $$ -o tty | tail -n 1" but this is not portable, as according to POSIX, [the format of the terminal name is unspecified](http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ps.html#tag_20_96_18) . Concerning C functions, ctermid (NULL) returns /dev/tty, which is useless here. **Note:** according to the zsh documentation, one should be able to do zsh -c 'echo $TTY' but this currently (version 5.0.7) fails when both the standard input and the standard output are redirected: $ zsh -c 'echo $TTY > /dev/tty' /dev/tty' /dev/null /dev/tty

If I make the bash as the first process invoked (i.e as init), as a result it will display the following:

init: cannot set terminal process group (-1): Inappropriate ioctl for device
init: no job control in this shell

And no signals (e.g ^C, ^Z) work. Through reading the source code of bash-5.1.12, the problem is located at the expression in job.c line 4501: (t = tcgetpgrp (shell_tty)) == -1 The error value is ENOTTY, which mean that the calling process does not have a controlling terminal. Why is Bash without a controlling terminal when invoked as init?

In a process session with a controlling terminal, - if the controlling process closes the file descriptor of the controlling terminal, does the process session become detached from the controlling terminal, i.e. not have any controlling terminal? - What if a non-controlling process in the session closes the file descriptor of the controlling terminal? Thanks.

Assume a session has a controlling terminal. If a process in the session that is not the session leader, calls ioctl(fd, TIOCNOTTY), is it correct that it only closes the fd for itself? Is it the same as close(fd)? Thanks.

A part of the output from the ps -ef command is given below : UID PID PPID C STIME TTY TIME CMD root 1 0 0 2012 ? 00:00:01 init root 2 1 0 2012 ? 00:00:01 [migration/0] root 3 1 0 2012 ? 00:00:00 [ksoftirqd/0] root 4 1 0 2012 ? 00:00:00 [watchdog/0] root 5 1 0 2012 ? 00:00:00 [events/0] root 6 1 0 2012 ? 00:00:00 [khelper] root 7 1 0 2012 ? 00:00:00 [kthread] root 9 7 0 2012 ? 00:00:00 [xenwatch] root 10 7 0 2012 ? 00:00:00 [xenbus] root 18 7 0 2012 ? 00:00:01 [migration/1] root 19 7 0 2012 ? 00:00:00 [ksoftirqd/1] What does the "?" for all the rows in the TTY column mean? Also what does C and CMD column stand for?

Consider this sample C program which writes to /dev/tty and doesn't have command line options to make it not do so.

#include 

int main (void) {
    FILE* fout = fopen("/dev/tty", "w");
    fprintf(fout, "Hello, World!\n");
    fclose(fout);
}

How could I redirect the output of it to /dev/null in a shell script? P.S. I read [this answer](https://unix.stackexchange.com/questions/597137/how-to-redirect-output-from-dev-tty-to-dev-null) , but I didn't understand much. In any case, I'm expecting an answer that doesn't modify the code source of the program.

I'm investigating the behaviour of a script that is normally run as an automated process (e.g. cron, Jenkins). The script can (eventually) invoke commands that behave differently (seeking user input) when run interactively; for example, patch will ask what to do with a reversed patch, and svn will ask for passwords, but I need to see what happens when they're run non-interactively. Persuading patch that it's non-interactive is fairly easy; I just need to redirect stdout to be a non-tty: $ >(cat) /path/to/myscript --args However svn will connect to the controlling terminal if it exists; editing the scripts to pass --non-interactive isn't really an option as this is coming from several levels deep and it'd be difficult to be certain I'd found every invocation. Is there a way to invoke a script/command non-interactively, without a controlling terminal (so that /dev/tty doesn't exist)? I'd prefer stdout/stderr to still go to my terminal. (I found the question https://unix.stackexchange.com/questions/23892/run-script-in-a-non-interactive-shell but the answers to that discuss the differences between the cron and user environment; I've already eliminated all differences except non-interactivity.)

On Lubuntu 18.04, I run a shell in lxterminal. Its controlling terminal is the current pseudoterminal slave: $ tty /dev/pts/2 I would like to know what relations are between my current controlling terminal /dev/pts/2 and /dev/tty. 1. /dev/tty acts like my current controlling terminal /dev/pts/2: $ echo hello > /dev/tty hello $ cat < /dev/tty world world ^C 2. But they seem to be unrelated files, instead of one being a symlink or hardlink to the other: $ ls -lai /dev/tty /dev/pts/2 5 crw--w---- 1 t tty 136, 2 May 31 16:38 /dev/pts/2 13 crw-rw-rw- 1 root tty 5, 0 May 31 16:36 /dev/tty For different sessions with different controlling terminals, if /dev/tty is guaranteed to be their controlling terminals. How can it be different controlling terminals, without being a symlink or hardlink? So what are their relations and differences? Any help is much appreciated! This post is originated from an earlier one https://unix.stackexchange.com/questions/446166/do-the-output-of-command-tty-and-the-file-dev-tty-both-refer-to-the-control

When I login on a Fedora 31 workstation and run the ps command, I see the below output; for an X session: PID TT CMD ... 1 ? /usr/lib/systemd/systemd --switched-root --system --deserialize 29 ... 820 ? /usr/sbin/gdm 1305 ? gdm-session-worker [pam/gdm-password] 1346 tty2 /usr/libexec/gdm-x-session --run-script /usr/bin/gnome-session 1348 tty2 /usr/libexec/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3 1444 tty2 /usr/libexec/gnome-session-binary 1465 ? /usr/bin/ssh-agent /bin/sh -c exec -l /bin/bash -c "/usr/bin/gnome-session" ... 1316 ? /usr/lib/systemd/systemd --user 1322 ? (sd-pam) ... 1531 ? /usr/bin/gnome-shell ... for a Wayland session: PID TT CMD ... 1 ? /usr/lib/systemd/systemd --switched-root --system --deserialize 29 ... 825 ? /usr/sbin/gdm 1309 ? gdm-session-worker [pam/gdm-password] 1351 tty2 /usr/libexec/gdm-wayland-session /usr/bin/gnome-session 1356 tty2 /usr/libexec/gnome-session-binary ... 1321 ? /usr/lib/systemd/systemd --user 1327 ? (sd-pam) ... 1492 ? /usr/bin/gnome-shell ... As I understand, graphical logins via a display manager like gdm executes an X/Wayland session directly after authenticating a user, instead of executing a login shell. I see that both X and Wayland sessions are started on a virtual terminal (tty2), and what the Xorg(1) says about the vt option is: 'This option applies only to platforms that have virtual terminal support, such as Linux, BSD, OpenSolaris, SVR3, and SVR4.' Is starting X/Wayland sessions with a controlling tty done merely to provide the ability to switch to other virtual terminals while running a graphical shell in one, or is it a constraint of X/Wayland? Is it possible to start an X/Wayland session without a controlling tty on Linux, and is this up to gdm, X/Wayland, or systemd? And what would be an example of a system that runs Xorg and doesn't have virtual terminals at all unlike the systems listed in Xorg(1)?

Does an X client process always have one or more GUI window(s)? Conversely, if a process has one or more GUI window(s), is it an X client process? Does an X client never have a controlling terminal? Does the concept of "controlling terminal" only apply to processes which have no GUI window? Thanks.

Suppose there is a session with multiple processes in it and without a controlling terminal. When the session leader creates a connection to a controlling terminal, - how would the other processes in the same session learn that the session has a controlling terminal and - how could they also make use of the controlling terminal? The reason that I have this question is the following. Usually a process calls setsid() to start a new session and become its leader, and calls open() to connect to a controlling terminal. Then the session leader goes on to fork() child processes, and the children will inherit the file descriptor to the controlling terminal. I then wonder what if a session already has multiple processes and but has no controlling terminal, and then the leader creates a connection to a controlling terminal, and then what about the other processes in the session. Thanks.

From The Linux Programming Interface > In an interactive shell, these three file descriptors 0, 1 and 2 normally refer to the terminal under which the shell is running. 1. Does "the terminal under which the shell is running" mean the controlling terminal of the session to which the interactive shell belongs? If yes, what if the shell's session doesn't have a controlling terminal? 2. When the shell is created from its parent process, will the shell automatically create connection betwee file descriptors 0, 1 and 2 and the terminal, in each of the following cases (inheritance from the parent process of the shell): - if "the terminal under which the shell is running" or the controlling terminal has already been opened at a file descriptor which is not 0, 1 and 2? - if the file descriptors 0, 1 and 2 have already been connected to a file which is not "the terminal under which the shell is running" or the controlling terminal? 3. What if the shell in the quote is noninteractive? Thanks. Btw, just assume "shell" is POSIX or bash. Related https://unix.stackexchange.com/questions/446588/how-can-we-disconnect-a-file-descriptor-from-any-file/446591#446591

How these process concepts are related together - background, zombie, daemon and without controlling terminal? I feel that they are somehow close, especially through the concept of controlling terminal, but there is still not much info for me to tell a story, like if you need to explain something to a child reading an article about Linux without lying too much. **UPDATE #1: For example (I don't know if that's true)** * background -- zombie - foreground process can not become zombie, because zombie is a background process that was left without a parent * daemon -- without ctty - all daemons run without ctty, but not all processes withoutctty are daemons * background -- daemon - a background process can be retrieved to run interactively again, daemon is not * zombie -- without ctty - zombie is indifferent if there is ctty attached to it or not * background -- without ctty - processes sent to background while they have ctty, and become daemons or die if the ctty is taken from them

Am I right that all input typed from the keyboard goes through a _controlling terminal_? That means that if a program is run without a controlling terminal, it won't be able to receive any user input. Is that right for every kind of program in Linux? **UPDATE #1**: To clarify the question, my pager module for Python [crashes when stdin is redirected](https://bitbucket.org/techtonik/python-pager/issues/7/33-piping-input-doesnt-work-for-linux) : $ ./pager.py page(sys.stdin) File "pager.py", line 375, in page if pagecallback(pagenum) == False: File "pager.py", line 319, in prompt if getch() in [ESC_, CTRL_C_, 'q', 'Q']: File "pager.py", line 222, in _getch_unix old_settings = termios.tcgetattr(fd) termios.error: (25, 'Inappropriate ioctl for device') This is because I try to get descriptor to setup keyboard input as fd = sys.stdin.fileno(). When stdin is redirected, its file descriptor no longer associated with any keyboard input, so attempt to setup it fails with input-output control error. I was told to get this controlling terminal instead, but I had no idea where does it come from. I understood that it is some kind of channel to send signals from user to running processes, but at the same time it is possible to run processes without it. So the question is - should I always read my keyboard input from controlling terminal? And what happens if the pager process is run without it? Will keyboard input still matter to user? Should I care to get it from some other source?

What happens with process when it is run without a controlling terminal? How is that process different from a standard processes? What features does it lose and what does it acquire? **UPDATE #1** The question listed as a possible duplicate: https://unix.stackexchange.com/questions/58186/concept-of-controlling-terminal-in-unix doesn't contain the answer. Also that other question is too broad and doesn't mention process qualities at all.

I can kill processes and send signals to them with kill, so I don't need controlling terminal (or ctty) for that. So.. is the purpose of controlling terminal is solely for reacting to nudges from user? Transforming Ctrl-C key press into SIGINT ("hey, stop it!") and detecting if operator behind the keyboard is still alive ("keyboard is detached - SIGHUP, man")? [The docs](http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html#tag_11_01_03) are full with details that doesn't answer the question "why it is here?", which must be obvious for everybody except me.

I use TIOCSCTTY to forcibly take over the controlling terminal in other "remote" application. But after the application finishes running, controlling terminal gets orphaned and bash stops reacting to Ctrl+C until I restart it with bash$ exec bash. How should I explicitly return the controlling terminal back after taking it with TIOCSCTTY?

Can some one please explain in an easy to understand way the concept of controlling terminal in unix and unix like systems ? Is it related to a session ? If yes, then how ?