0

I want to do a simple grep on dumpe2fs output but I keep seeing dumpe2fs 1.46.5 (30-Dec-2021) showing up after my grep:

$ sudo dumpe2fs -h /dev/sdb2 | grep 'Block count:' dumpe2fs 1.46.5 (30-Dec-2021) Block count: 1247300

But if I redirect stderr of dumpe2fs to stdout using |& then it will just work fine as expected:

$ sudo dumpe2fs -h /dev/sdb2 |& grep 'Block count:' Block count: 1247300

The question is why dumpe2fs is writing version number dumpe2fs 1.46.5 (30-Dec-2021) to stderr?!

Improve this question
7
  • I’m voting to close this question because "Why some tool does X" is a usually pointless question, as usually the answer is "because someone felt it was useful to do X and spent time and effort implementing it". Commented Feb 20 at 3:40
  • 2
    @muru, I don't know. It might not be such a pointless question in general, since for a lot of the behaviours of standard / common tools, there might well be a reasonable technical explanation, one that a reasonably experienced user might be able to at least guess at (if not even able to point at documantion explaining it). Of course in some cases, there might not be such clear-cut reasons, and it could go back to what the developer felt was good at the time. (Or what the developer of the original version ended up with 50 years ago on their PDP-11.) Commented Feb 21 at 10:47
  • Some tools print their help texts to stderr, even if explicitely called as sometool --help. Well, I suppose it's not like the normal output of the tool, but always meant for the user, similarly to actual error messages. But it makes it a bit annoying to try to grep a longer output for a particular option... GNU tools seem to print help texts to stdout, so it can go both ways. Commented Feb 21 at 10:50
  • @ilkkachu there might be. And if someone can bring evidence of an actual technical reason, sure, we can always reopen. But I would swap "a lot" and "some". And I personally would rather such questions be answered with facts rather than guesses, whether from users experienced or otherwise. Guesses are how myths are born and propagated. Commented Feb 21 at 10:54
  • 2
    It seems to me there are two parts to this question: one is “why does this go to standard error?”, and that’s addressed by this Q&A; the other is “why does dumpe2fs always show its version?”, and that can only be answered by its authors. Ted Ts’o at least does frequent this site, so that’s not impossible (and someone could just ask directly). Commented Feb 23 at 14:40

1 Answer 1

Reset to default
1

I've seen this with the fuser command, and I believe the developer understands that stdout is very commonly piped to other commands, so the type of output that other commands can parse and use is sent via stdout, while the type of output that's useful only when viewed by human beings is sent via stderr.

Fuser intermixes its output a lot. It alternates between stdout and stderr - the filename and a colon to stderr, a space and multiple pid digits to stdout, a single suffix letter to stderr, and back to stdout for the next pid's space and digits. The spaces and pid digits are useful for piping to grep, awk, sed, etc., but the filename at the start of the line and the letter suffixes are not. However, for the human being who is letting the output go to his/her terminal window, all the info is useful.

The output of dumpe2fs is probably the same way. The stuff that's easy to parse with grep/awk/sed/etc is written to stdout, while the stuff you don't want to bother parsing (the version string) is written to stderr.

I don't know the developers of either of these programs, so I can't speak with any authority. But this is what I think the reason is.

Improve this answer
2
  • 1
    It looks like it's even documented in the man page: "fuser outputs only the PIDs to stdout, everything else is sent to stderr.". That does seem like a rather extreme case, though, and a bit counterproductive even, IMO. Even if it makes sense regarding piping, it means something like whatever $(fuser foo) would leak the filenames to the terminal, and you'd have to explicitly redirect stderr. In which case one could just use an explicit option to only ask for the PIDs, if the tool had one. :) But it does have options for the common case of sending signals to the listed processes directly. Commented Feb 21 at 10:54
  • @ilkkachu I agree. I don't say it's a good practice to output things that aren't errors to stderr. I'm just explaining the apparent reasoning behind the behavior. Commented Feb 21 at 23:16

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.