From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh workers <zsh-workers@zsh.org>
Subject: Re: PATCH: print -v with an array
Date: Mon, 19 Sep 2016 13:30:47 -0700 [thread overview]
Message-ID: <160919133047.ZM28795@torch.brasslantern.com> (raw)
In-Reply-To: <53992.1474303843@hydra.kiddle.eu>
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.
next prev parent reply other threads:[~2016-09-19 20:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-19 16:50 Oliver Kiddle
2016-09-19 20:30 ` Bart Schaefer [this message]
2016-09-21 19:51 ` Oliver Kiddle
2016-09-21 21:24 ` Bart Schaefer
2016-11-04 16:37 ` Oliver Kiddle
2016-11-05 4:03 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=160919133047.ZM28795@torch.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).