What am I running inside my bash? (2014)

Even easier to run pstrings:

https://github.com/andikleen/pstrings

I used it a few times to handle similar situations, like recovering text from a web browser.

Can you also add the working directory in which each command was run?

Does bash have an option to write out the history before running the command? Usually history is written in PROMPT_COMMAND, which runs after the command completes.

I do something similar, I gave up on trying to get the bash history to work properly and so just have this:

    echo "$HOSTNAME $$ $(date "+%Y-%m-%dT%H:%M:%S%z") $*" >> ~/.fullhistory

It's attached to the preexec hook of https://github.com/rcaloras/bash-preexec, so is run before every command. This means that everything goes into one easily-greppable file, but is still separable by PID/host machine - since my work has me walking around a large facility, often I'll remember where I was when I did something but not exactly when, so can narrow down by machine.

This is why every major project I work on has a ".archive/oneshot/" folder for anything complicated that was used to quickly put out a fire. Not only will I inevitably need to remember months later what happened, but I'll also want to reuse certain bits later.

That ".archive" folder itself is then a personal git repo. Sometimes you just have to put that fire out or get that question answered and its not worth a "proper" solution, but keeping a history is worth it.

Resist the urge to keep it as part of the main project's repo at all costs. It's far too easy for it to be come standardized (e.g. by other devs, perhaps) and breath life into them they should never have.

Exactly, I just wrote a blog post about how I do that, basically with shell scripts in the repo with lots of small functions. They basically form an annotated log of what I did, so I never have to remember long commands.

I can't remember long commands so I always write them down.

Examples of using a JSON API, using a C++ tool uftrace, and hacking on Kernighan's awk:

Shell Scripts Are Executable Documentation http://www.oilshell.org/blog/2021/01/shell-doc.html

Admittely there are a lot of people who don't seem to like reading shell scripts as docs. But you don't really have to read the code -- you just read the function names.

I also added doc comments to Oil, like this:

    deploy() {
       ### doc comment
       cp foo bar
    }

which you can access with the 'pp' builtin. So eventually those strings could be exposed to autocomplete, etc.

http://www.oilshell.org/blog/2020/11/more-syntax.html

Maybe it's for portability. The /proc filesystem doesn't exist on every OS supported by gdb.

This won't work if the debug symbols are in a separate file though.

Because ctrl-z will stop the current command, and when you run "fg" it resumes that one process. However, the loop you were in has been abandoned, and it will not continue to execute.

For example, try it with this:

    for N in $(seq 10); do echo $N; sleep 1; echo $N; done

You'll see something like this:

    $ for N in $(seq 10); do echo $N; sleep 1; echo $N; done
    1
    1
    2
    ^Z
    [1]+  Stopped                 sleep 1
    $ fg
    sleep 1
    $

Thank you for your kind words. The funny thing is that I am not a sysadmin - or maybe I am one in spirit :-)

No, because that won't resume the loop.

Unless you are running the command via "sh -c", you can't see any shell builtin commands or Unix pipelines by dumping the process tree. For example, "cat > /dev/null", the redirection is done by the shell and isn't passed to cat's "char **argv", in the process tree you can only see a "cat" running without arguments (and a shell built-in is invisible). It also gives no information about the control flow of your one-liner shell script (e.g. what does the "for loop" do?), nor environmental variables, etc. You can try to reconstruct some information by inspecting its open files, its environ, etc., but it's not practical for any complicated combination of commands).

or ctrl-z for that matter

The script was running in production, doing actual work. Stopping it - when you don't remember a damn thing about it and how it worked - was not an option I wanted to consider at the time.