LinuxQuestions.org - > not writing output to file

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - > not writing output to file (https://www.linuxquestions.org/questions/linux-newbie-8/not-writing-output-to-file-4175515881/)

> not writing output to file

Dear All, Kindly help in debugging an issue where in my server using the > operator does not write output to file, although it shows output in putty.
Server SunOS 5.10
Thanks

Could you tell us more? You provided very little information for us to work with, but I will try to help.

The > operator will redirect the normal output (stdout) to a file, but not error messages (stderr). If you wish to output both stdout and stderr to a file, use the 2> operator, or &> if your system has it:

Code:

# redirect stdout but not stderr:

date > $logfile



# redirect stderr but not stdout:

date 2> $logfile



# redirect both stdout and stderr in the old way:

date > $logfile 2>&1



# redirect both stdout and stderr in the new way (since bash 4):

date &> $logfile

Next point: The > operator overwrites the previous file. Use >> to append to an existing file.

Code:

# (see above comments)



date >> $logfile



date 2>> $logfile



date >> $logfile 2>&1



date &>> $logfile

Finally, bear in mind that > and >> write to the current working directory, unless you specify the full path of the output file. Perhaps your output has been redirected to a file but you are looking for it in the wrong directory.

Thank you for your time, Beryllos. I have tried the following

Code:

ls >output.txt



ls >>output.txt



nohup READGFILE -d /SASG /D0 >output.txt 2>output.err &

This is creating a 0kb file only it doesn't have any data. I have tried both > and >>. And the directory contains files it is not empty.

Quote:

Originally Posted by Beryllos (Post 5225227)

Code:

# redirect stdout but not stderr:

date > $logfile



# redirect stderr but not stdout:

date 2> $logfile



# redirect both stdout and stderr in the old way:

date > $logfile 2>&1



# redirect both stdout and stderr in the new way (since bash 4):

date &> $logfile

Next point: The > operator overwrites the previous file. Use >> to append to an existing file.

Code:

# (see above comments)



date >> $logfile



date 2>> $logfile



date >> $logfile 2>&1



date &>> $logfile

Quote:

Originally Posted by sarfrazs (Post 5225330)

Code:

ls >output.txt



ls >>output.txt



nohup READGFILE -d /SASG /D0 >output.txt 2>output.err &

That redirection will truncate output.txt to zero length and then redirect the stdout from the nohup process to that now empty file. Since that removes the output from the previous ls processes, I doubt that is what you intended.

Quote:

Originally Posted by sarfrazs (Post 5225330)

Thank you for your time, Beryllos. I have tried the following

Code:

ls >output.txt



ls >>output.txt



nohup READGFILE -d /SASG /D0 >output.txt 2>output.err &

This is creating a 0kb file only it doesn't have any data. I have tried both > and >>. And the directory contains files it is not empty.

I don't know. Does output.err contain anything? What happens if you do it without the nohup? Does READGFILE do anything? If I do the following, it works as expected:

Code:

nohup ls >output.txt 2>output.err

Then the output of ls appears in output.txt and an error message from nohup appears in output.err. Does it work that way for you?

is READGFILE a long process? The output to output.txt and output.err will be buffered, which means you might not see anything for some time, depending on how quickly READGFILE is printing it out.