[SOLVED] Anomalies when directing terminal output to a file

[ternor]

Hello.  Until recently I was able to use a line such as the following in a terminal to create a text file containing the terminal output:

Code: [Select]

kwrite --help > /data/lib/software/kwrite
For kwrite the code still works.  I forget the other names I have tried recently but I have today tried the following:

Code: [Select]

mylivecd --help > /data/lib/software/mylivecd
That resulted in the output appearing in the terminal and an empty file 'mylivecd'.  I have tried using >> to append the output to the empty file but that doesn't work either.

Can anyone shed light on this new development?

[TerryN]

Linux has 2 output streams called stdout and stderr.

Normal program output is written to stdout and usually error messages and the like go to stderr.  By default both streams are sent to your terminal (window) but can be redirected to files using the > and >> characters.
When you do your redirect as > or >> you are redirecting stdout
mylivecd is writing the help text to stderr so you need to do 2> or 2>> which will redirect stderr (note: no space between 2 and >)

Terry

[Just17]

Thanks TerryN ....  I also had come across this but never followed it up and did not know why.

Now all I have to do is remember it in the future ....  

Is there a reason why some output to stderr and not stdout?

[TerryN]

Is there a reason why some output to stderr and not stdout?

A lot of commands output the help text if you specify an incorrect option or parameter.  If the command output is redirected you wouldn't see the help text (without looking in the file).

Terry

[Just17]

Is there a reason why some output to stderr and not stdout?

A lot of commands output the help text if you specify an incorrect option or parameter.  If the command output is redirected you wouldn't see the help text (without looking in the file).

Terry

Does that mean that all commands that output the help info when an error is met do so to stderr, and never to stdout, even if -help is specifically called?

Sorry for the multiple questions ...... trying to get it sorted in my head after only one cup of coffee .....

[TerryN]

Does that mean that all commands that output the help info when an error is met do so to stderr, and never to stdout, even if -help is specifically called?

It is entirely up to the developer.  Different developers have different views.  If your command generates output which is likely to be redirected (i.e. most command line tools) then it makes sense to send the help text to stderr (that's MY view  ).

Developers are notoriously lazy and would not write 2 different routines for --help and invalid parameter cases  

Terry.

[Just17]

Thanks 

[Bald Brick]

Does that mean that all commands that output the help info when an error is met do so to stderr, and never to stdout, even if -help is specifically called?

It is entirely up to the developer.  Different developers have different views.  If your command generates output which is likely to be redirected (i.e. most command line tools) then it makes sense to send the help text to stderr (that's MY view  ).

It does make sense, but it means that output from commands with the --help option is treated differently depending on the command in question. To me this sounds like a bug in those commands that send the output to standard error.

With the --help option most binary applications (as for instance muungwana's zuluCrypt-cli) send output to standard output. So do pinoc's scripts lomanager and addlocale (lusbc).

But some scripts, like mylivecd, send it to standard error. And this is inconsistent. (So perhaps standard error and standard output need some semantic standardisation.)

Developers are notoriously lazy and would not write 2 different routines for --help and invalid parameter cases  

Terry.

You said it.  

[ternor]

Thanks for the replies.  2> does the job.  I assume it can be used whenever writing output to a file?

[TerryN]

Thanks for the replies.  2> does the job.  I assume it can be used whenever writing output to a file?

Yep, it's the same as > except that it redirects the stderr stream.
If you want to redirect both streams to the same file you can use >outfile 2>&1

Terry

[Bald Brick]

Thanks for the replies.  2> does the job.  I assume it can be used whenever writing output to a file?

It only works if the output is sent to stderr (standard error). It doesn't work if the output is sent to stdout (standard output). That is the problem.

If you want to write all output to a file you can nowadays use something like

Code: [Select]

mylivecd --help &> /data/lib/software/mylivecd
TerryN's traditional syntax naturally also works:

Code: [Select]

mylivecd --help > /data/lib/software/mylivecd 2>&1

[ternor]

Thanks.  More thinking is required on my part.  I used mylivecd --help 2> /data/lib/software/mylivecd which, I now gather, is incorrect (even though it produced a help file).  The two commands you list also work.

[TerryN]

How is it incorrect if it produced a help file 

Terry

[ternor]

OK.  Now I have 3 options but the first apparently only works if the application outputs to stderr, so I shall use the first option quoted by Bald Brick.  My thanks to both of you.

EDIT: The code kwrite --help 2> /data/lib/software/kwrite1 produces output in the terminal and an empty kwrite1 file.

[The Chief]

OK.  Now I have 3 options but the first apparently only works if the application outputs to stderr, so I shall use the first option quoted by Bald Brick.  My thanks to both of you.

EDIT: The code kwrite --help 2> /data/lib/software/kwrite1 produces output in the terminal and an empty kwrite1 file.

So apparently, kwrite sends the help file to stdout, and true errors to stderr.  As someone said, it's the developers choice. 

If the normal response (of the given program) to an invalid parameter is simply to print the help, then it makes sense to write the help to stderr, in case the normal output has been redirected.  If each possible error has it's own error message, then it makes sense to write the help to stdout, and the error messages to stderr.