I think stdout, so you can easily grep, what do you think?
Only errors go to stderr. This is in no way an error, it does exactly what the user had in mind, which is print usage information.
Always stdout, makes it easier to pipe to less, grep it etc.
If you are showing the help text because there was a problem with parsing the command line arguments, then you might use stderr.
Well, it's an explicit request for help so it's output. If for some reason you can't output the help or the user mis-spells "help" then, by all means, send that to error :-)
Users that know what they're doing can use the infamous "2>&1" if they want errors on standard output.
It's not an error, so I'd say stdout....
netcat is the only application I can think of that would redirect -h to stderr, and I can't for the life of me fathom why.
I suppose if you're outputting the help information because someone used improper arguments, you might want to redirect it to stderr, but personally even then I wouldn't use stderr because I don't think spamming error logs with fullblown help text is useful - I'd rather just output a single error pointing out the arguments were malformed to stderr. If someone is explicitly calling your application using -h or --help, then you really shouldn't redirect it to stderr.
Related
I'm using bash, but perhaps most shells behave similarly in this regard. If not, then my question pertains to bash.
There's a regularly used command that always issues a spurious error message (to stderr), but MAY sometimes issue error messages that are important. I figured I could pipe stderr to grep, then use -v option to filter the offending line that's otherwise noise. Whatever passes through the filter on stderr should go right back to the original destination (presumably the user's terminal). How do I do this?
(Getting the source and editing it to make a custom version that doesn't spit out that error is obviously possible but out of the question for practical reasons.)
Output grep output to stderr.
thecommand 2> >(grep -v 'something' >&2)
i know what they are, but i dunno when i should use them. Are they useful? I think yes, but I want you to tell me in which situations a file descriptor could be useful. Thanks :D
The most obvious case which springs to mind is:
myProgram >myProgram.output_and_error 2>&1
which sends both standard output and error to the same file.
I've also used:
myProgram 2>&1 | less
which will allow me to page through the output and error in sequence (rather than having error got to the terminal in "arbitrary" places in the output).
Basically, any time when you need to get at an already existing file descriptor, you'll find yourself using this.
I have a ghostscript command, when the file I input is wrong, ghostscript fail and print a error message.
So far so good, I do a simple script apply the command on multiple files, and tell me how many files failed.
But ghostscript print error on stdout, and nothing to stdout.
While searching, I found the -sstdout flag, but in that case, everything goes to stderr and nothing to stdout.
Is there a way to simply and programatically tell if ghostscript encountered a error?
(A ugly workaround would be to search for 'error' in stdout, but that s just plain bad).
Is there a way to tell ghostscript to use stdout and stderr like thoses are supposed to be used? For separate standard and error output?
I ve found another workaround, since I don t need stdout, I added the flags -q -sstdout=%stderr.
-q suspress all non error message (in my case)
-sstdout=%stderr redirect stdout to stderr, in my case it mean the error messages.
if you do
ipconfig.exe 1> output.log 2>&1
this will direct all output(both stdout and stderr) to "output.log".
However, if you do (changing the order in which you specify desired redirections)
ipconfig.exe 2>&1 1> output.log
this will not achieve the intended effect of printing both output streams to "output.log" because "stderr" in this case will be printed to the console.
I suspect this has to do with the way "cmd" parses commands that gives different meanings depending on the order in which you specify redirects.
If so, what are the semantic rules and where are they documented?
I reckon this is something worth finding out as it could waste people hours by making them scratching their head trying to figure out why their redirection is not working.
The redirections are simply parsed left to right. Initially stdout and stderr are pointing to the console, so when you redirect stderr to where stdout is currently pointing in the second example, you are directing stderr to the console. You then subsequently redirect stdout to a file.
The explanations and examples here are quite good for further reference.
I am experiencing an issue whereby I cannot completely redirect output from an executable. For discussion, let's say the executable is printnames.exe.
If I do printnames.exe (without redirection), the following output is displayed in the command window:
Adam
Tim
Jesse
Sean
However if I do printnames.exe > myfile.txt, the command window shows:
Tim
Sean
...and the contents of myfile.txt is:
Adam
Jesse
How is this possible? What in the code can cause such behavior? Shouldn't the redirection operator redirect all output?
How is this possible?
You have two output streams.
What in the code can cause such behavior?
Writing to standard output and also writing to standard error.
Shouldn't the redirection operator redirect all output?
No. Default redirection applies to standard output.
Use 2> to redirect standard error.
http://www.gnu.org/software/bash/manual/bashref.html#Redirections