[Grml] RC: disable zshrc's share_history feature by default?

hi,

Post by Michael Prokop
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?

Post by Michael Prokop
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

--
CSILLAG Tamas (cstamas) - http://cstamas.hu/

Michael Prokop

2013-03-25 10:23:57 UTC

[Removing grml-devel from Cc]

Post by Michael Prokop
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...)

What will happen then?
The histories will still get merged, but only at the end of the session?

Yeah, they will be "merged".

Post by Csillag Tamas
If one or the other overwrites the history file I would vote against it.

No, you won't lose any history information.

Post by Csillag Tamas
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
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-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://ml.grml.org/pipermail/grml/attachments/20130325/29f5a9d7/attachment.pgp>

Csillag Tamas

2013-03-25 10:31:28 UTC

On Mon, Mar 25, 2013 at 11:23:57AM +0100, Michael Prokop wrote:
...

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 (cstamas) - http://cstamas.hu/

Michael Prokop

2013-03-25 10:39:45 UTC

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. :)

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-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://ml.grml.org/pipermail/grml/attachments/20130325/f4adc2fb/attachment.pgp>

Darshaka Pathirana

2013-03-28 16:56:11 UTC

Post by Csillag Tamas
On the other hand it is grml where I learned and got used to zsh and this was
one of its great features. :)

Post by Csillag Tamas
Maybe the grml distribution and users fetching grml's zsh config from grml.org/zsh
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. :)

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

Frank Terbeck

2013-03-28 19:31:46 UTC

Darshaka Pathirana wrote:
[...]

Post by Darshaka Pathirana
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.

[...]

Post by Darshaka Pathirana
* 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.

Post by Darshaka Pathirana
* 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.

Post by Darshaka Pathirana
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

Gregor Perner

2013-03-28 19:46:02 UTC

Post by Frank Terbeck
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

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.grml.org/pipermail/grml/attachments/20130328/e0f2d013/attachment.html>

Darshaka Pathirana

2013-03-31 14:43:12 UTC

Post by Frank Terbeck
[...]

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.

Post by Frank Terbeck
[...]

Post by Darshaka Pathirana
* 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..)

Post by Frank Terbeck

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..)

Post by Frank Terbeck

Post by Darshaka Pathirana
And if anybody cares: my vote goes to keep share_history!

Again, this isn't a vote.

Ok. See below.

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

Frank Terbeck

2013-03-25 12:43:45 UTC

[..disable share_history..]

Post by Michael Prokop
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.

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

Frank Terbeck

2013-03-25 11:21:40 UTC

[...]

Post by Michael Prokop
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

Richard Hartmann

2013-03-25 12:47:33 UTC