Re: PATCH: print -v with an array

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Bart wrote:
> When did we get the ability to do "print -z -f ..."  It might be

Not long after printf itself was added.

> useful to have every reuse of the format add a separate entry to
> the buffer stack.  Similarly for "print -s -f" and the history.

I doubt that anyone would notice a change of behaviour. Is multiple
entries definitely more useful?

> (Currently -S is silently ignored if -f is given.  Hmm.  Not sure
> how that ought to work anyway.)

-S is also missing from the completion function so I've missed that.
The only way it could work is for the parsing and splitting to be done
last. It doesn't even take more than one argument at the moment.

> I'd lean toward the -A option (especially if we alter -z / -s as I

Being able to create the array direct is nice and it is more
consistent with read and set. My concern was that adding ever more
options causes the most commonly used ones to get buried in
documentation and completion listings.

> just mentioned above).  Right now print -v / printf -v can create a
> variable (for which BTW we are lacking a WARN_CREATE_GLOBAL warning),

WARN_CREATE_GLOBAL is handled internally to setsparam so that's covered.

> I see you've implemented it by building up the array and then doing
> the assignment all at once, rather than appending one element at a
> time.  This makes it possible to use it for associative arrays, even
> though it'd be a bit unusual to have the same format for both keys
> and values.

While it's only five lines of code to check for a hash and use
sethparam, it just doesn't seem useful enough to do that.

> } > - Should "print -v foo bar" write the trailing newline into $foo ?  In the
> } I'd suggest we include the trailing newline if the -l option was
> } specified. Seems it does get included with -c.
>
> It's probably a mistake/oversight with -c.  The *embedded* newlines
> always get included.  The question is whether
>
>     print -l one two three four
> and
>     print -l -v stuff one two three four
>     print "$stuff"
>
> should produce identical output, rather than the latter having two
> consecutive newlines at the end.  Whichever way we decide, the same
> really should also apply to -c.

I'd vote for the two consecutive newlines in the case of both -l and -c.

Oliver