[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A snapshot
Re: A snapshot
Tue, 26 May 2020 00:14:38 -0300
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
On 16/05/2020 23:27, Greg Wooledge wrote:
On Sat, May 16, 2020 at 09:10:07AM -0700, address@hidden wrote:
I would like to create a file -- call it "snapshot" -- that will record things
like the current command history and the value of all shell and env variables.
And, then, at a later time, possibly from a different terminal and invocation
of bash, access the file, so that to the extent practicable, it will be as
though I continued the bash session at the time of snapshot's creation.
Well... there are several things you'll need to save in a machine-readable
format. The challenge is thinking of everything.
The 'declare -p' command gets you machine-readable copies of all shell
and environment variables, but not functions. The 'declare' commands
gets you variables and functions, but is missing the distinction between
shell and environment variables. I'd probably go with 'declare -p' for
the variables, and then pick up the functions separately.
So, then 'declare -pf' for functions.
'alias' for aliases.
'shopt -p' for shell options.
I'll let you figure out how to get shell history. Maybe setting HISTFILE
to a temporary file, and keeping that separate from the other settings?
History is just a mess, and is not one of the things I've spent a lot of
time trying to wrap my head around.
Maybe 'stty -a' to save the terminal state? But I doubt you'd want to
restore the terminal in a nonstandard state anyway.
Of course, you will lose all running child processes, but I'm assuming
you've already come to terms with that.
The cases Greg mentioned seem like the only practical and common cases.
On Linux, if you had a file descriptor redirection you wanted to
recreate upon returning, such as:
you could look at /dev/fd/ for file descriptor numbers and then, using
sudo, find your shell in /proc via $$ and readlink in the fd directory
to find out where those descriptors pointed to, e.g.:
$ sudo readlink /proc/$$/fd/3
[sudo] password for maroloccio:
If you needed open modes to be recreated too, you'd have to do more
As Greg said, you would not have child processes, so file descriptor
redirection to processes, rather than files, would not work unless you
restarted the children, e.g.:
exec 4> >(grep bar)
would only report a "pipe:[n]" kernel object via readlink.
You could lsof to see which process is attached to that pipe and from
there `ps -o args $pid' to find out more, but recreation would be too
brittle due to lost state.
I am assuming you don't need anything core dumped and resurrected.