Re: PATCH: print -v with an array

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sep 19,  6:50pm, Oliver Kiddle wrote:
}
} This patch makes print -v check if the variable is an array and if
} so, each reuse of the format string will correspond to a separate
} array element.  [...]  printf -v was added
} after zsh 5.2 was released so we've no compatibility concern there.
} [...]
} With a bit of rearrangment of bin_print it would now be possible
} to use this to allow more mixing of print options: -f with -c, for
} example.

When did we get the ability to do "print -z -f ..."  It might be
useful to have every reuse of the format add a separate entry to
the buffer stack.  Similarly for "print -s -f" and the history.
(Currently -S is silently ignored if -f is given.  Hmm.  Not sure
how that ought to work anyway.)

} Alternatives to checking if the variable is an array first would
} be a -A option or perhaps making the feature specific to print
} (which bash lacks) and not to printf.

I'd lean toward the -A option (especially if we alter -z / -s as I
just mentioned above).  Right now print -v / printf -v can create a
variable (for which BTW we are lacking a WARN_CREATE_GLOBAL warning),
it'd be nice to create it as an array.

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.

} Back in January, when I wasn't paying attention, Bart wrote:
} > - Should "print -v foo bar" write the trailing newline into $foo ?  In the
} >   patch below I've chosen to make -n implicit with -v.  This does not
} >   involve "printf" which always needs an explicit newline.
} 
} 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.

} With print -v the open_memstream stuff might see more usage. Should
} we be concerned with more efficient alternatives to the temporary
} file fallback?

I have no opinion here, except to grumble about ending up with three
or four #ifdef'd implementations of the same thing.