From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19230 invoked by alias); 17 Jun 2018 14:15:00 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 43036 Received: (qmail 4542 invoked by uid 1010); 17 Jun 2018 14:15:00 -0000 X-Qmail-Scanner-Diagnostics: from mail-wr0-f178.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.128.178):SA:0(-1.9/5.0):. Processed in 1.406707 secs); 17 Jun 2018 14:15:00 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_PASS,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: stephane.chazelas@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=PSSenu+4baokZU6dBzYV8i0dsp8mBK2UzWintB5lbaQ=; b=ETcXhKQ974jVPmX/Gj0wPB21tcGVQBFbVbPn6suDZUvHYHw2Dy0Clmg5xOPisvJj1o RrrPqigFMiyF3qu3AMcSt3b4w2Qnk6xnbCjD7X+RxqSR5SGF4zxVsCEyxcgm5qmHLxrM WdszJITnsgmJcobiyoUqR/21qYQh0SNLLth83IiEYMnsbT2aZZCIWuliQamS3f6dxDYW zF34e6IoSZBs8ynGVDaI0y9W/QVw4HMmUroyPI+BcoBunk/snDdAqP1kn0GPXrl0fa8Z vbrkA7hlxZhYBpKkHRE56LXtTPWSUA8HQlzVVh5IrWETvKAu7sIJcjUaJxcOY8v3+4nT nFVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=PSSenu+4baokZU6dBzYV8i0dsp8mBK2UzWintB5lbaQ=; b=IJlCvI3gwmVwkREfXgiBQlTZPn5ZJNCP6vFugqWSF9wr7mACPgvMLG1hEP4KAAPNmd LSHSh4ke5ehBnIycpgeQDndzYLnaGNV/+Byyp+SS+3Qz4bGQd6yUBr0IIChmY4cxcxkX WArJO3KcNQq6YKZuViaRMvi0H+UfcKMU/1UrPVWOyL7BfadOgleY51zLM1B2faHdBKZX +aaJfmyhOe6Ng6ao/7AJC6yqA2sW5I4QuED7+ELgZvy+kfkr7j1BoT1KX5wh2KkNCv5s Q9+FqLFYA3eVSzKJcz++yqH5CQ+Pfff5LIO3fT9WaqRRWgTpHsb9x4LVDhVtlF2PkSAU IRtQ== X-Gm-Message-State: APt69E0gEqajAir4k+k42nMWR4UmFyaOGazxor1dtw2Om92OiA4u/pyO JJu6VrhDDSTh6vjt+kTzodICfg== X-Google-Smtp-Source: ADUXVKJbvhn8ddzppzak8ktAV6m7E4M57Be06JY7ZPjN0TpzZ9uT+m7yyNXdoKP+gnqVMNSSR/RFUQ== X-Received: by 2002:adf:9f0f:: with SMTP id l15-v6mr7564514wrf.206.1529244895005; Sun, 17 Jun 2018 07:14:55 -0700 (PDT) Date: Sun, 17 Jun 2018 15:14:52 +0100 From: Stephane Chazelas To: Zsh hackers list Subject: Re: $userdirs empty in non-interactive shells Message-ID: <20180617141452.GA27755@chaz.gmail.com> Mail-Followup-To: Zsh hackers list References: <20171207112950.GA8258@chaz.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171207112950.GA8258@chaz.gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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 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?