Re: PATCH: printf builtin

[Oliver Kiddle <okiddle@yahoo.co.uk>]

Bart Schaefer wrote:
> 
> There is a bit of an issue with respect to combining with -s and -z, as
> those at present imply -n, and -z also implies -r; the question is what
> to do with trailing newlines if they appear in the format string.

A difficult question that. To follow ksh's example with -s, only up to
the first newline would go in the history but ksh can't store multi-line
commands in its history in the first place. I think we should be putting
it in exactly as the user asked for with the trailing newline but I'm
not sure.

And, as far as I can tell -z doesn't imply -r.

Peter Stephenson wrote:
> 
> 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.

Well, if we do ksh's -f to turn on printf handling it would be easy to
then add another option to force adding a final newline. Any
suggestions on the choice of letter?

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

What platform are you getting that with? I suspect the val union too but
it'd be nice to check.

When I used that val union, I feared that it would have portability
problems but the alternative was to repeat the block of code with the
varying calls to printf about five times. Does anyone have any ideas how
to maybe get this working. I don't really have a clue how the special
case of varying arguments to printf is handled. Would it maybe be
possible to record the sizeof() for the part of val used and have some
sort of typecast fix the size of val when it is passed to printf?

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

That's not a bad idea. Presumably this would also allow the parameter to
be a variable name or a calculation too.

> 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

I did think about that. I was very suprised that printf(3) seems to
work this way. Bash and ksh also do but a couple of external printf(1)s
work - treating the resulting `%' literally. I agree with you that that
is the better behaviour though. getkeystring() will need changes for
this so I'll leave this until I merge it into bin_print() and I'll deal
with the \c situation at the same time.

Cheers

Oliver

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp