Re: print builtin preceded by parameter assignment

[Vincent Lefevre <vincent@vinc17.net>]

On 2019-04-11 14:42:08 -0700, Bart Schaefer wrote:
> The trick is to mark TZ exported before you try to use it as a prefix
> assignment.
> 
> % echo $+TZ
> 0
> % export TZ
> % echo $+TZ
> 1
> % print -P "%D{%c %Z}"
> Thu Apr 11 14:27:39 2019 PDT
> % TZ=UTC print -P "%D{%c %Z}"
> Thu Apr 11 21:27:58 2019 UTC

This is even more confusing: the "export" status should not have
an effect in a variable assignment before a command (in particular,
a builtin).

Actually there is another inconsistency without the "export":

zira% echo $+TZ $+LC_ALL
0 0
zira% print -P "%D{%c %Z}"
Wed Apr 24 14:19:39 2019 CEST
zira% TZ=UTC0 LC_ALL=fr_FR.utf8 print -P "%D{%c %Z}"
mer. 24 avril 2019 14:19:50 CEST CEST

Following the (IMHO, invalid) justification for TZ not being taken
into account with a builtin, the LC_ALL assignment should have also
been ignored. But this is not the case.

Ditto for CDPATH:

zira% printenv CDPATH
zira% cd home
cd: no such file or directory: home
zira% CDPATH=/ cd home
/home

> Here's a semi-related oddity -- once the timezone is changed, it does
> not change back, even though the TZ variable is not set:
> 
> % echo $TZ
> 
> % date
> Thu Apr 11 21:28:18 UTC 2019
> 
> Oops, the timezone remains UTC even though the variable is no longer
> set.  This has to be a side-effect of calling localtime() in
> promptexpand().

This is even worse.

[...]
> So the "bug" if there is one is that variables that aren't marked for
> export don't magically become exported when used before a builtin in a
> prefix assignment.

There are several bugs (perhaps all related):

1. The fact that TZ remains exported with a value different
   from $TZ.

2. The fact that TZ and other variables (at least LC_ALL and CDPATH)
   are handled differently with a variable assignment before a
   builtin, when not exported.

3. The fact that for TZ, the "export" status has an effect on
   the value taken into account in a builtin.

IMHO, for (2), the best solution would be to fix (2) to follow
the behavior of LC_ALL/CDPATH/... (which would correspond to my
original request). And this would make (3) pointless.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)