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
On 2013-03-25 10:13, Csillag Tamas wrote:
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.
This is not a problem as long as every "root user" constantly uses only sudo <command> and doesn't start a root shell ;)
Moritz
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.
Teilnehmer (5)
-
Csillag Tamas -
Frank Terbeck -
Michael Prokop -
Moritz Augsburger -
Richard Hartmann