This story was discussed a few days ago¹, including with some fond personal recollections from users. There was a link posted to Vint Cerf's story collection² too. Also, a link to the source of Mills' fuzzball OS was posted³.
FWIW, that is also the default behaviour of zsh's standard completion subsystem for kill. You can try it yourself: "zsh -f" to get a shell without reading a fancy config, start compinit, "kill <Tab>".
You can even disable verbose mode via zstyle, should you be the type of person that likes a simple pid list like bash's completion project provides. To me this level of customization is the main feature zsh provides, but not everyone incessantly turns every knob they see.
* 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.
* 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.
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:
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².
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.
As we're in a zsh story, I'll point out it comes with a clever file renaming interface out of the box¹. It allows full access to all the advanced glob operators zsh provides too².
Like practically everything zsh, it can be configured. The select-word-style zle widget¹ ships with zsh, and has a bash compatible setting(among others). The interface is super powerful, and given that you can change it in individual zle widgets you can make it context aware if you wish too.
Well, you don't have to use the two pane mode if you don't want anyway. You can switch to single pane mode, use the second pane for file info, use the second pane as a directory tree in the manner of a "regular" single pane explorer, etc.
To perform your "copy, navigate, paste" task while in mc's single pane mode you could either:
a) tag files, pop open the second pane temporarily, navigate and copy.
b) tag files, swap the panes in the background, navigate and copy.
c) tag files, use the bindings to copy them to the inbuilt command line, navigate and copy. Using the "quick cd" dialog would probably speed this up.
d) any of the above with inverted target and source movement.
e) probably a thousand other more sensible ways than the three or cheat-y six I just thought of ;)
zsh has a comprehensive hook system available for these types of tasks¹(zshaddhistory in this case). It gives you more options to control how/when the history is preserved, and allows you to be more selective in when it should be written.
Possibly worth noting for others that you'd want to think this through if you're using any of the history eliding options(hist_ignore_space² for example), as one history file may contain secrets when you're really expecting that it wouldn't.
There is also a better interface to work with hook functions through the add-zsh-hook mechanism³, which allows stacking multiple hook functions together.
Depends on the archive type and how the vfs/extfs code was implemented for it¹. It also depends on how the archive is treated if it is compressed container, which can be seen by looking at how a .tar and .tar.xz are handled for example. The zip handler is probably the easiest to understand, as it doesn't need to contend with external compression wrappers and is a simple perl script. (In some cases it would probably be nicer if it did extract the entire archive to tmpfs, such as when you independently pull a few files from a massive .deb for example)
Implementing your own extfs scripts to wrap a simple menu around some task can be really useful, far beyond basic archives. I wrote one so that I can shuffle my todo list priorities by moving fake "task files" in to different pseudo-directories.
