Can I recover a nano process from a previous terminal?

Reading nano man page, and some search, I found:

In some cases nano will try to dump the buffer into an emergency file. This will happen mainly if nano receives a SIGHUP or SIGTERM or runs out of memory. It will write the buffer into a file named nano.save if the buffer didn't have a name already, or will add a ".save" suffix to the current filename. If an emergency file with that name already exists in the current directory, it will add ".save" plus a number (e.g. ".save.1") to the current filename in order to make it unique. In multibuffer mode, nano will write all the open buffers to their respective emergency files.

So you should maybe already have such a file waiting for you, somewhere on your system.

find /likely/path -mtime -1 -print | egrep -i '\.save$|\.save\.[1-90]*$'

(/likely/path being first the place where you launched nano from, then other such "possible" places, then in last resort: / (of course, launch that last find command as root or expect a lot of error output, which you could redirect away using your shell's STDERR redirection)

-mtime -1 says "up to 1 day old", you may want to change the value to -2, or -3, depending on when you edited the file and when you read this.

In the event nano did not yet write such a file, you could try to send it a SIGHUP signal to force it to do so (see: http://en.wikipedia.org/wiki/Unix_signal#POSIX_signals )

And then, run the find again to look for that file...

And in last, last resort, you could play with grepping through /proc/kmem for parts of the text you are looking for, but this will necessitate some precautions to sanitize what it shows you, and could be not trivial. or dd it first into a (as big as your memory) file.

So, this may not be an option for you, but I just sent a reboot command to the box. When it came back online, Viola- file.py.save was put in the directory.

It does work as mentioned by @Oliver Dulac, but in some situations instead dumping the buffer to a file Nano just interpret and keep waiting from a user command, but there are more options without reboot:

pkill -SIGHUP -e nano
pkill -SIGTERM -e nano
pkill -SIGILL -e nano

but the program can choose to ignore those 3 signals above, hence try they in the order above, then check if the file was create, and if it do not work, try the same signal as performing reboot (that is sent after SIGTERM)

pkill -SIGKILL -e nano

keep in your mind that those are signals to the program, the ones in the top can be interpreted and ignored by the running program, the last one.

• SIGHUP tell the program that the terminal in which it was running very common thing via SSH
• SIGTERM is the user signal to nicely close a program, but it can be ignored if the program needs something (ie. should it save the buffer over the file?)
• SIGILL inform the program that it is performing something improper and should be closed, but it still able to interpret and ignore as above;
• SIGKILL is a final warning, the system will kill the program soon, so the program will interpret and try it best