Re: PATCH: separate watch/log functionality out into a module

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Fri, Nov 5, 2021 at 5:17 PM Oliver Kiddle <opk@xxxxxxx> wrote:
>
> > Hm.  What would the right behavior be?  Do we need a flag on the
> > autoloaded parameter for whether the value is [not?] allowed to come
> > from the environment?  PM_DONTIMPORT seems potentially relevant.
>
> I'm not sure whether PM_DONTIMPORT really helps at all.

My thought was that the module bootstrap could examine its paramdef
array for PM_DONTIMPORT and either warn about, or skip marking for
autoload, any variable with that flag that is already in the
environment.

> But for a parameter like WATCH, it'd ideally load the module and use the
> imported value. Is it an important feature that $WATCH can come from the
> environment?

I don't have a feel for this.  As you pointed out earlier in the
thread, the prevalence of multi-user environments has diminished.

> On further testing zsh/watch does need to better guard against one of
> them coming from the environment. They can only be tied if both are
> there. The patch below covers this case.

How was this dealt with in the base shell, before you modularized it?
Array values ($watch) can't be imported, so something must have
happened when WATCH alone is an environment value at shell startup.

I would think the ideal behavior would be "as if":

  local W=$WATCH
  unset WATCH
  zmodload zsh/watch
  [[ -n $W ]] && WATCH=$W  # triggers autoload and tie

> Can someone with a Mac confirm something: have they disabled the log
> builtin because it clashed with an external command.

/bin/zsh on Catalina has not disabled the builtin; I don't have a
Monterey install to check.

> A log(1)
> man page does seem to exist

NAME
     log -- Access system wide log messages created by os_log, os_trace and
     other logging systems.

Seems to be borrowed from BSD.