This article erroneously conflates terminal and shell and then proceeds to talk about only one shell, the Bourne Again shell. (It is Windows NT where command h

This article erroneously conflates terminal and shell and then proceeds to talk about only one shell, the Bourne Again shell. (It is Windows NT where command history is a function of the console object rather than of the command interpreter.) Nor do "all software engineers use history". Some use the standard "fc" command. 93 Korn shell users can use "fc" or "hist" as well. The article's abuse of "legacy" to mean "undesirable" is almost a side-issue. * http://pubs.opengroup.org/onlinepubs/9699919799/utilities/fc.html http://pubs.opengroup.org/onlinepubs/9699919799/utilities/fc... * http://jdebp.uk./FGA/legacy-is-not-a-pejorative.html http://jdebp.uk./FGA/legacy-is-not-a-pejorative.html Of course, the idea that Unix, which was multi-user from 1st Edition onwards, "could only have one shell open at a time" is nonsense. And I can attest from personal experience that people cottoned on to having two terminals side-by-side before screen came to comp.sources.unix. Interestingly, the manual page for the TENEX C shell points out that shell variables controlling history should be set in .tcshrc rather than in .login so that they affect the sourcing of $histfile which is done before the sourcing of .login. What it does not also point out is that this results in always setting them in all interactive shells without need to import them from the associated environment variables. If always set in this way, it is largely meaningless to export the shell variables into environment variables visible to other programs in child processes, as the headlined article has one do. The same can be done with the Z shell, setting the history control shell variables in .zshrc or the $ENV file, the 93 Korn shell and PD Korn shell, setting the history control shell variables in the $ENV file, and the Watanabe shell, setting the history control shell variables in .yashrc or the $ENV file.