RC: disable zshrc's share_history feature by default?
Hi,
Grml's zshrc [http://grml.org/zsh/] uses 'setopt share_history' by default since ages.
This option is responsible for making the history of one Zsh session available to others "kind-of-immediately". So when sending 'echo foobar' in one terminal, then pressing e.g. <return> in another zsh session of the same user then cursor up will show 'echo foobar' on the command line.
While I personally like the feature and somewhat got used to it it's also one of the most discussed settings of grml-zshrc. It has the potential to do harm, especially if you aren't aware of that feature.
This is why I'd like to disable this setting by default (but provide it as commented feature so it's trivial to just enable it on request). Of course you will be able to just customize it via e.g. .zshrc.local, it's really just about the default behaviour.
Any objections against that switch? Happy to hear your {N,}ACKs. :)
regards, -mika-
hi,
On Mon, Mar 25, 2013 at 10:47:40AM +0100, Michael Prokop wrote:
Hi,
Grml's zshrc [http://grml.org/zsh/] uses 'setopt share_history' by default since ages.
This option is responsible for making the history of one Zsh session available to others "kind-of-immediately". So when sending 'echo foobar' in one terminal, then pressing e.g. <return> in another zsh session of the same user then cursor up will show 'echo foobar' on the command line.
While I personally like the feature and somewhat got used to it it's also one of the most discussed settings of grml-zshrc. It has the potential to do harm, especially if you aren't aware of that feature.
What is the potential harm?
This is why I'd like to disable this setting by default (but provide it as commented feature so it's trivial to just enable it on request). Of course you will be able to just customize it via e.g. .zshrc.local, it's really just about the default behaviour.
What will happen then?
The histories will still get merged, but only at the end of the session? If one or the other overwrites the history file I would vote against it.
On the other hand it is grml where I learned and got used to zsh and this was one of its great features. :)
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.
Regards, cstamas
[Removing grml-devel from Cc]
* Csillag Tamas [Mon Mar 25, 2013 at 11:13:33AM +0100]:
On Mon, Mar 25, 2013 at 10:47:40AM +0100, Michael Prokop wrote:
Grml's zshrc [http://grml.org/zsh/] uses 'setopt share_history' by default since ages.
This option is responsible for making the history of one Zsh session available to others "kind-of-immediately". So when sending 'echo foobar' in one terminal, then pressing e.g. <return> in another zsh session of the same user then cursor up will show 'echo foobar' on the command line.
While I personally like the feature and somewhat got used to it it's also one of the most discussed settings of grml-zshrc. It has the potential to do harm, especially if you aren't aware of that feature.
What is the potential harm?
If you have e.g. 'rm -rf $whatever' in one of your sessions and then <enter><cursor-up> in another session then you might have 'rm -rf $whatever' in your command line while expecting something different. (Yeah, don't execute without reading what's there, but if you're used to something different and fast working...)
This is why I'd like to disable this setting by default (but provide it as commented feature so it's trivial to just enable it on request). Of course you will be able to just customize it via e.g. .zshrc.local, it's really just about the default behaviour.
What will happen then? The histories will still get merged, but only at the end of the session?
Yeah, they will be "merged".
If one or the other overwrites the history file I would vote against it.
No, you won't lose any history information.
On the other hand it is grml where I learned and got used to zsh and this was one of its great features. :)
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. :)
Thanks for your feedback, regards, -mika-
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. :)
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.
Regards, cstamas
* 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. :)
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.
regards, -mika-
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
Darshaka Pathirana wrote: [...]
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....
I usually do different things in different shells. Hence that feature is absolutely the worst for *me*. But this is not about personal preference.
[...]
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)?
This is not going to help.
- 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
I would rather change the default on the live-medium than use a grml-quickconfig setting. Not because it's better but because the quickconfig approach is not easily possible.
And if anybody cares: my vote goes to keep share_history!
Again, this isn't a vote.
If you could make a convincing argument, that share_history indeed does not violate the principle of least surprise, then that could make a difference. But I doubt you can. Because zsh is pretty much the only shell that implements this. And even with zsh, it's *not* the default setting.
After realising, that it does in fact violate said principle, you can absolutely still like the feature. There is nothing wrong with liking it. But enabling it, should be an conscious decision by *you* the user. It should not be the default.
Regards, Frank
Frank Terbeck ft@grml.org schrieb:
If you could make a convincing argument, that share_history indeed does not violate the principle of least surprise, then that could make a difference. But I doubt you can. Because zsh is pretty much the only shell that implements this. And even with zsh, it's *not* the default setting.
After realising, that it does in fact violate said principle, you can absolutely still like the feature. There is nothing wrong with liking it. But enabling it, should be an conscious decision by *you* the user. It should not be the default.
This.
I agree with the principle of least surprise on the live-cd. But because I really like this feature in my environment I would appreciate it if it was easy to activate...
best regards gregor
On 03/28/2013 08:31 PM, Frank Terbeck wrote:
Darshaka Pathirana wrote: [...]
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....
I usually do different things in different shells. Hence that feature is absolutely the worst for *me*. But this is not about personal preference.
Ack.
[...]
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)?
This is not going to help.
Maybe not. But it would remind /me/ (and maybe others) to change to the prefered setting (whatever the default setting is going to be..)
- 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
I would rather change the default on the live-medium than use a grml-quickconfig setting. Not because it's better but because the quickconfig approach is not easily possible.
Same as above. Whatever the setting is going to be, it would be definitly nice if *grml* would provide a quick way to change the default. Maybe something like: grml-zsh-share-history enable|disable (Again, just thinking loud here..)
And if anybody cares: my vote goes to keep share_history!
Again, this isn't a vote.
Ok. See below.
If you could make a convincing argument, that share_history indeed does not violate the principle of least surprise, then that could make a difference. But I doubt you can. Because zsh is pretty much the only shell that implements this. And even with zsh, it's *not* the default setting.
As I tried to say before. I think the "principle of least surprise" heavily depends on what the user expects (even if all the "other" shells do not have this default setting). We are talking about grml users here (at least thats what I thought) and maybe they expect something *grml* provides (since ages - since when actually?). But obvioulsy you are not that kind of (grml) user. So there might be no definite truth here.
As I did not see this discussion about convincing anyone what the "best" setting is or should be and as you noted that this is not a vote I do not think I can help anymore in finding the answer what the default setting should be... It then all leads to the grml-zsh-config maintainer and what /he/ (or she) thinks whats the least "harmful" for the grml user...
I surely will be able to live with whatever decision will be made.
All the best!
Regards, - Darsha
Csillag Tamas wrote:
On Mon, Mar 25, 2013 at 10:47:40AM +0100, Michael Prokop wrote:
[..disable share_history..]
While I personally like the feature and somewhat got used to it it's also one of the most discussed settings of grml-zshrc. It has the potential to do harm, especially if you aren't aware of that feature.
What is the potential harm?
The harm, for example, could be that you're using history to recall a series of commands in one shell and did a destructive one in another terminal. Then you continue with your series of commands and destroy something.
I know, I know. This cannot happen, because people _always_ double check before they hit enter. Oh wait! Why was I so grateful, that I a backup a couple of times in the past? :-)
But more seriously: The feature does violate the principle of least surprise. It's okay that zsh _has_ this option. It is also okay that you _like_ it. But enabling it should be a conscious decision by you, the user. It should not be the default.
This is why I'd like to disable this setting by default (but provide it as commented feature so it's trivial to just enable it on request). Of course you will be able to just customize it via e.g. .zshrc.local, it's really just about the default behaviour.
What will happen then?
Well, the feature will be disabled unless we get hordes of users that scream at us. Actually, screaming doesn't help. A convincing argument might.
In case we change _our_ default (again, this default DIFFERS from zsh's default settings), then you can get the old behaviour be adding the following to your `~/.zshrc.local':
setopt share_history
Then for you, nothing changes.
Regards, Frank
Michael Prokop wrote:
Grml's zshrc [http://grml.org/zsh/] uses 'setopt share_history' by default since ages.
This option is responsible for making the history of one Zsh session available to others "kind-of-immediately". So when sending 'echo foobar' in one terminal, then pressing e.g. <return> in another zsh session of the same user then cursor up will show 'echo foobar' on the command line.
While I personally like the feature and somewhat got used to it it's also one of the most discussed settings of grml-zshrc. It has the potential to do harm, especially if you aren't aware of that feature.
[...]
Any objections against that switch? Happy to hear your {N,}ACKs. :)
ACK for exactly the reason you gave: It violates the principle of least surprise.
Regards, Frank
It's always been the thing I looked least about that zshrc. I lost a few days of debug data on two machines because a script started to write over existing files, years ago.
Least surprise says disable it and keep as optional.
Richard
Sent by mobile; excuse my brevity.
participants (6)
-
Csillag Tamas -
Darshaka Pathirana -
Frank Terbeck -
Gregor Perner -
Michael Prokop -
Richard Hartmann