$userdirs empty in non-interactive shells

$userdirs empty in non-interactive shells

[Stephane Chazelas]

Hi,

$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).

-- 
Stephane

Re: $userdirs empty in non-interactive shells

[Stephane Chazelas]

2017-12-07 11:29:50 +0000, Stephane Chazelas:
[...]
> >     /* We don't maintain a hash table in non-interactive shells. */
[...]

Note another consequence:

~ completion works in

zsh -fic 'vared -c var'

but not in

zsh -fc 'vared -c var'

(as in, when "vared" is used in scripts).

-- 
Stephane

Re: $userdirs empty in non-interactive shells

[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).

-- 
Stephane

Re: $userdirs empty in non-interactive shells

[Peter Stephenson]

On Fri, 8 Dec 2017 12:23:46 +0000
Stephane Chazelas <stephane.chazelas@gmail.com> 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.

Strictly you probably need to be able to turn off variable hashing as
directories entirely in POSIX mode.

pws

Re: $userdirs empty in non-interactive shells

[Stephane Chazelas]

2017-12-08 12:31:50 +0000, Peter Stephenson:
> On Fri, 8 Dec 2017 12:23:46 +0000
> Stephane Chazelas <stephane.chazelas@gmail.com> 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?

-- 
Stephane

Re: $userdirs empty in non-interactive shells

[Stephane Chazelas]

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@gmail.com> 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?