Writing output to file, similar to "script" command?

Question

Is there anything that's similar to "script" but does not require the terminal to be open?

I want to save the results from my program into a file, however I have some issues. I need to work remotely but I have bad internet connection. Thus I usually run:

./MyProgram.exe > output.txt &

And the results from my program are saved into the output.txt file.

However, when I run my program on certain objects I received a "SIGSEGV: Segmentation fault" error. The program quits and that is okay, I know it will do this. But I end up loosing all my data from previous objects before the program came across this problematic object that causes the errort.

How can I record everything, the results from the non-problematic objects as well as this error, into a file/s?

I have tried:

./MyProgram.exe > output.txt 2>&1 &

./MyProgram.exe > output.txt 2> error.txt &

./MyProgram.exe > & error-n-output.txt &

But all of the above just record the segmentation error but not the results from the previous objects, even though I know the program does work for the previous objects.

I have also tried the script command by typing as follows:

Myname@Computer ~/Folder $ script screen.log
Script started, file is screen.log
Myname@Computer ~/Folder $./MyProgram.exe
~~~THE RESULTS AND THE SEGMENTATION ERROR ARE PRINTED ON SCREEN SO I CAN RECORD THE RESULTS FOR SOME OBJECTS AND IGNORE THE ERROR~~
Myname@Computer ~/Folder $ exit
exit
Script done, file is screen.log

And everything that was on screen is recorded in the screen.log file. This may be fine, however, due to my bad internet connection I cannot leave the screen running for a long time. I need to exit from the terminal but of course my program quits and nothing is written in the "screen.log" file.

Is there anything that's similar to script but does not require the terminal to be open?

Answer 1

nohup is probably what you want. nohup's purpose is to "run a command, ignoring hangup signals". In other words, if your ssh, telnet, serial, etc connection disconnects for any reason (other than the host crashing, shutting down, or rebooting, of course), your program will keep running.

You probably also want to run the nohup-ed command in the background (using &) as all output will be redirected to a file.

For example:

nohup MyProgram.exe &

By default, it will save output to ./nohup.out or ~/nohup.out but you can redirect to a different file if you want. From the man page:

If standard input is a terminal, redirect it from an unreadable file. If standard output is a terminal, append output to nohup.out if possible, $HOME/nohup.out otherwise. If standard error is a terminal, redirect it to standard output. To save output to FILE, use nohup COMMAND > FILE.

nohup is best used for non-interactive programs that don't expect input from users.

If you need to run a program that interacts directly with users (e.g. an ncurses application), use a terminal multiplexer like GNU screen, or tmux, or byobu or similar instead of nohup.

Terminal multiplexers not only make your program immune to hangup signals, they also allow you to re-connect to the same shell session (and your running program) when you log in again after a disconnection. They also enable multiple shell sessions over the one connection (e.g. ssh to your remote machine, run screen, and you can create, destroy, and switch between as many shell "windows" as you like).

BTW, these programs all give you your standard shell so you can run script inside them if you choose.

I've linked to the home pages of these programs, but you probably don't need to compile them to install - they're available as pre-compiled packages for most (all?) Linux distros, FreeBSD, Mac OS X, solaris, and more.

Answer 2

When you want to append to the standard output, you can use >> instead of just >:

./MyProgram.exe >> output.txt 2> error.txt &

This will prevent your output to be overwritten every time.

That obviously won't stop the process from exiting when the session closes. If nohup is available, you should use it to start your program and it will allow it to continue running even if the session is closed.

Answer 3

Try the command

stdbuf -oL ./MyProgram.exe > output.txt

The standard output of programs is, by default, line buffered if the output is a terminal, but buffered in 4kB chunks if the output is a regular file (which is the case now, since you redirect it to output.txt).

This means that the standard stdio functions (such as printf()) collect the data up to 4kB before actually writing it out. If your utility crashes then – too bad – this last chunk that has not been written out yet is lost.

stdbuf -oL sets the standard output to be line buffered, even if the output goes to a regular file.

(Although, no doubt, the cleanest solution would be to fix your application not to crash.)

You might further combine this with nohup or screen, as shown in other answers.

Answer 4

Just try something like:

program.exe &> /temp/output.log ;
# OR #
program.exe &> /temp/output.log &

---

In some circumstances, you might like to keep an eye on it as it changes, with something like:

watch cat /temp/output.log
# OR #
watch --diff cat /temp/output.log

Or similarly:

watch tail /temp/output.log
# OR #
watch --diff tail /temp/output.log

---

It's kind of difficult to ascertain exactly what it is you want, but you might find the following utilities useful:

script
# OR #
asciinema

---

Failing all that- you should probably look at using a debugger, decompiler, disassembler, etc.

Let me know how you go and I'll adjust this post accordingly.