My version of curl only prints the progress junk to stderr if you pipe stdout somewhere. I guess I've never had a problem since I don't use a pager usually.

BTW, how do you detect whether your program's stdout is being piped to something other than the shell?

> My version of curl only prints the progress junk to stderr if you pipe stdout somewhere.

Hmm, good point -- I actually hadn't noticed that, and it seems to be the case on mine as well. (Though I rarely use it without piping or stdout-redirecting to something, so it still strikes me as inappropriate.)

> BTW, how do you detect whether your program's stdout is being piped to something other than the shell?

In the three languages I've used recently enough to remember:

C: int isatty(int fd); /* from unistd.h */

Python: os.isatty

Shell (bourne): [ -t 1 ] # exits 0 if stdout is a tty, 1 if not

Instead of os.isatty(sys.stdout.fileno()) (ew) you should just use sys.stdout.isatty(). In addition to being shorter, it will work everywhere [that Python does], not just Unix.

Actually, it is very much unix style. With any modern shell you can simply turn off stderr, or only put stdout in the pipe, or put 2>/dev/null and so on. If both went to stdout then it would be a reasonable complaint.

> With any modern shell you can simply turn off stderr, or only put stdout in the pipe, or put 2>/dev/null and so on.

Or I could type fewer extra characters by using the '-s' flag, as I described in my comment. My point was about its default mode of operation: "noisy" (which is not, as I see it, a characteristic of "traditional unix" tools).

Edit: Additionally, if both went to stdout the tool would be completely unusable -- I'd simply file that under "data corruption".

That is not really a good assertion. Look at grep: default output is filename, line number, relevant line. This is far from a minimalist output. Or du, which by default lists all the files and subdirectories and their sizes. Minimal, quiet output doesn't define "traditional unix" style -- the ability to taylor the output to the situation, and further make the output as machine readable as possible is what makes it "unixy".

This is probably going on longer than it merits, but...

Those aren't really good comparisons.

Perhaps you have a different version of grep than I do, but my grep only prints filenames when more than one file has been specified for searching (in which case showing which file the match is from is necessary, I'd say), and certainly doesn't print line numbers if I don't give it '-n':

  [me@host: ~]% grep PATH /etc/bashrc 
  		if ! echo $PATH | /bin/egrep -q "(^|:)$1($|:)" ; then
  				PATH=$PATH:$1
  				PATH=$1:$PATH
  [me@host: ~]% grep PATH /etc/bashrc /etc/profile
  /etc/bashrc:		if ! echo $PATH | /bin/egrep -q "(^|:)$1($|:)" ; then
  /etc/bashrc:				PATH=$PATH:$1
  /etc/bashrc:				PATH=$1:$PATH
  /etc/profile:	if ! echo $PATH | /bin/egrep -q "(^|:)$1($|:)" ; then
  /etc/profile:	      PATH=$PATH:$1
  /etc/profile:	      PATH=$1:$PATH
  /etc/profile:export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE
  /etc/profile:export PATH
  [me@host: ~]% grep -V
  grep (GNU grep) 2.5.1

As for du...well, frankly I'd prefer if du's output were less verbose -- a default more like 'du --max-depth=1' would be more to my liking. Compare to 'ls' vs. 'ls -R' (though I realize du does need to operate recursively regardless of whether it prints a line for everything it finds, so perhaps that's not an ideal comparison).

But the main difference here is the nature of what they're printing. In both of the above cases, the extra output text is still much more immediately relevant to the program's real task than what curl prints to stderr. For a more direct analogy, it would be like grep printing to stderr '50MB searched, 974MB remaining...' as it searches through a 1GB file.