Re: zsh built-in commands are removed when passing through a built-in command that spawns commands

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Wed, May 15, 2013 at 10:33 AM, Bart Schaefer
<schaefer@xxxxxxxxxxxxxxxx> wrote:
>
> Well, that indicates that the builtin time is still there.  So
> something else must be going on.

Aha.  I can in fact reproduce it, I was misled by $TIMEFMT.

So ... what's happening is that the shell can't time itself timing
time, if you see what I mean. The trivial case is

% time time true

The built-in time [which is actually a keyword rather than a command,
which is why
  % time (sublist)
works at all] is executed in the current shell and is able to record
the elapsed time for a single "job".  If that job is also executed in
the current shell, the built-in handles that by reading the time stats
for the shell itself.  If that current-shell-job in turn is also the
built-in time, there's no nested set of time stats available ...
either the outer time has to be abandoned [or reported incorrectly] or
the inner one has to be handled differently.

Zsh chooses to solve this during parsing by simply not recognizing the
time keyword inside another time keyword.  You can see this by the
strange parse error in this example:

% time (true)
( true; )  0.00s user 0.00s system 48% cpu 0.001 total
% time time (true)
zsh: missing end of name
time (true)  0.00s user 0.00s system 49% cpu 0.001 total

A possible alternative would be for a nested "time" keyword to force
itself into a subshell.  This wouldn't cost any more processes than
the current approach of falling back to the external time command.
Unfortunately this is not entirely trivial to implement, though
someone who knows the internal wordcode representation better than I
do could probably do it reasonably quickly.

An intermediate approach is to recognize nested time keywords in
explicit subshells, which turns out to be pretty straightforward.  If
that were implemented,

% time ( time true )

would use the keyword in both positions, but

% time time true
% time { time true }

would behave as they do now.  We'd want to implement the subshell
variant anyway in order to avoid an unnecessary fork for the time
keyword inside the subshell, but by itself it'd introduce even more
inconsistency.