Re: padding.

Re: padding.

[Daniel Shahaf]

Ray Andrews wrote on Fri, Feb 10, 2017 at 19:15:14 -0800:
> $ integer -x vvar=-1
> $ echo ${(l:5::0:)vvar}
> 
> 
> 000-1
> 
> 
> How do I get "-00005"? But also with the negative not counting as part of
> the padding?  Or is this a job for printf?  It seems to be asking quite a
> bit from zsh itself.

${(l)} is a string operator:

% integer x
% echo ${(l:5::x:)x}
xxxx0

So, yes, use printf %05d.

Re: padding.

[Ray Andrews]

On 10/02/17 10:29 PM, Daniel Shahaf wrote:
> % integer x
> % echo ${(l:5::x:)x}
> xxxx0
>
> So, yes, use printf %05d.
Sure, printf is perhaps to be expected, but I wondered if zsh could do 
it directly.

padding.

[Ray Andrews]

$ integer -x vvar=-1
$ echo ${(l:5::0:)vvar}


000-1


How do I get "-00005"? But also with the negative not counting as part 
of the padding?  Or is this a job for printf?  It seems to be asking 
quite a bit from zsh itself.

Re: padding.

[Bart Schaefer]

On Feb 10,  7:15pm, Ray Andrews wrote:
} Subject: padding.
}
} $ integer -x vvar=-1
} $ echo ${(l:5::0:)vvar}
} 
} How do I get "-00005"?

In addition to the suggestion of printf,

integer -Z 6 vvar=-1

    -Z [ N ]
          Specially handled if set along with the -L flag.  Otherwise,
          similar to -R, except that leading zeros are used for padding
          instead of blanks if the first non-blank character is a digit.
          Numeric parameters are specially handled: they are always
          eligible for padding with zeroes, and the zeroes are inserted
          at an appropriate place in the output.

} But also with the negative not counting as part of
} of the padding?

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.

Re: padding.

[Ray Andrews]

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.

BTW, is this kosher:


|$  if [ "$1" = "start" ]; then||
||        if [ "$1" = 'null' ] && return||
||   fi||
||
||(no message) and:||
||
||$  if [ "$1" = "start" ]; then||
||        # if [ "$1" = 'null' ] && return||
||   fi||
||
||(no message) but:||
||
||$  # if [ "$1" = "start" ]; then||
||        if [ "$1" = 'null' ] && return||
||   # fi||
||
||||./test2:7: parse error near `\n'||
|
... I just noticed this in some of my code.  Seems to me that samples 
one and two above should throw an error because there are two 'fi' 
needed but they seem to be sharing the single one.   And sample three 
gets it right, no?

Re: padding.

[Ray Andrews]

On 11/02/17 05:54 PM, Ray Andrews wrote:

Sorry, God knows why that formatted like that.

> BTW, is this kosher:
>
>
> $  if [ "$1" = "start" ]; then
>         if [ "$1" = 'null' ] && return
>    fi
>
> (no message) and:
>
> $  if [ "$1" = "start" ]; then
>         # if [ "$1" = 'null' ] && return
>    fi
>
> (no message) but:
>
> $  # if [ "$1" = "start" ]; then
>         if [ "$1" = 'null' ] && return
>    # fi
>
> ./test2:7: parse error near `\n'
>
> ... I just noticed this in some of my code.  Seems to me that samples 
> one and two above should throw an error because there are two 'fi' 
> needed but they seem to be sharing the single one.   And sample three 
> gets it right, no?
>
>

Re: padding.

[Daniel Shahaf]

[@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

Re: padding.

[Ray Andrews]

On 11/02/17 10:14 PM, Daniel Shahaf wrote:
> 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.

I have a sort of built-in thinking that 'direct syntax' (if that means 
anything) is always better.   Dunno, maybe because I presume that 
commands are external, another hangover from DOS.  I think that if I 
'don't need' printf then I shouldn't use it.  Scottish frugality?  
Probably I should try to avoid that thinking as baseless.  As to the 
variable, I was sorta  pondering that and of course the answer is just 
as you give it.

Re: padding.

[Ray Andrews]

On 11/02/17 10:14 PM, Daniel Shahaf wrote:
>
> % 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?

Well no one else has commented on it, but I don't know how it could not 
be a bug, tho this 'shortloops' must  be there for a reason. Docs refer 
to the 'short form' of various constructs but what's the point of it 
here?  I see the use with 'while', but with 'if' it seems trivial.  I 
see it as just letting me get away with mistakes.
>
>> and:
>>
>> $  if [ "$1" = "start" ]; then
>>          # if [ "$1" = 'null' ] && return
>>     fi
>>
>> (no message)
> That's expected.

Yes, it's just there as contrast for the questionable one.

Re: padding.

[Ray Andrews]

On 13/02/17 08:27 PM, Mikael Magnusson wrote:
> Yes, the shortloops option turns a lot of what should be obvious
> syntax errors into code that does unobviously weird things, which is
> why i always tell people to turn it off.
>
Now that's what I call a helpful comment!  Not just the tech of the 
thing but some honest advice.  Yeah, I've already turned it off 
(shouldn't something like that be off by default?) and I was pleased 
that only one error showed up in all my functions.