zsh-users
 help / color / mirror / code / Atom feed
From: Vincent Lefevre <vincent@vinc17.net>
To: zsh-users@zsh.org
Subject: Re: print builtin preceded by parameter assignment
Date: Wed, 10 Apr 2019 16:11:13 +0200	[thread overview]
Message-ID: <20190410141113.GD15169@cventin.lip.ens-lyon.fr> (raw)
In-Reply-To: <1554902053.6252.6.camel@samsung.com>

On 2019-04-10 14:14:13 +0100, Peter Stephenson wrote:
> On Wed, 2019-04-10 at 14:55 +0200, Vincent Lefevre wrote:
> > It seems that the print builtin doesn't take into account a change
> > of the environment with a parameter assignment. For instance:
> > 
> > cventin% zsh -c 'TZ=UTC print -P "%D{%c}"'
> > 2019-04-10T14:53:50 CEST
> > cventin% zsh -c 'export TZ=UTC; print -P "%D{%c}"'
> > 2019-04-10T12:53:53 UTC
> > 
> > Is there any (undocumented?) reason or is this a bug?
> 
> It's certainly the case that such assignments only go into the
> environment, and aren't processed within the shell.
> 
> I *think* this is standard behaviour:
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/
> 
> 2.9.1 specifies that unless the command is a special builtin utility,
> the "current execution environment" is not affected by the assignment;
> the value is simply exported.  I'd certainly assume the time zone seen
> by % escapes is part of the current execution environment.  Neither
> print (obvioussy) nor echo are special builtin utilities.
> 
> As this is a standard, I may simply have misread it.

This is not how I interpret it (see below). But anyway, non-special
builtins are not in the scope of POSIX, unless you regard these
builtins as functions (in the sense, with a similar behavior), in
which case, the current behavior seems to be a bug.

POSIX distinguish 4 cases with a command name, and it depends on
which case you assume to apply to the "print" builtin.

1. If the command name is not a special built-in utility or function,
the variable assignments shall be exported for the execution environment
of the command [...]

In this case, the variable assignments should affect the output.

2. If the command name is a standard utility implemented as a function,
the effect of variable assignments shall be as if the utility was not
implemented as a function.

The "print" builtin is not a standard utility, so that this does not
apply (otherwise this is similar enough to cases 1 and 4).

3. If the command name is a special built-in utility, variable
assignments shall affect the current execution environment.

If you want to regard the "print" builtin as a special built-in
utility, the variable assignments should affect its output.

4. If the command name is a function that is not a standard utility
implemented as a function, variable assignments shall affect the
current execution environment during the execution of the function.

Again, in this case, if you regard the "print" builtin as similar
to some (opaque) function, the variable assignments should affect
its output.

As a summary, it is expected that in *any* case, variable assignments
affect the output.

When POSIX talks about the current execution environment is what
occurs around the execution of the command/function/... (e.g.
expansions and code run after the execution of the command).

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

  reply	other threads:[~2019-04-10 14:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20190410125753epcas1p4052249a86c562165e1fe2a485d70e70b@epcas1p4.samsung.com>
2019-04-10 12:55 ` Vincent Lefevre
2019-04-10 13:14   ` Peter Stephenson
2019-04-10 14:11     ` Vincent Lefevre [this message]
2019-04-10 14:39       ` Peter Stephenson
2019-04-10 17:25         ` Bart Schaefer
2019-04-11 10:40           ` Vincent Lefevre
2019-04-11 20:58             ` Bart Schaefer
2019-04-11 21:42               ` Bart Schaefer
2019-04-24 12:31                 ` Vincent Lefevre
2019-04-24 16:00                   ` Bart Schaefer
2019-04-25 19:47                     ` Bart Schaefer
2019-04-11 10:45         ` Vincent Lefevre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190410141113.GD15169@cventin.lip.ens-lyon.fr \
    --to=vincent@vinc17.net \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).