How does a program know if stdout is connected to a terminal or a pipe?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
I'm having trouble debugging a segfaulting program because the ouput right before the segfault is what I need, but this is lost if I'm piping the output to a file. According to this answer: https://unix.stackexchange.com/a/17339/22615, this is because the output buffer of the program flushes immediately when connected to a terminal but only at certain points when connected to a pipe. A few questions here:
How does a program determine what its stdout is connected to?
How does the "script" command produce the same behavior as when the program writes to a terminal?
Can this be achieved without the script command?
terminal pipe
New contributor
add a comment |
I'm having trouble debugging a segfaulting program because the ouput right before the segfault is what I need, but this is lost if I'm piping the output to a file. According to this answer: https://unix.stackexchange.com/a/17339/22615, this is because the output buffer of the program flushes immediately when connected to a terminal but only at certain points when connected to a pipe. A few questions here:
How does a program determine what its stdout is connected to?
How does the "script" command produce the same behavior as when the program writes to a terminal?
Can this be achieved without the script command?
terminal pipe
New contributor
A related question is unix.stackexchange.com/q/513926/5132 .
– JdeBP
7 hours ago
add a comment |
I'm having trouble debugging a segfaulting program because the ouput right before the segfault is what I need, but this is lost if I'm piping the output to a file. According to this answer: https://unix.stackexchange.com/a/17339/22615, this is because the output buffer of the program flushes immediately when connected to a terminal but only at certain points when connected to a pipe. A few questions here:
How does a program determine what its stdout is connected to?
How does the "script" command produce the same behavior as when the program writes to a terminal?
Can this be achieved without the script command?
terminal pipe
New contributor
I'm having trouble debugging a segfaulting program because the ouput right before the segfault is what I need, but this is lost if I'm piping the output to a file. According to this answer: https://unix.stackexchange.com/a/17339/22615, this is because the output buffer of the program flushes immediately when connected to a terminal but only at certain points when connected to a pipe. A few questions here:
How does a program determine what its stdout is connected to?
How does the "script" command produce the same behavior as when the program writes to a terminal?
Can this be achieved without the script command?
terminal pipe
terminal pipe
New contributor
New contributor
edited 4 hours ago
egmont
2,7471913
2,7471913
New contributor
asked 10 hours ago
mowwwalkermowwwalker
1062
1062
New contributor
New contributor
A related question is unix.stackexchange.com/q/513926/5132 .
– JdeBP
7 hours ago
add a comment |
A related question is unix.stackexchange.com/q/513926/5132 .
– JdeBP
7 hours ago
A related question is unix.stackexchange.com/q/513926/5132 .
– JdeBP
7 hours ago
A related question is unix.stackexchange.com/q/513926/5132 .
– JdeBP
7 hours ago
add a comment |
1 Answer
1
active
oldest
votes
Telling if a file descriptor points to a terminal device
A program can tell if a file descriptor is associated with a tty device by using the isatty()
standard C function (which generally underneath does an innocuous tty-specific ioctl()
system call that would return with an error when the fd doesn't point to a tty device).
The [
/test
utility can do it with its -t
operator.
if [ -t 1 ]; then
echo stdout is open to a terminal
fi
Tracing libc function calls on a GNU/Linux system:
$ ltrace [ -t 1 ] | cat
[...]
isatty(1) = 0
[...]
Tracing system calls:
$ strace [ -t 1 ] | cat
[...]
ioctl(1, TCGETS, 0x7fffd9fb3010) = -1 ENOTTY (Inappropriate ioctl for device)
[...]
Telling if it points to a pipe
To determine whether a fd is associated with a pipe/fifo, one can use the fstat()
system call, which returns a structure whose st_mode
field contains the type and permissions of the file opened on that fd. The S_ISFIFO()
standard C macro can be used on that st_mode
field to determine if the fd is a pipe/fifo.
There is no standard utility that can do a fstat()
, but there are several incompatible implementations of a stat
command that can do it. zsh
's stat
builtin with stat -sf "$fd" +mode
which returns the mode as a string representation whose first character represents the type (p
for pipe). GNU stat
can do the same with stat -c %A - <&"$fd"
, but also has stat -c %F - <&"$fd"
to report the type alone. With BSD stat
: stat -f %St <&"$fd"
or stat -f %HT <&"$fd"
.
Telling if it's seekable
Applications generally do not care if stdout is a pipe though. They may care that it's seekable (though generally not to decide whether to buffer or not).
To test whether a fd is seekable (pipes, sockets, tty devices are not seekable, regular files and most block devices generally are), one can attempt a relative lseek()
system call with an offset of 0 (so innocuous). dd
is a standard utility that's an interface to lseek()
but it can't be used for that test, as implementations would not call lseek()
at all if you ask for an offset of 0.
The zsh
and ksh93
shells have builtin seeking operators though:
$ strace -e lseek ksh -c ': 1>#((CUR))' | cat
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
ksh: 1: not seekable
$ strace -e lseek zsh -c 'zmodload zsh/system; sysseek -w current -u 1 0 || syserror'
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
Illegal seek
Disabling the buffering
The script
command uses a pseudo-terminal pair to capture the output of a program, so the program's stdout (and stdin and stderr) will be a pseudo-terminal device.
When the stdout is to a terminal device, there is still generally some buffering, but it is line based. printf
/puts
and co will not write anything until a newline character is to be output. For other types of files, the buffering is by blocks (of a few kilo bytes).
There are several options to disable the buffering which are discussed in a number of Q&As here (search for unbuffer or stdbuf, Can't redirect cut output gives a few approaches) either by using a pseudo-terminal as can be done by socat
/script
/expect
/unbuffer
(an expect
script)/zsh
's zpty
or by injecting code in the executable to disable the buffering as done by GNU's or FreeBSD's stdbuf
.
Awesome answer, thank you very much for this!
– mowwwalker
9 hours ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
mowwwalker is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f515778%2fhow-does-a-program-know-if-stdout-is-connected-to-a-terminal-or-a-pipe%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Telling if a file descriptor points to a terminal device
A program can tell if a file descriptor is associated with a tty device by using the isatty()
standard C function (which generally underneath does an innocuous tty-specific ioctl()
system call that would return with an error when the fd doesn't point to a tty device).
The [
/test
utility can do it with its -t
operator.
if [ -t 1 ]; then
echo stdout is open to a terminal
fi
Tracing libc function calls on a GNU/Linux system:
$ ltrace [ -t 1 ] | cat
[...]
isatty(1) = 0
[...]
Tracing system calls:
$ strace [ -t 1 ] | cat
[...]
ioctl(1, TCGETS, 0x7fffd9fb3010) = -1 ENOTTY (Inappropriate ioctl for device)
[...]
Telling if it points to a pipe
To determine whether a fd is associated with a pipe/fifo, one can use the fstat()
system call, which returns a structure whose st_mode
field contains the type and permissions of the file opened on that fd. The S_ISFIFO()
standard C macro can be used on that st_mode
field to determine if the fd is a pipe/fifo.
There is no standard utility that can do a fstat()
, but there are several incompatible implementations of a stat
command that can do it. zsh
's stat
builtin with stat -sf "$fd" +mode
which returns the mode as a string representation whose first character represents the type (p
for pipe). GNU stat
can do the same with stat -c %A - <&"$fd"
, but also has stat -c %F - <&"$fd"
to report the type alone. With BSD stat
: stat -f %St <&"$fd"
or stat -f %HT <&"$fd"
.
Telling if it's seekable
Applications generally do not care if stdout is a pipe though. They may care that it's seekable (though generally not to decide whether to buffer or not).
To test whether a fd is seekable (pipes, sockets, tty devices are not seekable, regular files and most block devices generally are), one can attempt a relative lseek()
system call with an offset of 0 (so innocuous). dd
is a standard utility that's an interface to lseek()
but it can't be used for that test, as implementations would not call lseek()
at all if you ask for an offset of 0.
The zsh
and ksh93
shells have builtin seeking operators though:
$ strace -e lseek ksh -c ': 1>#((CUR))' | cat
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
ksh: 1: not seekable
$ strace -e lseek zsh -c 'zmodload zsh/system; sysseek -w current -u 1 0 || syserror'
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
Illegal seek
Disabling the buffering
The script
command uses a pseudo-terminal pair to capture the output of a program, so the program's stdout (and stdin and stderr) will be a pseudo-terminal device.
When the stdout is to a terminal device, there is still generally some buffering, but it is line based. printf
/puts
and co will not write anything until a newline character is to be output. For other types of files, the buffering is by blocks (of a few kilo bytes).
There are several options to disable the buffering which are discussed in a number of Q&As here (search for unbuffer or stdbuf, Can't redirect cut output gives a few approaches) either by using a pseudo-terminal as can be done by socat
/script
/expect
/unbuffer
(an expect
script)/zsh
's zpty
or by injecting code in the executable to disable the buffering as done by GNU's or FreeBSD's stdbuf
.
Awesome answer, thank you very much for this!
– mowwwalker
9 hours ago
add a comment |
Telling if a file descriptor points to a terminal device
A program can tell if a file descriptor is associated with a tty device by using the isatty()
standard C function (which generally underneath does an innocuous tty-specific ioctl()
system call that would return with an error when the fd doesn't point to a tty device).
The [
/test
utility can do it with its -t
operator.
if [ -t 1 ]; then
echo stdout is open to a terminal
fi
Tracing libc function calls on a GNU/Linux system:
$ ltrace [ -t 1 ] | cat
[...]
isatty(1) = 0
[...]
Tracing system calls:
$ strace [ -t 1 ] | cat
[...]
ioctl(1, TCGETS, 0x7fffd9fb3010) = -1 ENOTTY (Inappropriate ioctl for device)
[...]
Telling if it points to a pipe
To determine whether a fd is associated with a pipe/fifo, one can use the fstat()
system call, which returns a structure whose st_mode
field contains the type and permissions of the file opened on that fd. The S_ISFIFO()
standard C macro can be used on that st_mode
field to determine if the fd is a pipe/fifo.
There is no standard utility that can do a fstat()
, but there are several incompatible implementations of a stat
command that can do it. zsh
's stat
builtin with stat -sf "$fd" +mode
which returns the mode as a string representation whose first character represents the type (p
for pipe). GNU stat
can do the same with stat -c %A - <&"$fd"
, but also has stat -c %F - <&"$fd"
to report the type alone. With BSD stat
: stat -f %St <&"$fd"
or stat -f %HT <&"$fd"
.
Telling if it's seekable
Applications generally do not care if stdout is a pipe though. They may care that it's seekable (though generally not to decide whether to buffer or not).
To test whether a fd is seekable (pipes, sockets, tty devices are not seekable, regular files and most block devices generally are), one can attempt a relative lseek()
system call with an offset of 0 (so innocuous). dd
is a standard utility that's an interface to lseek()
but it can't be used for that test, as implementations would not call lseek()
at all if you ask for an offset of 0.
The zsh
and ksh93
shells have builtin seeking operators though:
$ strace -e lseek ksh -c ': 1>#((CUR))' | cat
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
ksh: 1: not seekable
$ strace -e lseek zsh -c 'zmodload zsh/system; sysseek -w current -u 1 0 || syserror'
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
Illegal seek
Disabling the buffering
The script
command uses a pseudo-terminal pair to capture the output of a program, so the program's stdout (and stdin and stderr) will be a pseudo-terminal device.
When the stdout is to a terminal device, there is still generally some buffering, but it is line based. printf
/puts
and co will not write anything until a newline character is to be output. For other types of files, the buffering is by blocks (of a few kilo bytes).
There are several options to disable the buffering which are discussed in a number of Q&As here (search for unbuffer or stdbuf, Can't redirect cut output gives a few approaches) either by using a pseudo-terminal as can be done by socat
/script
/expect
/unbuffer
(an expect
script)/zsh
's zpty
or by injecting code in the executable to disable the buffering as done by GNU's or FreeBSD's stdbuf
.
Awesome answer, thank you very much for this!
– mowwwalker
9 hours ago
add a comment |
Telling if a file descriptor points to a terminal device
A program can tell if a file descriptor is associated with a tty device by using the isatty()
standard C function (which generally underneath does an innocuous tty-specific ioctl()
system call that would return with an error when the fd doesn't point to a tty device).
The [
/test
utility can do it with its -t
operator.
if [ -t 1 ]; then
echo stdout is open to a terminal
fi
Tracing libc function calls on a GNU/Linux system:
$ ltrace [ -t 1 ] | cat
[...]
isatty(1) = 0
[...]
Tracing system calls:
$ strace [ -t 1 ] | cat
[...]
ioctl(1, TCGETS, 0x7fffd9fb3010) = -1 ENOTTY (Inappropriate ioctl for device)
[...]
Telling if it points to a pipe
To determine whether a fd is associated with a pipe/fifo, one can use the fstat()
system call, which returns a structure whose st_mode
field contains the type and permissions of the file opened on that fd. The S_ISFIFO()
standard C macro can be used on that st_mode
field to determine if the fd is a pipe/fifo.
There is no standard utility that can do a fstat()
, but there are several incompatible implementations of a stat
command that can do it. zsh
's stat
builtin with stat -sf "$fd" +mode
which returns the mode as a string representation whose first character represents the type (p
for pipe). GNU stat
can do the same with stat -c %A - <&"$fd"
, but also has stat -c %F - <&"$fd"
to report the type alone. With BSD stat
: stat -f %St <&"$fd"
or stat -f %HT <&"$fd"
.
Telling if it's seekable
Applications generally do not care if stdout is a pipe though. They may care that it's seekable (though generally not to decide whether to buffer or not).
To test whether a fd is seekable (pipes, sockets, tty devices are not seekable, regular files and most block devices generally are), one can attempt a relative lseek()
system call with an offset of 0 (so innocuous). dd
is a standard utility that's an interface to lseek()
but it can't be used for that test, as implementations would not call lseek()
at all if you ask for an offset of 0.
The zsh
and ksh93
shells have builtin seeking operators though:
$ strace -e lseek ksh -c ': 1>#((CUR))' | cat
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
ksh: 1: not seekable
$ strace -e lseek zsh -c 'zmodload zsh/system; sysseek -w current -u 1 0 || syserror'
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
Illegal seek
Disabling the buffering
The script
command uses a pseudo-terminal pair to capture the output of a program, so the program's stdout (and stdin and stderr) will be a pseudo-terminal device.
When the stdout is to a terminal device, there is still generally some buffering, but it is line based. printf
/puts
and co will not write anything until a newline character is to be output. For other types of files, the buffering is by blocks (of a few kilo bytes).
There are several options to disable the buffering which are discussed in a number of Q&As here (search for unbuffer or stdbuf, Can't redirect cut output gives a few approaches) either by using a pseudo-terminal as can be done by socat
/script
/expect
/unbuffer
(an expect
script)/zsh
's zpty
or by injecting code in the executable to disable the buffering as done by GNU's or FreeBSD's stdbuf
.
Telling if a file descriptor points to a terminal device
A program can tell if a file descriptor is associated with a tty device by using the isatty()
standard C function (which generally underneath does an innocuous tty-specific ioctl()
system call that would return with an error when the fd doesn't point to a tty device).
The [
/test
utility can do it with its -t
operator.
if [ -t 1 ]; then
echo stdout is open to a terminal
fi
Tracing libc function calls on a GNU/Linux system:
$ ltrace [ -t 1 ] | cat
[...]
isatty(1) = 0
[...]
Tracing system calls:
$ strace [ -t 1 ] | cat
[...]
ioctl(1, TCGETS, 0x7fffd9fb3010) = -1 ENOTTY (Inappropriate ioctl for device)
[...]
Telling if it points to a pipe
To determine whether a fd is associated with a pipe/fifo, one can use the fstat()
system call, which returns a structure whose st_mode
field contains the type and permissions of the file opened on that fd. The S_ISFIFO()
standard C macro can be used on that st_mode
field to determine if the fd is a pipe/fifo.
There is no standard utility that can do a fstat()
, but there are several incompatible implementations of a stat
command that can do it. zsh
's stat
builtin with stat -sf "$fd" +mode
which returns the mode as a string representation whose first character represents the type (p
for pipe). GNU stat
can do the same with stat -c %A - <&"$fd"
, but also has stat -c %F - <&"$fd"
to report the type alone. With BSD stat
: stat -f %St <&"$fd"
or stat -f %HT <&"$fd"
.
Telling if it's seekable
Applications generally do not care if stdout is a pipe though. They may care that it's seekable (though generally not to decide whether to buffer or not).
To test whether a fd is seekable (pipes, sockets, tty devices are not seekable, regular files and most block devices generally are), one can attempt a relative lseek()
system call with an offset of 0 (so innocuous). dd
is a standard utility that's an interface to lseek()
but it can't be used for that test, as implementations would not call lseek()
at all if you ask for an offset of 0.
The zsh
and ksh93
shells have builtin seeking operators though:
$ strace -e lseek ksh -c ': 1>#((CUR))' | cat
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
ksh: 1: not seekable
$ strace -e lseek zsh -c 'zmodload zsh/system; sysseek -w current -u 1 0 || syserror'
lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
Illegal seek
Disabling the buffering
The script
command uses a pseudo-terminal pair to capture the output of a program, so the program's stdout (and stdin and stderr) will be a pseudo-terminal device.
When the stdout is to a terminal device, there is still generally some buffering, but it is line based. printf
/puts
and co will not write anything until a newline character is to be output. For other types of files, the buffering is by blocks (of a few kilo bytes).
There are several options to disable the buffering which are discussed in a number of Q&As here (search for unbuffer or stdbuf, Can't redirect cut output gives a few approaches) either by using a pseudo-terminal as can be done by socat
/script
/expect
/unbuffer
(an expect
script)/zsh
's zpty
or by injecting code in the executable to disable the buffering as done by GNU's or FreeBSD's stdbuf
.
edited 18 mins ago
answered 10 hours ago
Stéphane ChazelasStéphane Chazelas
316k57599957
316k57599957
Awesome answer, thank you very much for this!
– mowwwalker
9 hours ago
add a comment |
Awesome answer, thank you very much for this!
– mowwwalker
9 hours ago
Awesome answer, thank you very much for this!
– mowwwalker
9 hours ago
Awesome answer, thank you very much for this!
– mowwwalker
9 hours ago
add a comment |
mowwwalker is a new contributor. Be nice, and check out our Code of Conduct.
mowwwalker is a new contributor. Be nice, and check out our Code of Conduct.
mowwwalker is a new contributor. Be nice, and check out our Code of Conduct.
mowwwalker is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f515778%2fhow-does-a-program-know-if-stdout-is-connected-to-a-terminal-or-a-pipe%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
A related question is unix.stackexchange.com/q/513926/5132 .
– JdeBP
7 hours ago