Re: $userdirs empty in non-interactive shells

[Stephane Chazelas <stephane.chazelas@xxxxxxxxx>]

Any opinion on the question and follow ups below?

I ran into it once again today (when trying to use
${(k)userdirs} as a list of user names).

Original discussion at
https://www.zsh.org/mla/workers/2017/msg01756.html
(worker 42092).

2017-12-07 11:29:50 +0000, Stephane Chazelas:
> $userdirs seems to only work in interactive shells. That seems
> to be due to:
> 
> > mod_export void
> > adduserdir(char *s, char *t, int flags, int always)
> > {
> >     Nameddir nd;
> >     char *eptr;
> >
> >     /* We don't maintain a hash table in non-interactive shells. */
> >     if (!interact)
> >         return;
> 
> Why? It seems to me it would make as much sense to hash it in
> non-interactive shells. It may be useful to be able to flush
> that cache though.
> 
> Note that upon expanding $userdirs in non-interactive shells,
> the code still loops over the pw entries.
> 
> So, if we don't want to change the behaviour, we may still want
> to disable $userdirs altogether in non-interactive shells (and
> update the documentation).


2017-12-08 12:23:45 +0000, Stephane Chazelas:
> 2017-12-07 11:29:50 +0000, Stephane Chazelas:
> [...]
> > >     /* We don't maintain a hash table in non-interactive shells. */
> > >     if (!interact)
> > >         return;
> [...]
> 
> If I remove that code, that breaks one of the tests:
> 
> > --- /tmp/zsh.ztst.2996/ztst.out 2017-12-07 21:31:18.051388484 +0000
> > +++ /tmp/zsh.ztst.2996/ztst.tout        2017-12-07 21:31:18.047388673 +0000
> > @@ -1,4 +1,4 @@
> >  ~/install/cvs/zsh/Test/options.tmp
> > -~/install/cvs/zsh/Test/options.tmp/tmpcd ~/install/cvs/zsh/Test/options.tmp
> > -~/install/cvs/zsh/Test/options.tmp/tmpcd ~/install/cvs/zsh/Test/options.tmp/tmpcd ~/install/cvs/zsh/Test/options.tmp
> > -~/install/cvs/zsh/Test/options.tmp/tmpcd ~/install/cvs/zsh/Test/options.tmp/tmpcd ~/install/cvs/zsh/Test/options.tmp
> > +~cdablevar2 ~/install/cvs/zsh/Test/options.tmp
> > +~cdablevar2 ~cdablevar2 ~/install/cvs/zsh/Test/options.tmp
> > +~cdablevar2 ~cdablevar2 ~/install/cvs/zsh/Test/options.tmp
> > Test ./E01options.ztst failed: output differs from expected as shown above for:
> >   dirs
> >   pushd $mydir/tmpcd
> >   dirs
> >   pushd $mydir/tmpcd
> >   dirs
> >   setopt pushdignoredups
> >   pushd $mydir/tmpcd
> >   dirs
> >   unsetopt pushdignoredups
> >   popd >/dev/null
> >   popd >/dev/null
> > Was testing: PUSHD_IGNOREDUPS option
> > ./E01options.ztst: test failed.
> 
> That's because an earlier test does a cd a:
> 
> cd cdablevar2
> 
> under setopt cdablevars with cdablevar2 containing that same
> tmpcd directory, and so an entry is added in that hash.
> 
> That's one case where an earlier test has side effects on later
> tests.
> 
> While the documentation doesn't mentions that that "hashing" only
> happens in interactve shells, the test code acknowleges it to
> some extent:
> 
> ># Test various shell options.
> ># Interactive options not tested here:
> [...]
> >#    AUTO_NAME_DIRS  (named directory table not maintained)
> 
> That also means:
> 
> $ zsh -fc 'cd ~bin; dirs'
> /bin
> $ zsh -fic 'cd ~bin; dirs'
> ~bin
> 
> BTW, I just realised that named dirs in variables took precedence
> over user home dirs:
> 
> $ zsh -fc 'cd -P -- ~bin && pwd'
> /bin
> $ bin=/tmp zsh -fc 'cd -P -- ~bin && pwd'
> /tmp
> 
> Is that intentional? I can't say I like the  idea. It would need
> to be disabled in "sh" emulation if we wanted to be POSIX
> compliant in that regard (but then there are a few other
> namespace clashes that would need to be addressed like for
> keywords, special variables if we wanted to go all the way
> there).


2017-12-08 19:46:52 +0000, Stephane Chazelas:
> 2017-12-08 12:31:50 +0000, Peter Stephenson:
> > On Fri, 8 Dec 2017 12:23:46 +0000
> > Stephane Chazelas <stephane.chazelas@xxxxxxxxx> wrote:
> > > BTW, I just realised that named dirs in variables took precedence
> > > over user home dirs:
> > > 
> > > $ zsh -fc 'cd -P -- ~bin && pwd'
> > > /bin
> > > $ bin=/tmp zsh -fc 'cd -P -- ~bin && pwd'
> > > /tmp
> > > 
> > > Is that intentional?
> > 
> > Yes, it allows you to override locations associated with users without
> > jumping through lots of hoops.
> [...]
> 
> Ah OK.
> 
> What would be a typical use case?
> 
> Is that the reason why named dirs were introduced in the first place?