I do something similar -- I show the duration of the command in a human readable format, but only if the command too more than 60 seconds; useful to get an idea of how long compilations (etc) take
One of my most useful changes is a script that garbage-collects my history file: deduplication, removal of sensitive + trivial commands. In combination with a FZF based history search that's shared between all shells, I effectively have a super-quick database of every command without any noise. See https://github.com/naggie/dotfiles/blob/master/scripts/clean... -- added via bash/zsh hooks.
> I show the duration of the command in a human readable format, but only if the command too more than 60 seconds
There is also a similar builtin feature [1] of ZSH. For example, you can put this in your .zshrc:
REPORTTIME=10
It instructs ZSH to report the time elapsed since the command was invoked (if it is above this threshold, 10 seconds in this case).
However, it just takes the CPU time into account. When using something like `sleep`, it won't trigger. There is a plugin [2] that covers this use case aswell.
why would you write an own script to sanitize your history manually? that sounds crazy, you can disallow duplicates and blacklist specific commands using normal shell configuration...
Because HISTCONTROL=ignoredups only deduplicates sequential commands, and having my own script allows specification of the blacklist in a non-redundant way between zsh and bash.
In addition, I can do it in such a way that the most recent invocation is deleted last. I can also use regexes.
I'm sure most know this but if anyone thinks this is a way of doing forensics, keep in mind it can be easily skipped over by doing a non-standard logout, like "kill -9 $$" or if a remote ssh connection gets cut for whatever reason. The command history for a session won't get written until logout by default. A workaround such as forcing each entry to be written to a log file will have to be done to have better assurance of true history.
Excellent point. Seeing when a command in the history list was run is very useful.
My preference is just for a date in the history, rather than date and time. I find that when I'm searching history, date is usually granular enough for me, so I can omit the time and save a little bit of screen real estate.
Have you tried zsh with histdb? It's been an absolute gamechanger. Having a complete, precise, and effectively infinite history is like a second brain.
I know not everyone is on the zsh train, but it might be able to be ported to bash (it's just pre-hooks and some sqlite)
I've had the following in my ~/.bash_profile for quite some time. I leave it here in the hopes it help someone.
## History configuration, see HISTORY in bash(1)
## builtin fc, aka fix command, for history manipulation
## fc [-e ename] [-lnr] [first] [last]
## -e or invoke editor ename; defaults to $FCEDIT
## -l or list commands
## -n or suppress entry numbers
## -r or reverse command order
## first, last selects a range of entries by numeric index
##
## fc -s [pat=rep] [cmd]
## -s or substitute all occurences of pat with rep
#
# - h() is short for history
# - r() is short for replay
# - always append to the history, don't overwrite
# - save multi-line commands in a single entry
# - insist on vim everywhere
# - don't record commands with a leading space or duplicates
# - constrain the size of the history file
# - ignore common things
# - constrain the number of history entries
# - set up nicer timestamps
alias h="history"
alias r="fc -s"
shopt -s histappend
shopt -s cmdhist
export FCEDIT=$EDITOR
export HISTCONTROL=ignoreboth
export HISTFILE=$HOME/.bash_history
export HISTFILESIZE=1048576
export HISTIGNORE='ls:ls -l:ls -latr:ps -ef:fc:h:history:clear:exit'
export HISTSIZE=8192
export HISTTIMEFORMAT='[%F %T] '
In our research group (with shared NFS), we log the history per directory (i.e. the histfile is $PWD/.history.$USER), and we also log the date/time. This has been extremely helpful. Not only checking your own history, but also being able to see others history. E.g. imagine going through some directories of some former colleague who is gone now. Otherwise it would often be impossible to really understand how sth was created, or ended up that way, etc. I mean, properly documenting everything is of course nice, but even if that is done consistently, it will still miss some details. And in practice, it never is done consistently.
I wonder why this is not more standard. Most shells write a single global histfile to $HOME.
The Bash solution probably could also be simplified by using this script, which takes care of filtering logic and adding it to the history file, in your preferred format.
You can do this easily with zsh’s standard features. I love having years of my command history! It's all combined across sessions and instantly searchable with the standard ^R.
These are most of the settings in ZSH I use to enable all that.
HISTSIZE=10000000
SAVEHIST=10000000
setopt EXTENDED_HISTORY # logs the start and elapsed time
setopt INC_APPEND_HISTORY
setopt SHARE_HISTORY
setopt HIST_IGNORE_DUPS
setopt HIST_IGNORE_ALL_DUPS
setopt HIST_FIND_NO_DUPS
Thank you, this was so timely. My zsh terminals have been saving my command history but, for reasons I didn't know, were not displaying them. I'm much pleased to have that sorted out.
Xonsh lets you log history to a sqlite database. It’s a nifty feature for analysing what you’re doing in your shell and AFAIK it keeps the start/stop/elapsed time too.
What’s nice about iterm2’s approach is it shows it for every line of output not just commands, but even before I started using that I had a timestamp on the right hand side of my fish prompt so I can track the progress of my work. Don’t use any thing like this in bash, but there are definitely times when I remote into a system where having them would be handy.
I have a much shorter snippet in .profile for bash:
if $INTERACTIVE; then
# http://superuser.com/a/175802
# show date when command was executed
preexec() {
[ -n "$COMP_LINE" ] && return # do nothing if completing
[ "$BASH_COMMAND" = "$PROMPT_COMMAND" ] && return # don't cause a preexec for $PROMPT_COMMAND
echo -ne "\033[$(( COLUMNS-15 ))C$(date +'%m%d-%H:%M:%S')\r"
}
trap 'preexec' DEBUG
fi
The `echo -ne ...` is what prints the date (month+day+time, year is assumed obvious) close to the right margin (COLUMNS-15), then prints `\r` to get back to left margin. This has pros (less space taken) and cons (shows up in copy&paste), you can surely edit the format to your liking if you prefer.
I'll have to check how the OP's PS0 compares with that however, maybe it can make my snippet even simpler? edit: Ah, IIUC, PS0 seems bash 4.4+, for better or worse: https://github.com/rcaloras/bash-preexec/issues/28
And I like storing the time the prompt was printed so that I can keep track of how long a command took. When I care to keep track of when a command started, I just hit enter once or twice to get a “fresh” timestamp, then I have both an accurate start time and an accurate stop time. This is very handy if you run long jobs in a tmux session, for example.
If I rewrote the prompt each time I ran a command, I’d lose that record. (I suppose I could do the same trick in reverse and if I care to know how long a command will take, I could run it and hit enter a few times to queue up an empty command to create the same timestamp effect after the fact).
It's executed just before the PS1 prompt is printed.
A nice idea I've seen is to use PROMPT_COMMAND to print the time a command finished (and maybe an indication of its exit status) in low-contrast text at the far right of the terminal. Then that info is there if you want to look for it, but it's not distracting.
Then you could have the best of both worlds, and it would all happen without the need to remember to create fresh prompts.
I think you could do the same thing but put the real time in place of --:--. Then when the command is run, overwrite the time with the current time. You'd only be able to see the time the most recent command took with precision, but that's usually what matters.
Sort of related, I like to put this snippet in my PROMPT_COMMAND variable:
PROMPT_COMMAND='echo "$(date "+%Y-%m-%d.%H:%M:%S") $(pwd) $(HISTTIMEFORMAT= history 1)" >> ~/.logs/bash/bash-history-$(date "+%Y-%m-%d").log'
I forget where I learned this. What it does is write the bash history to a log file, with the date/time, directory of the command, and the command. Occasionally it has helped me find where a file is that I was working on :)
I switched over to zsh a few months back and picked up something like this method: https://gist.github.com/zulhfreelancer/9c410cad5efa9c5f7c74c.... This is nice to see for bash and I definitely agree on the usefulness notes, it’s been a nice improvement / helped me not get confused a few times
Isn't that printing the time the prompt was printed (the time the previous command finished)?
This is printing the time you pressed Enter (the time the command started), which is harder and less common, since that's not when the prompt is printed.
The "mortalscumbag" theme from oh-my-zsh show current path above the prompt line which is exactly what you want. Can't live without it! I enable it on every system I use.
Thanks for sharing this guide. For those (like me) who are lazy and want to delegate the hard work and maintenance to folks smarter than me, starship is a cross-shell prompt that will print duration of commands. https://starship.rs/
All these neat tricks being discussed, and meanwhile I just `date; my_cmd; date` for jobs I want start/end times of. The fact that I can do it with no configuration on all the umpteen boxes I log into is the reason I stick with it.
Whenever I want a command dated like in your suggestion, instead of pressing Enter to execute the command, I press the key-sequence ".,d" and the command gets wrapped in 'date' calls.
All of those are only useful if you thought of it beforehand. Which is rare in my experience, often I want to know the time exactly when something unexpected happened.
If you also write the starttime to a file you can read it and produce the elapsed time. Then one step further is to have a program read all your ongoing times alongside parsing the active processes, and give you running progress of your current shells.
Mine works but is hacky, it would be nice to have a more neatly packaged solution.
I think that hacks are the name of the game when it comes to this sort of thing with Bash, so don't feel bad about that. My solution is very much a hack too.
I wrap every interactive shell in ‘script’ effectively recording it.
I’ve been tempted to add time logging by something similar to
PS1=“$(date)\r$PS1”
Because I don’t really care about the execution time of current commands but might care historically.
If I'm understanding it correctly, what this sort of approach will give you is a timestamp in the prompt which is generated when the prompt is printed to the terminal and then doesn't change.
The thing is that the prompt might sit there for minutes or hours before you use it to run a command, so that timestamp doesn't reliably serve as an accurate record of when a command was run.
That's the problem which my approach addresses by updating the timestamp when a command is run.
Sure, forensics accuracy isn’t something I hugely care about, i do have some shell sessions that span days so having an indication can be handy.
If I did, It’s also possible to get amount of time a command required to complete. Based on that execution time in conjunction with the timestamp of the next print of PS1 it would be easy to deduce the time when a line was actually executed, rather than when typing of the line began, but at that point I’d probably just record my screen to track any harder to determine behaviours.
And I discovered that I like to always see in the prompt the return value of the last command executed, if it is not 0. nd that I don't need the name of the machine and the user name in the prompt on my main computer.
See https://github.com/naggie/dotfiles/blob/master/home/.functio...
One of my most useful changes is a script that garbage-collects my history file: deduplication, removal of sensitive + trivial commands. In combination with a FZF based history search that's shared between all shells, I effectively have a super-quick database of every command without any noise. See https://github.com/naggie/dotfiles/blob/master/scripts/clean... -- added via bash/zsh hooks.