Came here to say this. I can imagine a lot of people instead of doing -o were just redirecting output... if this changes the behavior of that, then a lot of people are not going to be happy when a curl upgrade breaks scripts.

It won't because 'isatty' returns false for a pipe. So that should not break anything unless you plan on sending binary output to your terminal which is a bad idea anyway, but they allow you to override the default as per TFA.

You can trick isatty, but only if you're very, very set on doing so. It requires allocating a psuedo-TTY, and attaching it.

cURL already use isatty checks elsewhere, such as to determine if progress info should be printed (will only show if you're not outputting to tty).

Sure, but that's exactly what a pseudo-TTY is supposed to do, pretend it is a TTY when actually it is a pipe so isatty will return true.

So that's not so much tricking isatty as much as using the system in the way it is intended. If you do that without the required background information then you have only yourself to blame.

A pipe is different from a pseudo-TTY. Pseudo-TTYs are how all graphical terminals work, but all shells use simple pipes on redirection and pipe-composition. TTYs and pseudo-TTYs are supposed to be interactive, with a user sitting on the other end with a keyboard. Plenty of tools make their output different based on if they're outputting to a tty or not, e.g. ls and others do not colourise by default if not outputting to a tty, as colour control characters are usually not what you want dumped to a text file or piped to grep. I feel this change brings curl more in-line with other terminal programs that try to be good citizens.

Psuedo-TTY's come in pairs, one end for the application to connect to, the other for whatever is consuming the output or producing input to the application. So, yes, of course they are not pipes but they are similar in that you have two end-points. So pipes and pseudo-tty's have quite a bit in common, thinking of a pseudo-tty pair as a pipe that knows how to deal with a bunch of terminal specific ioctl calls is a pretty good approximation.

Considering it a pipe is a very rough approximation, though. The only purpose of PTYs is to provide access to a TTY with all its bells and whistles (kernel provided line editing, yay!) in a world without hard terminals.

The psuedo-TTY subsystem is designed to allow user sessions with virtual, rather than hard terminals. Telnet, ssh, terminal emulators. It provides everything you would expect from a tty. Cooked mode, baudrate control (despite redundant), all that jazz.

Its purpose is not just to make isatty return true. If you spin up that giant subsystem to trick an application into a different behavior on a simple pipe, then I believe it is appropriate to call it a hack, trick, workaround or similar.

> You can trick isatty, but only if you're very, very set on doing so. It requires allocating a psuedo-TTY, and attaching it.

You can also LD_PRELOAD an isatty shim that returns true. This is occasionally useful when piping the output of tools which disable ANSI colorization with no switch to re-enable that.

"script" is also a quick and dirty hack. It's a small tool meant to record a shell session, but if you set the output to /dev/null, it is effectively just a pty wrapper. Quicker than writing a shim.

Never thought of that, that is a neat trick, thank you.

And note that isatty() works on a file descriptor, and that you might be outputting to both stderr and stdout, and both, neither, or some weird combination might be a tty. (i.e., you need to check for the file descriptor you're going to output to.)

Some programs will check if stdout is a tty prior to writing to stderr, for example, which means that if you're doing,

  foo | bar

foo's stderr will go to the tty, but would lose coloring, for example. For example, `babel`, a JS transpiler, loses the color in its error messages when you pipe its output.