nocorrect documentation and behavior

nocorrect documentation and behavior

[Vincent Lefevre]

With zsh 5.9, consider:

cventin% setopt CORRECT_ALL
cventin% zsha && zshb && nocorrect zshc && zshd
zsh: correct 'zsha' to 'zsh' [nyae]? n
zsh: correct 'zshb' to 'zsh' [nyae]? n
zsh: command not found: zsha

while without "nocorrect", the 4 commands are proposed for correction.

The following lines are handled in the same way:

  zsha ; zshb ; nocorrect zshc ; zshd
  zsha ; zshb ; echo $(nocorrect zshc) ; zshd

"nocorrect" is documented under "PRECOMMAND MODIFIERS". So it is
surprising that it can affect more than the corresponding command.

Is this the expected behavior?

Well, at least this is useful to be able to use "nocorrect" on
the "for" words:

  nocorrect : ; for i in word1 word2 ; do echo $i ; done

Given the context "PRECOMMAND MODIFIERS", the documentation is not
explicit:

    nocorrect
        Spelling correction is not done on any of the words. This
        must appear before any other precommand modifier, as it is
        interpreted immediately, before any parsing is done. It has
        no effect in non-interactive shells.

If this is the expected behavior, I suppose that the documentation
should be something like

  Spelling correction is not done on any of the subsequent words
  of the full command line. [...]

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: nocorrect documentation and behavior

[Bart Schaefer]

On Wed, Mar 13, 2024 at 9:17 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> "nocorrect" is documented under "PRECOMMAND MODIFIERS". So it is
> surprising that it can affect more than the corresponding command.

It's documented there because there was no better place to put it, I
vaguely recall.

> Is this the expected behavior?

It's the implemented behavior, at least.  This is an effect of it
being handled with a flag in the global parser state, which does not
reset at subshell or command boundaries.  This is hinted at by "with
the exception of nocorrect which is a reserved word ... interpreted
immediately, before any parsing".  Conversely, as I think was
discussed not that long ago, spelling correction is applied during
parsing as soon as each full word is seen, just like alias expansion.

>   Spelling correction is not done on any of the subsequent words
>   of the full command line. [...]

It also says "A simple command may be preceded ..." which is equally
inaccurate in this case, but there are a lot of bits of the doc that
colloquially assume that one interactive command line is the same as
one "simple command".

diff --git a/Doc/Zsh/grammar.yo b/Doc/Zsh/grammar.yo
index 915b93bc0..b80f9750c 100644
--- a/Doc/Zsh/grammar.yo
+++ b/Doc/Zsh/grammar.yo
@@ -100,14 +100,15 @@ More generally, a list can be seen as a set of
any shell commands
 whatsoever, including the complex commands below; this is implied wherever
 the word `list' appears in later descriptions.  For example, the commands
 in a shell function form a special sort of list.
+
 texinode(Precommand Modifiers)(Complex Commands)(Simple Commands &
Pipelines)(Shell Grammar)
 sect(Precommand Modifiers)
 cindex(precommand modifiers)
 cindex(modifiers, precommand)
-A simple command may be preceded by a em(precommand modifier),
-which will alter how the command is interpreted.  These modifiers are
-shell builtin commands with the exception of tt(nocorrect) which is
-a reserved word.
+With the exception of tt(nocorrect), which is a reserved word that
+affects further parsing when it is found in command position, each
+of the following builtin commands is a em(precommand modifier) which
+may precede a simple command to alter how that command is interpreted.

 startitem()
 findex(-)

Re: nocorrect documentation and behavior

[Vincent Lefevre]

On 2024-03-13 20:46:40 -0700, Bart Schaefer wrote:
> On Wed, Mar 13, 2024 at 9:17 AM Vincent Lefevre <vincent@vinc17.net> wrote:
> >   Spelling correction is not done on any of the subsequent words
> >   of the full command line. [...]
> 
> It also says "A simple command may be preceded ..." which is equally
> inaccurate in this case, but there are a lot of bits of the doc that
> colloquially assume that one interactive command line is the same as
> one "simple command".

No, this is really before a "simple command". For intance,
"nocorrect" is not valid before "for", "if", "!" or "{":

cventin% nocorrect for i in a b ; do echo $i ; done
zsh: parse error near `for'

Or is this a bug? (I do not see a reason to forbid it this case,
and IMHO, "nocorrect" should be allowed as the first word of a
complex command, the semantics being: just ignore "nocorrect",
i.e. it is only used to enable spelling correction.)

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)