Don Cragun wrote: [heavy snipping]
> > ksh93 itself does not set a default editing mode; it would be a > standards violation to do so. In an interactive shell, in-line editing > will be disabled, unless an in-line editing option is set by one of the > configuration files read when the shell is invoked, or is set > explicitly by the user. > Using the ksh93 tarball provided by the ksh93-integration project, this appears to not be true. Without the provided ksh.kshrc present, it defaults to vi-style editing. This is also the behaviour of a freshly built AST ksh93r. I also take some issue with the statement regarding standards, though I have no particular skill at interpreting them. SuSv3 regarding sh(1): > Command Line Editing > > When sh is being used interactively from a terminal, the current > command and the command history (see fc) can be edited using vi-mode > command line editing. This mode uses commands, described below, > similar to a subset of those described in the vi utility. > Implementations may offer other command line editing modes > corresponding to other editing utilities. > > The command set -o vi shall enable vi-mode editing and place sh > into vi insert mode (see Command Line Editing (vi-mode)). This command > also shall disable any other editing mode that the implementation may > provide. The command set +o vi disables vi-mode editing. > > Certain block-mode terminals may be unable to support shell > command line editing. If a terminal is unable to provide either edit > mode, it need not be possible to set -o vi when using the shell on > this terminal. > > In the following sections, the characters erase, interrupt, kill, > and end-of-file are those set by the stty utility. It then goes onto describe the operation of vi-mode. I don't see anything specifying that the shell should not be in that mode by default beyond the fact that the statements regarding how one would enable it may imply it not being enabled as a default. It's also worth noting that this is purely with reference to sh(1), ksh appears to not be specified in any way by SuSv3. Since it's apparent I must be looking at the wrong standard, could this be updated to state which standard a default mode would violate. If indeed an sh(1) (or ksh(1)) must default to not having line editing as per standards yet unknown, why it is acceptable for this not to be how ksh93(1) would behave under Solaris. While not this case, precisely, are there any statements regarding how this will affect any future work to replace ksh(1) or the XPG.4 sh(1) with ksh93? Either will have a change in behaviour with their default mode being set to 'gmacs', and in the case of the XPG.4 sh(1), it's been somewhat stated above that this would in fact be a violation of standards (though the above also would mean the current XPG4 sh(1) is already in violation, by defaulting to vi-mode). -- Rich
