On 03/25/2013 11:39 AM, Michael Prokop wrote:
- Csillag Tamas [Mon Mar 25, 2013 at 11:31:28AM +0100]:
On Mon, Mar 25, 2013 at 11:23:57AM +0100, Michael Prokop wrote:
On the other hand it is grml where I learned and got used to zsh and this was one of its great features. :)
+1
Maybe the grml distribution and users fetching grml's zsh config from grml.org/zsh has a different use case (I am not sure) let me explain: On a server there can be more root users operating in parallel on a grml live system there is usually one and typing in one shell then the capability to see that on the other's history is a great thing.
Yeah, but people use grml-zshrc also outside of Grml, even on different operating systems. So we don't have to care just about the Grml live mode use case but also about the more generic one. :)
I try to explain a bit what I meant above: Maybe it can make sense to enable this feature on a grml live system and disable otherwise.
Oh, right - that's another option. But I'm afraid that people would be even more confused about the inconsistency between the different environments.
Yeah. Two different defaults would be confusing.
That said, I also love that share_history feature! I am not sure how you guys work but I usually remember my last command (regardless which terminal I currently use). It often happens that I get interrupted, switch away from (or even close) the terminal and when trying to return find myself in a different terminal where I have no access to my last command....
Or the other way around: I always "expected" to find my last command across all terminals (long before I found grml default zsh share_history feature). But as that did not happen I often found myself issuing the wrong "last" command.
So the same potential "harm" (issuing the wrong "last" command) could also arise without this setting enabled.
I am sure that there a few people who are annoyed by shared_history but I am not sure if these people form a majority.
Thinking loud here: * what about putting a note at the end of the boot process which informs the user about that fact (if you really think that feature is that dangerous)?
* what about adding an option to grml-quickconfig to quickly disable this feature? Hmm, but when thinking about it: the shells on the other consoles are alreay up and running and when invoking grml-quickconfig this might be too late. Is there some kind of SIGHUP to tell (all running) zsh to reload its config?
* do NOT make different settings for grml live-cd and the grml-config: people who are able to apply grml-config are surely able to adapt their needs in .zsh.local
And if anybody cares: my vote goes to keep share_history!
JM2C && Regards, - Darsha