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
Myname@Computer ~/Folder $ 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?

  • This is exactly what screen is for.
    – DopeGhoti
    May 13, 2016 at 22:54
  • @DopeGhoti It seems this is a program that needs to be installed. I would like not installing anything new, but just working with the commands available, if there's anything else.
    – Guest
    May 14, 2016 at 1:10
  • when you write static, do you mean script?
    – cas
    May 14, 2016 at 4:29
  • GNU screen is a very common/popular utility. It comes pre-installed on the majority of Linux distributions (and I think, modern UNIX variants, in general). if it's not installed by default.. It probably should be.
    – voices
    May 14, 2016 at 5:34
  • 1
    On the other hand; I've never heard of static. What is that?
    – voices
    May 14, 2016 at 5:51

4 Answers 4


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.


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.

  • For some reason I still get an empty output.txt file but the error does write to error.txt. I tried doing ./MyProgram.exe >>& output.txt & but received a syntax error. I'm not sure why.
    – Guest
    May 14, 2016 at 1:08
  • Well if you get an empty output, it means that the program produced no output. Since it gave you an error, it probably got the error before outputting anything. May 14, 2016 at 1:14
  • Strange, it does produce an output before the error when I write it to screen in the terminal. Maybe I will try it again.
    – Guest
    May 14, 2016 at 1:37
  • What's the error message? (wondering if it could be linked to redirection) May 14, 2016 at 2:12
  • The error is: "Program received signal SIGSEGV: Segmentation fault - invalid memory reference." The program quits after this error occurs and it's okay. But knowing the output before it reaches this error helps me remove the data that causes this problem.
    – Guest
    May 14, 2016 at 2:31

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.

  • Cool, so this basically spools out the stdout; line by line?
    – voices
    May 14, 2016 at 6:53

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:

# OR #

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .