8

If I run:

$ ls *
foo bar buzz
$ history | tail -1
ls *

You can see that in my shell history it remembers that I ran ls * rather than ls foo bar buzz. Ideally, I'd like to record both in separate histories. When I wonder, "what the heck happened to file foo?", it would be nice to be able to have a way to go back and figure out that I did rm * in the wrong directory by searching through my history and finding 'foo'.

I'm interested in solutions for both zsh and bash.

Improve this question
1

1 Answer 1

Reset to default
5

I don't think any shell does anything beyond whitespace munging when storing commands into the history. What * expanded to is not recorded, and there doesn't seem to be an option to record it.

Note that it would not be possible to record in full generality anyway. For example, if you run a='foo* bar*'; rm $a (rm $=~a in zsh), the shell is unlikely to detect the wildcard match syntactically. And there's no option to log all glob expansions.

You could cobble something together with preexec (or the bash equivalent). Untested first go (for zsh):

history_wildcards=()
precmd () {
  emulate -LR zsh
  local n tmp
  history -1 | read n tmp
  history_wildcards[$(($n+1))]=$=~1
}

This fills the history_wildcards array to a string with the glob expansion of each word in the command line. Word splitting is performed in the naive way, so something like echo ' /**/* ' will expand /**/* (i.e. traverse your disk). Don't expect anything useful from cd subdir && echo * or anything so mind-bogglingly nontrivial.

If you plan beforehand, you can make zsh expand the wildcards before you submit the command. In the default configuration, just press Tab when your cursor is on the glob. If you've configured completion differently, try ^X * (expand-word).

Improve this answer
5
  • If nobody adds another answer in a few days I'll mark as accepted, I think you're right. It would be interesting to try to make a shell where the history was more suitable for assisting with audits.
    – Joseph Garvin
    May 1, 2011 at 20:12
  • 1
    @Joseph: The shell is the wrong level for auditability, there are too many ways to escape it (such as launching a file manager). There are all kinds of auditing packages, up to fully logged filesystems, but they aren't wildly deployed.
    – Gilles 'SO- stop being evil'
    May 1, 2011 at 20:16
  • @Giles: When I said make a shell I meant create a whole new one from scratch, where you'd have to build in limitations to prevent that sort of thing. You're definitely right that writing a fool proof config is probably impossible.
    – Joseph Garvin
    May 5, 2011 at 22:54
  • @Joseph: Writing a new shell from scratch wouldn't help you because the shell is inherently the wrong LEVEL to be working at. It is just a process run by the kernel. It happens to be an interactive one that accepts commands from user input and instructions the kernel to launch those as other processes, but it is just a process. There are other process on systems and no shell you could ever write would have the ability to audit what those process actually do. The kind of auditing you ask about would have to be done at the kernel or file system level.
    – Caleb
    May 7, 2011 at 12:46
  • @Caleb: I'm assuming such a shell would only be part of a larger system where what the user can do is fairly controlled by other means already. I didn't mean to imply a custom shell by itself would accomplish anything security wise ;p
    – Joseph Garvin
    May 7, 2011 at 19:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.