Re: PATCH: printf builtin

[Peter Stephenson <pws@xxxxxxx>]

Oliver Kiddle wrote:
> Ksh and bash both have a printf builtin. This adds one to zsh.

Yes, this is a good idea.

> I'm inclined to think this should be in a loadable module - it isn't
> that useful interactively but then it isn't particularly large either.
> Any views on that? If it should be a module, should it be compiled in
> by default for a static zsh?

It depends how how large it's likely to grow.  We may end up implementing
more and more internally to avoid problems with differing versions of
printf (and pre-parsing printf text for passing on to printf in a slightly
different format is not something anyone would *want* to do anyway).  But
at the moment it's not a very large builtin --- plus there are precedents
for later moving builtins out to modules which are automatically linked in.

Some other comments: it's perennially annoying that printf here and
elsewhere doesn't add the newline in the way print does, so (unlike in
perl) they aren't natural companions.  For this and other reasons I'd quite
like a flag to ordinary print to turn on printf handling but keep all the
usually options --- although it does change the way arguments are
interpreted.  This allows us to make it useful without running into
compatibility problems with other implementations.

Also, I don't understand what's happening here.
  % printf "The answer is %d\x0c" 13
  The answer is -4265416
I can't seem to get any of the numeric formats to work.  In fact, I can't
get the string format to work either.  Maybe there's some portability
problem with the val union?  I haven't looked any closer.  Precision and
width don't make any difference; __packed__ doesn't help, nor would I
expect it to.

Also, it might be an idea, in common with other parts of the shell, to
perform a matheval on arguments which are going to be treated numerically,
then co-erce them to integer or floating point as needed.  (This should
also make things like `printf "%d" 1e3' work transparently --- if it
doesn't it's my fault and I haven't made the math code smart enough.)

Also, it's not good enough that zsh-style printf handling happens before
%-handling; ideally they should be concurrent, which is probably a lot more
work:
  % printf "\x25d\n" 32
  -4265416
--- same problem with %d as before, but the point is here the resulting `%'
should be treated literally.  Or it needs at least to be documented that
there are two distinct levels of processing, but I consider that a less
attractive solution, ultimately:  there are already quite enough levels of
print escape handling (c.f. `print "\\\\"') without making this a separate
one: either backslash handling, or percent handling, but not both on the
same piece of text.

-- 
Peter Stephenson <pws@xxxxxxx>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************