Mrthfx

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?

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.