Item — HN Reader

Noting that you didn't solicit advice, but…

* Exporting shell variables such as HISTFILE isn't necessary, and can be unsafe. For example, if you decide to pop open unconfigured bash from within a zsh session it would intermingle its history on write.

* There is a smart keyboard subsystem that neatly manages terminal differences¹, making it much nicer compared to inserting {system,term}-specific escapes in to your config.

Hoping this comes across in the helpful spirit it was intended, not as nitpicky unwanted code review.

¹ https://zsh.sourceforge.io/Doc/Release/User-Contributions.ht...

1 comments

Thanks, I'm always open for advice.

* For shell history I don't think I've encountered that issue yet. For example if I have zsh loaded and run `bash` and then within that bash session run `whoami` and exit bash, my `history` within zsh doesn't include the whoami command, only `bash`. Is there another workflow that would produce intermingled history?

* Ah, this is likely in reference to the home / end / insert / etc. key binds I added? I think I came up with those from following a 2007 blog post[0] which I found here[1]. Do you know what the nicer versions would be for those specific keys? The docs are coming up empty with specific examples and most Google results return the escaped references.

[0]: https://blog.andrewbeacock.com/2007/08/how-to-get-home-end-k...

[1]: https://stackoverflow.com/questions/8638012/fix-key-settings...

For the first; Unless your bash config overrides the environment variable you've set it will use $HISTFILE from the calling shell, which is why "HISTFILE=<location>" without the export fixes it. You can test it with:

    export HISTFILE=trash
    bash --norc
    echo hello
    exit
    cat trash

It isn't just intermingling either, bash may truncate the file depending on how it is configured too. You can see this by performing the same procedure as above but starting with 1000 lines in the trash file, bash will truncate the file to 500 lines by default on exit. It shouldn't happen in your case as you're also exporting HISTSIZE, but it can if you have a lot of multiline history events as bash treats them differently to zsh.

The point wasn't just about HISTFILE really though, very few of the shells own configuration variables are useful in child processes. (LC_* and PATH being the obvious exceptions that spring to mind.)

---

For the second; The doc I linked to above shows how to use zkbd to handle terminal differences in a clean way. Run the wizard, and then you can use the $key array as in $key[Home]. The neat thing to do with zkbd is have the wizard run on startup when it can't find its definitions file, that way you'll get correct behaviour whenever you play with a new terminal type.

Another option is to use the terminfo database¹ directly, if you trust it to be correct for your terminals. "zmodload terminfo", and then the database is available through the $terminfo array as in $terminfo[khome] or using the echoti function².

¹ https://zsh.sourceforge.io/Doc/Release/Zsh-Modules.html#The-...

² terminfo(5) contains the mappings, but they're often far less readable than the $key array. $terminfo[kpp] vs $key[PageUp], for example.

Thanks, I'll test them out and apply the changes. It sounds like all 4 of the history env vars don't need to be exported.

What felt like an initial thirty second throwaway comment yesterday has turned in to a pile of replies that feel like a poorly conceived Ted talk now, forgive me for that.

The dividing line between variables that should be prefixed by export are ones that are generally useful to child processes and ones that are not.

For example, $PATH is useful and should be exported. You probably want scripts you start to have access to all the things you have installed, not just the locations of the default search path:

    PATH= =zsh -fc 'print -l $path'

$HISTFILE/$PROMPT/etc control current shell behaviour and are unlikely to be of any use to child processes executed by the shell, and do not need to be exported. Remembering, of course, that they'll be set by any new interactive shells anyway as they too will read their startup files when launched.

Oftentimes it doesn't make much difference. However, some such as $CDPATH can cause non-obvious bugs when they're exported, and some such as $HISTFILE can cause data corruption or even loss when the planets align against you.

Hah no problem.

There was just enough time after your talk for 1 more question from the audience:

For my zshrc that you poked around in, is this issue related specifically to HISTFILE or all of the history related env vars?

All four of the $HIST* parameters are perfectly functional without export.