Open siteshwar opened 5 years ago
Currently
ksh
usesvi
as default editing mode.
That isn't true. It bases the default editing mode on the value of the VISUAL
env var if set else the EDITOR
env var. And if neither are set then it defaults to neither vi
, emacs
or gmacs
mode being enabled. I do think that in that situation it should enable emacs
mode.
We need to either switch to
emacs
as default editing mode, or find ways to make it easier for new users to discoveremacs
mode.
While I'd prefer to replace the heuristic with a simple default it's probably not worth changing now. But I do think we could improve the documentation. The current wording for the effect of the VISUAL
env var on ksh behavior isn't great. It should state clearly that you can force a particular mode at startup by putting set -o emacs
, etc. in your ~/.kshrc.
Currently
ksh
usesvi
as default editing mode.That isn't true. It bases the default editing mode on the value of the
VISUAL
env var if set else theEDITOR
env var. And if neither are set then it defaults to neithervi
,emacs
orgmacs
mode being enabled. I do think that in that situation it should enableemacs
mode.
Right. I had EDITOR
set to vim
and that's how it picked up the default editing mode. May be we can print a message when ksh
does this.
Maybe we can print a message when
ksh
does this.
I've been tempted to add such a message in similar situations. But it is almost always a bad idea unless you can ensure the message only appears once. Where "appears once" is itself something that is often hard to define. I really don't want to see a message telling me the CLI editing mode is what I already expect every time I start an interactive shell. Even if the message was predicated on the absence of an explicit set -o emacs
(or vi or gmacs) it would still be more annoying than helpful since I presumably am relying on the heuristic that sets the mode based on the VISUAL
or EDITOR
env vars.
Ksh is not a friendly shell. Even fish, whose name is an acronym for friendly interactive shell, doesn't display such a message. It simply defaults to emacs behavior. The user has to explicitly ask for vi behavior.
At $WORK, ksh is still the default login shell on linux servers.
All of my younger colleagues switch to bash as the first action after logging in.
When I explain about 'set -o emacs' they look at me as if I'm talking gibberish. And perhaps I am.
My vote is for making emacs mode the default.
On 26/02/2019 05:35, Kurtis Rader wrote:
Maybe we can print a message when |ksh| does this.
I've been tempted to add such a message in similar situations. But it is almost always a bad idea unless you can ensure the message only appears once. Where "appears once" is itself something that is often hard to define. I really don't want to see a message telling me the CLI editing mode is what I already expect every time I start an interactive shell. Even if the message was predicated on the absence of an explicit |set -o emacs| (or vi or gmacs) it would still be more annoying than helpful since I presumably am relying on the heuristic that sets the mode based on the |VISUAL| or |EDITOR| env vars.
Ksh is not a friendly shell. Even fish, whose name is an acronym for friendly interactive shell, doesn't display such a message. It simply defaults to emacs behavior. The user has to explicitly ask for vi behavior.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/att/ast/issues/1180#issuecomment-467291670, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLHkNciac6JgfK9sHiYLdo7APngquZfks5vRLl6gaJpZM4bOpak.
My vote is for making emacs mode the default.
I'm okay with such a change but it can't be done until we've managed to make a stable release based on the ksh93v- work in progress code. We have made a huge number of changes that might affect the behavior of ksh (e.g., replacing AST vmalloc with system malloc). But we are trying to avoid making any change that explicitly changes user visible behavior until another ksh release based on this code base occurs. When that happens we have some latitude for introducing backward incompatible changes.
I'm okay with such a change but it can't be done until we've managed to make a stable release based on the ksh93v- work in progress code.
When it comes to backward compatibility, my concerns are mostly related to retaining compatibility with existing scripts. I don't think there would be any issues with improving interactive features.
That isn't true. It bases the default editing mode on the value of the VISUAL env var if set else the EDITOR env var.
I am one of the people who use vim
as default editor, but prefer emacs
mode on command line. I am curious whether we should continue to use above approach to set default editing mode.
I've been tempted to add such a message in similar situations. But it is almost always a bad idea unless you can ensure the message only appears once.
For me such a message is fine as long as it describes the action(s) one needs to take to get rid of it.
When it comes to backward compatibility, my concerns are mostly related to retaining compatibility with existing scripts. I don't think there would be any issues with improving interactive features.
I agree. You just need to make it easy for users to get the old behavior back and document it at suitable places (which is the most difficult part).
Maybe we can print a message when ksh does this.
Another problem with doing this is that it could potentially break using rsync
with ssh
if it prints text because someone has it in their .profile
. It should of course only be in their .kshrc
.
My vote is for making emacs mode the default.
One of the differences with bash
, I believe, is that it defaults to emacs
mode even if no mode has been set, in violation of POSIX
apparently. Whereas ksh
, in that case, starts in a mode with no editing capability at all.
All of my younger colleagues switch to bash as the first action after logging in. When I explain about 'set -o emacs' they look at me as if I'm talking gibberish.
That is strange as emacs
mode should have been set by their .kshrc
which is copied from /etc/skel/.kshrc
and which is properly configured in Red Hat and Debian, unless setting $EDITOR
to vim
or vi
somewhere is changing it.
However if their accounts have been setup before ksh
was installed, then they won't have received a copy of the .kshrc
in their home dir, which is a good reason to change the behaviour of ksh
to default to emacs
if no mode has been set, because otherwise users installing ksh
to try it out will get a bad experience as they won't get a copy of the default .kshrc
.
When it comes to backward compatibility, my concerns are mostly related to retaining compatibility with existing scripts. I don't think there would be any issues with improving interactive features.
Okay but using the same reasoning there shouldn't be any objection to replacing the implementation of the mail related env vars in the core code with equivalent ksh script functions that are run when an interactive prompt it about to be displayed. See issue #1163.
Also, whether replacing the current heuristic with a constant default is an improvement is debatable. I do agree the heuristic is fragile. The fact you get no default editing mode if the heuristic fails to match your preferred editor is an argument against it. But the heuristic has been in place for several decades and I can't recall ever hearing from another ksh user before now that this behavior surprised them, let alone "I'm going to stop using ksh" because of that behavior.
Also, as @dannyweldon points out printing a message can cause problems. Even if you ignore the issue that displaying the message every time an interactive ksh shell starts is going to annoy people.
On Thursday, March 7, 2019 8:35:10 AM CET Kurtis Rader wrote:
But the heuristic has been in place for several decades and I can't recall ever hearing from another ksh user before now that this behavior surprised them, let alone "I'm going to stop using ksh" because of that behavior.
I do. When I was studying at the university 15 years ago, ksh was the default
shell on some non-Linux servers. When students (mostly Windows users) were
given the vi-style line editor, which was the default, they got totally lost.
Instead of figuring out how to switch the editor mode, they quickly learned
how to switch to bash, which was also available on those servers.
were given the vi-style line editor, which was the default, they got totally lost
It's only the default if your VISUAL
or EDITOR
env vars imply that is your preferred editor mode. So I don't understand what point you are making. Are you saying that those students were given an environment which would have launched a vi style text editing program if an external editor was required and those students were surprised the ksh CLI provided that behavior? Or are you saying the ksh environment set up for those students had an explicit set -o vi
in the ksh initialization scripts? In which case what does that have to do with this issue? Since that would be a mistake made by the people responsible for setting up student's computing environments.
@hlangeveld Please provide more information about why your coworkers switch to bash after you tell them about set -o emacs
. Why does the default shell environment provided by your company for new employees cause ksh to default to vi editing mode? Presumably it's because that environment defines the EDITOR
or VISUAL
env vars in a manner that looks like a vi style editor is what the user expects. If that is the case isn't the solution to either
a) stop defining those default env vars, or
b) change the default to emacs, or
c) explain to the new employee how to set those env vars in their personal shell dot files or add a set -o emacs
by default.
Please understand I am not a fan of the existing heuristic. But so far I haven't seen a good argument for why it should be changed after being in place for 3+ decades. I am also perplexed by statements like
When I explain about 'set -o emacs' they look at me as if I'm talking gibberish.
Note that bash supports both set -o emacs
and set -o vi
. If your colleagues don't understand something that trivial, but still switch to bash because the ksh CLI editing mode isn't what they expected, I am inclined to suggest they should consider a career that does not involve a computer CLI.
On Thursday, March 7, 2019 10:27:47 AM CET Kurtis Rader wrote:
were given the vi-style line editor, which was the default, they got totally lost It's only the default if your
VISUAL
orEDITOR
env vars imply that is your preferred editor mode.
Could be. I do not have access to those systems any more. In fact, I am not even sure whether they still exist.
So I don't understand what point you are making.
I am saying that bash was using a different default, which was much better accepted by the target consumers.
Are you saying that those students were given an environment which would have launched a vi style text editing program if an external editor was required and those students were surprised the ksh CLI provided that behavior?
Yes, that was very likely the case.
Or are you saying the ksh environment set up for those students had an explicit
set -o vi
in the ksh initialization scripts?
I do not think there was much on-site customisation on those servers.
In which case what does that have to do with this issue? Since that would be a mistake made by the people responsible for setting up student's computing environments.
Could be. You just need to be careful in order not to do a similar mistake with the upstream distribution of ksh.
Currently
ksh
usesvi
as default editing mode. Most of the new users coming frombash
will try to execute commands likeCtrl-L
(to clear screen) and will get an impression that these bindings are not supported at all. We need to either switch toemacs
as default editing mode, or find ways to make it easier for new users to discoveremacs
mode.