3 ms·

How can you grep output if there's no output? Can you provide a concrete example of such an application?

d3VwsX 2y ago
Some applications print usage information (e.g. with --help flag) to stderr. That is a bit annoying when there is a lot of output and I just want to grep for some flag, since the first attempt will fail and then I have to try again after adding 2>&1.
- quectophoton 2y ago
  Then there's `ssh-keyscan`, printing the "real" output to stdout, but also printing "comments" to stderr. Nothing wrong with that, but it was a bit confusing the first time I saw that behavior.
- matheusmoreira 2y ago
  If I pass the --help flag, I'm explicitly asking the program to print the help text. In this case it's appropriate for the help text to be written to standard output since the help text is the output. If the user passes invalid options and inputs, then the program should produce no output and any error or help messages should be written to the error stream. It's important that these messages end up on the terminal when one gets the command invocation wrong while trying to pipe data into another program. If they're written to standard output, the program on the other end of the pipe will slurp all the error messages up and try to parse them as though they were valid inputs.
quectophoton 2y ago
I think what they meant was something like: > Unless your app doesn't generate [stdout] output,then grepping the [visible] output will not work if it's stderr and it will be confusing With the first "output" meaning "specifically stdout", and the second meaning "what you see on the terminal". As in, you run a command, see it printed a lot of stuff, so then you do it again but piping it to `grep` or `less`, and realize none of that output was actually going to stdout.
- matheusmoreira 2y ago
  I see what you mean. My logic only really applies to the simpler programs which exclusively use the standard file descriptors. It gets fuzzier when the output of a program is an actual file somewhere. The output of a package manager is the packages. The text it writes to the terminal is not part of the output, it's just the program's log. I haven't thought about what's appropriate in this situation. By unix standards package managers shouldn't even be printing anything to begin with.

Some applications print usage information (e.g. with --help flag) to stderr. That is a bit annoying when there is a lot of output and I just want to grep for some flag, since the first attempt will fail and then I have to try again after adding 2>&1.

quectophoton 2y ago
Then there's `ssh-keyscan`, printing the "real" output to stdout, but also printing "comments" to stderr. Nothing wrong with that, but it was a bit confusing the first time I saw that behavior.
matheusmoreira 2y ago
If I pass the --help flag, I'm explicitly asking the program to print the help text. In this case it's appropriate for the help text to be written to standard output since the help text is the output. If the user passes invalid options and inputs, then the program should produce no output and any error or help messages should be written to the error stream. It's important that these messages end up on the terminal when one gets the command invocation wrong while trying to pipe data into another program. If they're written to standard output, the program on the other end of the pipe will slurp all the error messages up and try to parse them as though they were valid inputs.

quectophoton 2y ago

I think what they meant was something like: > Unless your app doesn't generate [stdout] output,then grepping the [visible] output will not work if it's stderr and it will be confusing With the first "output" meaning "specifically stdout", and the second meaning "what you see on the terminal". As in, you run a command, see it printed a lot of stuff, so then you do it again but piping it to `grep` or `less`, and realize none of that output was actually going to stdout.

matheusmoreira 2y ago
I see what you mean. My logic only really applies to the simpler programs which exclusively use the standard file descriptors. It gets fuzzier when the output of a program is an actual file somewhere. The output of a package manager is the packages. The text it writes to the terminal is not part of the output, it's just the program's log. I haven't thought about what's appropriate in this situation. By unix standards package managers shouldn't even be printing anything to begin with.