Re: what does 'interactive' mean?

[Roman Neuhauser <neuhauser@sigpipe.cz>]

# p.w.stephenson@ntlworld.com / 2021-08-10 13:12:02 +0100:
> > On 10 August 2021 at 03:58 Roman Neuhauser <neuhauser@sigpipe.cz> wrote:
> > the description of INTERACTIVE in zshoptions(1) contains
> > *no mention of its effects*!
> > 
> >   INTERACTIVE (-i, ksh: -i)
> >     This is an interactive shell.  This option is set upon
> >     initialisation if the standard input is a tty and commands are
> >     being read from standard input.  (See the discussion of
> >     SHIN_STDIN.) This heuristic may be overridden by specifying a
> >     state for this option on the command line.  The value of this
> >     option can only be changed via flags supplied at invocation of
> >     the shell.  It cannot be changed once zsh is running.
> 
> As you say, the documentation is confusing.  What it's trying to say,
> but not making a good job of, is that basically the conditions
> here (tty on STDIN with commands coming from it, which cause the
> INTERACTIVE option to be set) define an interactive shell

you're on the right track here.  one thing i tried to convey was
that the manual overloads the meaning of "interactive shell"
(the colloquial use in the blurb vs. the should-be-precise technical
one basically everywhere else), and that "interactive shell" is too
entrenched as an informal coin to be useful in a technical reference,
that ship has sailed.

with that in mind, i don't think the proposed definition is useful,
or rather, the conditions should be called something other than
"interactive shell" because that is usually understood to include
some kind of online editing facility a la ZLE.  you could strip
zsh down so much its interactive mode would behave like '>>(zsh)'
and it would still fit the definition you offered here.
nobody would accept that as an "interactive login shell".

i think we already have a name for that set of conditions, it's
called "the INTERACTIVE option is set"!

> The shell tests the option internally in a great number of places
> to see if it's appropriate to output prompts, use the line editor,
> etc. etc.  Mostly this is mentioned in the manual, but only
> with something like "if the shell is interactive..."
> This becomes more useful if you know it's testing the
> option when that happens, so somewhere we need a sentence along
> the lines of "where the shell needs to decide if it is
> interactive at run time, it tests the state of the INTERACTIVE shell
> option.  See XXXX for information on this".

i disagree, this is an unnecessary indirection.  i propose

  s/if the shell is interactive/if the INTERACTIVE option is set/g

it's longer by a negligible margin and needs no further cross-reference.

aaand then there's the smaller fish i mentioned, like the text about
the ZLE option being misleading at the very least.  i'll get back to
you later about that.

while i love back-seat driving this is not meant that way.
i'd like to have a patch for this ready by the weekend and then
continue with other parts of the manual that in my opinion don't work
as well as they should and could.  there'll be no ambushes though,
you can always expect a rant first so we can discuss the issue and
see where we meet.

-- 
roman