Shell History and the Value of Text Only Environments |
August 4th, 2010 |
| logging, programming, shell, tech |
I log all my shell history at work. The code [1] to do this is pretty simple: [2]
This is in principle just as possible with a gui environment. Graphical programs could be written to log their actions in a way that lets one reconstruct past actions. The problem with this is that is is opt-in. Because on unix you generally use collections of small tools, logging invocations and arguments is sufficient, which means individual programs don't need to know anything about logging at all. With larger graphical tools, you need to know what actions the user took inside the program. Because the interface is less constrained, the only things you could possibly log from the outside would be keyboard input, mouse input, and the graphical output. These are not searchable. So we have to log from the inside, where the program knows what the clicks and key presses mean. This makes logging the responsibility of every single application's developers, which means that it almost never happens.
[1] Thanks to blake for pointing out that I can do
[2] I also think that this should not be necessary. Logging since 2009-07-02, with extensive use, I have run 83170 individual commands which, stored uncompressed, take up 48M. Storage is cheap enough nowadays that saving history should be on by default for interactive sessions, with an option to turn it off for low storage environments.
.bashrc:I also do almost all my work in a command prompt. Taken together, I have a very good record of what I've worked on. If someone is wondering how I did something, this will let me either find the bash command that made the change, or at least tell me what program I ran with what arguments to make it. Combined with version control for my programs, I can reconstruct almost anything if I'm willing to dig a bit.promptFunc() {
# right before prompting for the next command, save the previous
# command in a file.
echo "$(date +%Y-%m-%d--%H-%M-%S) $(hostname) $PWD $(history 1)" >> ~/.full_history
}
PROMPT_COMMAND=promptFunc
This is in principle just as possible with a gui environment. Graphical programs could be written to log their actions in a way that lets one reconstruct past actions. The problem with this is that is is opt-in. Because on unix you generally use collections of small tools, logging invocations and arguments is sufficient, which means individual programs don't need to know anything about logging at all. With larger graphical tools, you need to know what actions the user took inside the program. Because the interface is less constrained, the only things you could possibly log from the outside would be keyboard input, mouse input, and the graphical output. These are not searchable. So we have to log from the inside, where the program knows what the clicks and key presses mean. This makes logging the responsibility of every single application's developers, which means that it almost never happens.
[1] Thanks to blake for pointing out that I can do
$(history 1) in place of $(history | tail -n 1).
[2] I also think that this should not be necessary. Logging since 2009-07-02, with extensive use, I have run 83170 individual commands which, stored uncompressed, take up 48M. Storage is cheap enough nowadays that saving history should be on by default for interactive sessions, with an option to turn it off for low storage environments.
Comment via: facebook