Re: padding.

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

[@all: the second hunk is of independent interest]

Ray Andrews wrote on Sat, Feb 11, 2017 at 17:54:09 -0800:
> On 11/02/17 11:04 AM, Bart Schaefer wrote:
> >integer -Z 6 vvar=-1
> 
> Perfect!  Amazing what's hiding under the hood.  I always prefer to do as
> much as possible with built in functionality.
> >I don't think you can, except by specifying a field width of 6.  Even
> >printf is going to treat the "-" as part of the field width.
> 
> Yeah, it would be more complicated and more involved to get a neat printout.
> The engineer in me does want the field width to be independent of the sign,
> but it's a trivial matter.

printf is not a reserved word (it isn't part of the syntax), however,
it _is_ builtin to the shell:

    % which printf
    printf: shell built-in command

If printf weren't a builtin, it wouldn't have been able to grow the
«-v variablename» flag.

> BTW, is this kosher:
> 
> 
> $  if [ "$1" = "start" ]; then
>         if [ "$1" = 'null' ] && return
>    fi
>
> (no message)

Reduced example:

% if false; then if true; fi 
% setopt noshortloops 
% if false; then if true; fi 
zsh: parse error near `fi'

I'm guessing the second 'if' is parsed using the SHORT_LOOPS syntax,
with an empty sublist.  I'm not sure whether that's a bug: is the
sublist in the SHORT_LOOPS syntax allowed to be null?

What about the following variant:

    if true; then if exit 42; fi

Should it exit() or report a syntax error about a missing 'fi'?

> and:
>
> $  if [ "$1" = "start" ]; then
>         # if [ "$1" = 'null' ] && return
>    fi
>
> (no message)

That's expected.

In a script or with INTERACTIVE_COMMENTS, the outer if's body is empty.

Interactively and with INTERACTIVE_COMMENTS unset, the outer if's body
invokes the '#' command with its ${argv[1]} set to the two-character
string "if".  That would report "command not found" if the outer
condition were true, but is nonetheless not a syntax error; it's
exactly equivalent to:

    if false; then
      this-is-not-a-command-name arg1 arg2
    fi

which is not a syntax error, either.  It's a runtime error.

> but:
>
> $  # if [ "$1" = "start" ]; then
>         if [ "$1" = 'null' ] && return
>    # fi
>
> ./test2:7: parse error near `\n'

Again, this is parsed differently depending on whether
comments are being parsed.

With comments enabled, this is a syntax error because the if on line 2
is unterminated.

With comments disabled, this is a syntax error because the 'then' on the
first line doesn't follow an if.

Cheers,

Daniel