Indeed! No idea what went through my brain when I wrote that :-)

Could you just use `gdb --pid 53165 /proc/53165/exe`?

If that works, is there any reason why gdb shouldn't automatically use the /proc/PID/exe?

Probably because /proc is very Linux-specific, and gdb is not.

I wonder, too... It could pick it up automatically.

Probably - will try it out next week and adjust my GitHub script if it works.

I recently did exactly the same, it's those times when everything with similar functionality depending on what context you are in blurs together because you should probably be outside, taking a walk, or staring at a tree.

However, reaching for one way of doing things when the justification for the other way of doing things is because you've seen them done that way more, is not really good justification. So maybe that blurry brain is a good brain sometimes, in retrospect.

:-)

Hey, working code is the only justification you need :)

And cp would have also saved permissions (the executable bit). Not that GDB would have an issue without it, as the OP showed it can look for symbols inside an ELF regardless of the inode bits.

I would have tried running 'strings'on the process's memory instead of gdb. Ugly, but likely would have worked with some manual intervention.

As to 'cp' vs 'cat': neither is a builtin, so they both are risky. What if you also accidentally did a rm -rf / on that system?

Mac OS X doesn't have a /proc filesystem, so I cannot test it, but from reading the man page

   read -N 1000000000 /proc/53165/exe $bash

should read all of bash into $bash, if it isn't ridiculously large, and

   echo -nE $bash > myBash

should then complete the copy.

Why are cp and cat "risky"?

It's just that in some emergency situations, where for example someone deleted a lot of files on the disk, you might not have /bin/cat or /bin/cp anymore.

I don't see how that ("rm -rf /") is relevant... The OP feared for a reboot that would make him recode his command line.

Ah, fair enough. Good point :)

    read -N 1000000000 /proc/53165/exe $bash

That shouldn't work, due to NUL bytes.