Hi Klemens,

On 19 Oct 08:49, Klemens Nanni wrote:
> On Wed, Aug 31, 2022 at 05:16:27PM +0200, Uwe Werler wrote:
> > Hi folks,
> > 
> > I'm just wondering why there's a test for an empty line and args to start 
> > the
> > editor for line editing. In bash one can start vi immediately with an empty
> > line by ^v. Might be there's another reason I don't understand for this 
> > test?
> 
> Logically, this should probably be allowed, but reading ksh(1)
> 
>      [n]v        Edit line n using the vi(1) editor; if n is not specified,
>                  the current line is edited.  The actual command executed is
>                  fc -e ${VISUAL:-${EDITOR:-vi}} n.
> 
> this says that editing is implemented via history

...WHEN n is specified. Otherwise it uses the current line?

> 
>      fc [-e editor | -l [-n]] [-r] [first [last]]
>                   Fix command.  first and last select commands from the 
> history.
>                   Commands can be selected by history number or a string 
> specifying
>                   the most recent command starting with that string.  The -l 
> option
>                   lists the command on standard output, and -n inhibits the 
> default
>                   command numbers.  The -r option reverses the order of the 
> list.
>                   Without -l, the selected commands are edited by the editor
>                   specified with the -e option, or if no -e is specified, the
>                   editor specified by the FCEDIT parameter (if this parameter 
> is
>                   not set, /bin/ed is used), and then executed by the shell.
> 
> ^v does not specify a number, so ksh supposedly runs `fc -e vi'?

Yes. And that would edit the current line.

> 
> The `fc' synopsis does not show how to use "a string specifying the most
> recent command starting with that string...

Because it only runs fc with either the line number to edit or simply the
current line?

When running manually 'fc expression' then it jumps to the first match
backwards or with 'fc -r expression' it reverses the list for matches. 

> 
> I guess ^v uses the current line for this string (no idea how), at which
> point it makes sense to not pass the empty string.

I think no, it doesn't search for the command via fc but simply passes the
current line by saving it to history and using that line number as argcnt.
And why it couldn't be even an empty line?

> 
> In vi mode, if you enter only spaces, then ESC then `v' to edit:
> - our ksh will edit the previous line, not current whitespace one
> - ksh93 from ports will print a warning and not do anything

Mmh, the same happens when running the fc command...

I try to interprete the code here:

                case 'v':

Ok, empty line and no linenum given - do nothing.

                        if (es->linelen == 0 && argcnt == 0)
                                return -1;

No linenum given:

                        if (!argcnt) {

Current line is modified (can even be empty by deleting everything) and saved
in history:

                                if (modified) {
                                        es->cbuf[es->linelen] = '\0';
                                        source->line++;
                                        histsave(source->line, es->cbuf, 1);

Imho can't happen because then there must be an empty line before modify - but
we returned already with -1. That can only happen when applied my diff and will 
be empty?

                                } else
                                        argcnt = source->line + 1
                                                - (hlast - hnum);
                        }

                        shf_snprintf(es->cbuf, es->cbufsize,
                            argcnt ? "%s %d" : "%s",
                            "fc -e ${VISUAL:-${EDITOR:-vi}} --",
                            argcnt);
                        es->linelen = strlen(es->cbuf);
                        return 2;

So finally with the diff we would run simply 'fc -e ${VISUAL:-${EDITOR:-vi}} --'
which opens vi with an empty file.  When running 'fc -e vi -- ' (at least
one blank) it will use the last command from history somehow.

> 
> 
> So without looking at the code, I think this check is warranted.
> 

Thanks for your time!

-- 
wq: ~uw

Reply via email to