I have by accident overwritten a very complex bash script, where I tried to implement scoping and threading in a tidy way.

Now the same script is still running but the file is no more, question is: Is it possible to scan through the ram and find the sting representation of the file itself ?

Another problem is: I can't find the /dev/mem or /dev/kmem file, already tried to grep it for contents.

To the environment: It's a debian/sid machine (vps) hostet on vpsfx.com

root@heisenberg:~# ls -a /dev
.        kmsg   ptyp2  ptyp9  random  tty1   tty5   ttyp2  ttyp9  urandom
..       log    ptyp3  ptypa  shm     tty10  tty6   ttyp3  ttypa  xconsole
.udev    null   ptyp4  ptypb  stderr  tty11  tty7   ttyp4  ttypb  zero
char     ptmx   ptyp5  ptypc  stdin   tty12  tty8   ttyp5  ttypc
console  pts    ptyp6  ptypd  stdout  tty2   tty9   ttyp6  ttypd
fd       ptyp0  ptyp7  ptype  tty     tty3   ttyp0  ttyp7  ttype
full     ptyp1  ptyp8  ptypf  tty0    tty4   ttyp1  ttyp8  ttypf

3 Answers 3


Have a look at /proc/$PID/fd. There you should have all the file descriptors openned by the process, including the script itself. Just cat $FD > /tmp/yourscript.sh should be enough to recover it.

  • 1
    I upvoted this answer despite the fact that it does not in fact answer the question that the OP asked. The OP asked how to recover the script from RAM, not from the filesystem. This answer uses the files system, relying on the fact that the script file is not finally unlinked until the final reference count reaches zero. Dec 26, 2013 at 6:53
  • 1
    The proc filesystem resides in RAM only and almose everybody has it mounted. Dec 27, 2013 at 11:32
  • 2
    The /proc fs does not reside in RAM. In fact, it does not reside anywhere. See unix.stackexchange.com/questions/74713/…. Although you can get the fd from /proc, cating the fd reads the file from fs, not RAM. True, you deleted the file, reducing the inode ref count, and no one else can see it now, but it is not actually deleted from the fs until the process running the script closes it. See stackoverflow.com/questions/2028874/…. Dec 27, 2013 at 12:18
  • Yes, you are right. The file itself is read from the disk filesystem. /proc exists in RAM, it's not like a ramdisk, but the information is in RAM. With the exception of /proc/$PID/fd and may be other. Anyway, @Thomas Nordquist wants to recover the file, and this is thse easy way. Dec 27, 2013 at 14:01
  • Worked for me, after a few trys I found the correct file descriptor finally i can close the process and continue Jan 9, 2014 at 15:44

Assuming that the OP really meant from RAM and not any possible way, and assuming that the process in which the script was executed has zero core file limit (which is usually the default setting, cat /proc/PID/limits), then you need to attach to the process and either set the core limit to a large enough value to include the process image and the use the ABRT signal to generate the core file, or use a tool such as gdb that can attach to a process and generate a core image of the process from RAM.

  1. Install gdb

In some shell with same ownership as the running script or root ownership:

  1. Do ps ax to find the process id (PID)
  2. gdb -p PID

Note that this will stop the process execution from continuing but not remove it from the process table.

  1. In gdb, issue the command generate-core-file

gdb should repond with something like Saved corefile core.15113, assuming that PID is 15113.

  1. In gdb, issue the command detach

Your script will continue (resume) running.

  1. In gdb, issue the command quit
  2. In shell, run strings core.15113 > my_script.sh

Open the my_script.sh in some editor. Your script text should be towards the end of the file before the environment section. Use the editor to scrape off the sections before and after the script.

Test this solution on another script before you use it on your prize script.  YMMV.

The sequence looks like this:

yba@tavas:~$ gdb -p 15113
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
Attaching to process 15113
Reading symbols from /bin/bash...(no debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libtinfo.so.5
Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libdl.so.2
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00007feaf4b4c7be in waitpid () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) generate-core-file
Saved corefile core.15113
(gdb) detach
Detaching from program: /bin/bash, process 15113
(gdb) quit
  • This solution works too, but here is some digging involved, thank for your help Jan 9, 2014 at 15:47
  • This is the solution that worked for me! I had overwritten the original file, and hoped it would still be in memory. The open fd (other answer) pointed to the updated file. That saved me!
    – Antoine
    Oct 8, 2019 at 18:02

dd the harddisk partition in overlapping chunks and grep binary for parts of the script. if you are lucky, write out those chunks to temporary directory in ram for greeping in it to save your harddisk or ssd's write cycles. no, it's not a 'from ram' solution. be aware of the fact that when reading disk byte by byte scripts might be in utf-8 (or similar) charset format, so the grep parameters might have to be adapted as well.

You must log in to answer this question.

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