Woah, how do I enable this? From what I can tell this information is not being stored in $HISTFILE:
...
: 1613659860:0;sleep 1
: 1613659863:0;sleep 3
: 1613659871:0;exec zsh
: 1613659880:0;vim $HISTFILEFrom the Zsh man page:
EXTENDED_HISTORY <C> Save each command's beginning timestamp (in seconds since the epoch) and the duration (in seconds) to the history file. The format of this prefixed data is: `: <beginning time>:<elapsed seconds>;<command>'.
(EDIT: My best guess explanation is some competing/conflicting setopt, but the Zsh mailing list could almost surely help you. Also, `history -fD` may show the correct answer even if the saved file has all 0s.)
[1] https://unix.stackexchange.com/questions/396809/zsh-share-hi...
It makes sense. It's preferring to add to history immediately so that it's available to other shells without having to wait for the command to finish.
From the manpage:
> INC_APPEND_HISTORY_TIME This option is a variant of INC_APPEND_HISTORY in which, where possible, the history entry is written out to the file after the command is finished, so that the time taken by the command is recorded correctly in the history file in EXTENDED_HISTORY for‐ mat. This means that the history entry will not be available immediately from other instances of the shell that are using the same history file. This option is only useful if INC_APPEND_HISTORY and SHARE_HISTORY are turned off. The three options should be considered mutually exclusive.
It looks like either share_history or inc_append_history break recording duration in a fundamental way. The TL;DR is that the history line is written out before the command in question completes. I guess the thinking is that inc/shared history with some very long running command is not as useful if you wait until it ends and you have elapsed time data to append that line. I feel like that might be a personal issue - like if you almost only ever run commands 1-90 seconds then you are fine with the delay.
Anyway, this also explains why it is available from the `history -fD` command but not in the file.
$ function c;{echo $[$*]}
$ c 1234./56
22.035714285714285
$ a=33;c a / 3
11TL;DR - Yuck = namespace squishing in this application only, but then again one man's "collapse of namespaces being yucky" is another's "yay, I do not have to remember 3..4 namespaces!".
EDIT: for what it's worth, I never intended my 9..11 items to be "in order of importance or persuasiveness". Mostly in order of personally driving me batty when I use Bash and just meant to actually be things Zsh could do that (present)Bash could not, to my knowledge due to @deadbunny's complaint. I do try to keep a side Bash config that is as close as possible to my Zsh config, because it's not always worth my time to compile/install Zsh on a system. But when I do that and start using Bash, I notice all these missing things. { That's why I would genuinely appreciate anyone who knows how to replicate them in Bash saying how. I'm not just "daring the Bash apologists to a challenge" or whatever. :-) }
10) =() expansion. It's like <() which both bash and zsh have, but instead of substituting with the path to a pipe, it substitutes with the path to a temporary regular file. Sometimes pipes don't suffice. For example, I can do `viewnior =(maim -s)` to select a region of the screen and see it in an image viewer immediately. `viewnior <(maim -s)` fails because viewnior can't display an image from a pipe.
11) short syntax for control structures. For example, you can do `for x in $(xs); foo $x` without bothering with `do` and `done`.
12) variable expansion in brace expansion. In bash, `x=5; echo {3..$x}` outputs `{3..5}`. zsh outputs `3 4 5`.
13) Command can be just redirection without any executable. `<<< foo` is equivalent to `cat <<< foo`, `> foo.txt` is equivalent to `cat > foo.txt`.
14) Able to convert numbers between any bases. To convert base-5 10 to base-4: `<<< $(( [#4] 5#10 ))` outputs `4#11` which means 11 in base-4.
15) Named directories. I have my project files organized under deep directories like ~/work-for/.../.../.../foo/, and have configured all those as named directories to be able to access them as `~foo`, for instance. Different from using simple variables for this, named directories are compacted when presented by the shell. So in my prompt, I see my current directory is e.g. `~foo/bar` instead of the whole thing from the home dir. Named directories come in 2 forms, static and dynamic. Static named dirs are when you set them up in a hash of name => directory. Dynamic named dirs are when you define a function that expands arbitrary names to paths and compacts arbitrary paths to names.
16) `=foo` expands to the full path of executable foo. So you can, e.g. see the source of `pass` with `less =pass`.
17) Variable expansion syntax, glob qualifiers, and history modifiers can be combined/nested quite nicely. For example, this outputs all the commands available from $PATH: `echo ${~${path/%/\/*(*N:t)}}`. `${~foo}` is to enable glob expansion on the result of foo. `${foo/%/bar}` substitutes the end of the result of foo to "bar" (i.e. it appends it); when foo is an array, it does it for each element. In `/*(*N:t)`, we're adding the slash and star to the paths from `$path`, then the parentheses are glob qualifiers. `*` inside means only match the executables, `N` is to activate NULL_GLOB for the match so that we don't get errors for globs that didn't match anything, `:t` is a history mod used for globs that returns just the "tail" of the result, i.e. the basename. IIRC, bash can't even nest multiple parameter expansions; you need to save each step separately.
18) Suffix aliases can be used to define how to open arbitrary files. `./foo.mp4` opens it up in with `mpv`, because I have `alias -s mp4=mpv`.
19) Global aliases are useful for expanding stuff anywhere. For example, I have `alias -g %LD='~/downloads/*(oc[1])'` so that `%LD` expands to the latest download as part of any argument to a command.
20) Globbing flags. There are various flags for globbing, that enable e.g. backreferences in globs, allow n-number of errors while matching (approximate matching), etc. The only one I've really used though is `i` which enables a glob to be case-insensitive. So `(#i)*.pdf` matches `foo.pdf` as well as `bar.PDF`.
21) Multios. You can use multiple files in individual redirections. For example, `foo > bar | baz` is equivalent to `foo | tee bar | baz`. That accepts globbing and brace expansion too: `foo > *.{c,h}` is the same as `foo | tee *.{c,h}`. Also works for reading: `foo < *.txt` is practically the same as `cat *.txt | foo`. I must admit that I haven't really used this, though.
Also, I tend to use a global alias "/n" for "/dev/null". I know I could just use $n with n=/dev/null, but I enjoy having it look like a path in / that never actually exists.