* Re: Counting characters in command output?
2024-02-14 6:49 ` Roman Perepelitsa
@ 2024-02-14 13:56 ` Mark J. Reed
2024-02-14 15:36 ` Ray Andrews
2024-02-16 1:53 ` Bart Schaefer
2 siblings, 0 replies; 22+ messages in thread
From: Mark J. Reed @ 2024-02-14 13:56 UTC (permalink / raw)
To: Zsh Users
[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]
I think splitting vs not splitting could go either way; there are pros and
cons to each default, and as long as there's a mechanism to do the other
one, it's workable.
But I do think it's a bit counterintuitive that parameter expansion is not
split by default, while command expansion is. I would in general have
expected *foo $(bar) * to behave identically to *baz=$(bar); foo $baz*. In
bash or ksh, that's true (probably absent some edge cases I'm not thinking
of), but not in zsh. Specifically, I would have thought you'd need *${=$(...)}
*to get the word spitting that you instead get by default.
On Wed, Feb 14, 2024 at 1:49 AM Roman Perepelitsa <
roman.perepelitsa@gmail.com> wrote:
> On Wed, Feb 14, 2024 at 1:46 AM Mark J. Reed <markjreed@gmail.com> wrote:
> >
> > On Tue, Feb 13, 2024 at 3:41 PM Roman Perepelitsa <
> roman.perepelitsa@gmail.com> wrote:
> >>
> >> Process substitution gives you an array. Quote it if you need a scalar.
> >
> > You mean command substitution, but thanks! It wouldn't have
> > occurred to me to put quotes around it to change what the `#` was
> > counting!
>
> Right, command substitution. In my opinion, it's unfortunate that
> command substitution in zsh splits on IFS by default. I wish this
> wasn't the case. It's not even common that one wants to split command
> output into words. Lines -- perhaps, but not words. So the default
> behavior in this case is rarely what is desired and has to be actively
> turned off.
>
> Roman.
>
--
Mark J. Reed <markjreed@gmail.com>
[-- Attachment #2: Type: text/html, Size: 2302 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Counting characters in command output?
2024-02-14 6:49 ` Roman Perepelitsa
2024-02-14 13:56 ` Mark J. Reed
@ 2024-02-14 15:36 ` Ray Andrews
2024-02-14 15:58 ` Mark J. Reed
2024-02-15 9:50 ` Roman Perepelitsa
2024-02-16 1:53 ` Bart Schaefer
2 siblings, 2 replies; 22+ messages in thread
From: Ray Andrews @ 2024-02-14 15:36 UTC (permalink / raw)
To: zsh-users
[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]
On 2024-02-13 22:49, Roman Perepelitsa wrote:
> Right, command substitution. In my opinion, it's unfortunate that
> command substitution in zsh splits on IFS by default. I wish this
> wasn't the case. It's not even common that one wants to split command
> output into words. Lines -- perhaps, but not words. So the default
> behavior in this case is rarely what is desired and has to be actively
> turned off.
What are the vectors? First must be logical necessity, second
consistency -- avoid strange exceptions -- third and fourth would be
helpfulness and tradition, with old-school guys favoring tradition and
guys like me favoring helpfulness. I've spent more hours trying to get
splitting issues correct than anything else. Characters, words, IFS,
lines, elements ... it's the most obscure and confusing part of the
shell. Lacking any focused explanation of the entire subject what I do
is just throw saved snippets of code at problems until something sticks
-- it looks about right, but even there I might think I have line
splitting when it's really elements. I wish there were enough of us on
this list to put things to a vote sometimes and in this case I'd bet
that Roman's view would win overwhelmingly. I myself almost always
want lines. Or elements. Sometimes words, almost never characters.
[-- Attachment #2: Type: text/html, Size: 1833 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Counting characters in command output?
2024-02-14 15:36 ` Ray Andrews
@ 2024-02-14 15:58 ` Mark J. Reed
2024-02-14 16:30 ` Ray Andrews
2024-02-15 9:50 ` Roman Perepelitsa
1 sibling, 1 reply; 22+ messages in thread
From: Mark J. Reed @ 2024-02-14 15:58 UTC (permalink / raw)
To: zsh-users
[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]
> I myself almost always want lines. Or elements. Sometimes words,
almost never characters.
As I said, it's the consistency. If you have a scalar parameter named *foo*,
*$#foo* is the number of characters. If it's an array, *$#foo* is the
number of elements. The key point in my mind is that when you assign a
parameter from command substitution, e.g. *foo=$(bar)*, then what you get
is a scalar parameter, not an array. You *can* get an array instead, but
you have to ask for it explicitly by putting extra parentheses around the
right hand side: *foo=($(bar))*. So parameter assignment defaults to scalar
mode and requires extra punctuation to do array mode. But directly counting
the result of the substitution with no intervening parameter defaults to
array mode and requires extra punctuation to do scalar mode.
On Wed, Feb 14, 2024 at 10:37 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
>
> On 2024-02-13 22:49, Roman Perepelitsa wrote:
>
> Right, command substitution. In my opinion, it's unfortunate that
>
> command substitution in zsh splits on IFS by default. I wish this
> wasn't the case. It's not even common that one wants to split command
> output into words. Lines -- perhaps, but not words. So the default
> behavior in this case is rarely what is desired and has to be actively
> turned off.
>
> What are the vectors? First must be logical necessity, second consistency
> -- avoid strange exceptions -- third and fourth would be helpfulness and
> tradition, with old-school guys favoring tradition and guys like me
> favoring helpfulness. I've spent more hours trying to get splitting issues
> correct than anything else. Characters, words, IFS, lines, elements ...
> it's the most obscure and confusing part of the shell. Lacking any
> focused explanation of the entire subject what I do is just throw saved
> snippets of code at problems until something sticks -- it looks about
> right, but even there I might think I have line splitting when it's really
> elements. I wish there were enough of us on this list to put things to a
> vote sometimes and in this case I'd bet that Roman's view would win
> overwhelmingly. I myself almost always want lines. Or elements.
> Sometimes words, almost never characters.
>
>
>
>
--
Mark J. Reed <markjreed@gmail.com>
[-- Attachment #2: Type: text/html, Size: 3229 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Counting characters in command output?
2024-02-14 15:58 ` Mark J. Reed
@ 2024-02-14 16:30 ` Ray Andrews
2024-02-15 14:34 ` Lawrence Velázquez
0 siblings, 1 reply; 22+ messages in thread
From: Ray Andrews @ 2024-02-14 16:30 UTC (permalink / raw)
To: zsh-users
[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]
On 2024-02-14 07:58, Mark J. Reed wrote:
> > I myself almost always want lines. Or elements. Sometimes words,
> almost never characters.
>
> As I said, it's the consistency.
Right. That would be second on my list of vectors and should trump
tradition, especially when, as Roman says, most users don't prefer the
status quo.
> If you have a scalar parameter named *foo*, *$#foo* is the number of
> characters. If it's an array, *$#foo* is the number of elements. The
> key point in my mind is that when you assign a parameter from command
> substitution, e.g. *foo=$(bar)*, then what you get is a scalar
> parameter, not an array. You /can/ get an array instead, but you have
> to ask for it explicitly by putting extra parentheses around the right
> hand side: *foo=($(bar))*. So parameter assignment defaults to scalar
> mode and requires extra punctuation to do array mode. But directly
> counting the result of the substitution with no intervening parameter
> defaults to array mode and requires extra punctuation to do scalar mode.
So really there is a logical problem too. We have another 'invisible'
transformation. We 'have' quarts but liters are what's counted, yes?
> I would in general have expected *foo $(bar) * to behave
identically to *baz=$(bar); foo $baz*.
Yes, it would be non-negotiable in algebra. a=b; b=c; ergo a=c.
[-- Attachment #2: Type: text/html, Size: 2263 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Counting characters in command output?
2024-02-14 16:30 ` Ray Andrews
@ 2024-02-15 14:34 ` Lawrence Velázquez
0 siblings, 0 replies; 22+ messages in thread
From: Lawrence Velázquez @ 2024-02-15 14:34 UTC (permalink / raw)
To: Ray Andrews; +Cc: zsh-users
On Wed, Feb 14, 2024, at 11:30 AM, Ray Andrews wrote:
> So really there is a logical problem too. We have another 'invisible'
> transformation. We 'have' quarts but liters are what's counted, yes?
>
>> I would in general have expected *foo $(bar) * to behave identically to *baz=$(bar); foo $baz*.
>
> Yes, it would be non-negotiable in algebra. a=b; b=c; ergo a=c.
The shell language isn't algebra. This is hardly the only case in
which the substitution principle doesn't hold without putting in
some extra work (which I'm omitting here for demonstration purposes).
% foo=(a b c)
% printf '<%s>' $foo; echo
<a><b><c>
% bar=$foo
% printf '<%s>' $bar; echo
<a b c>
--
vq
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Counting characters in command output?
2024-02-14 15:36 ` Ray Andrews
2024-02-14 15:58 ` Mark J. Reed
@ 2024-02-15 9:50 ` Roman Perepelitsa
2024-02-15 14:30 ` Lawrence Velázquez
2024-02-15 14:53 ` Ray Andrews
1 sibling, 2 replies; 22+ messages in thread
From: Roman Perepelitsa @ 2024-02-15 9:50 UTC (permalink / raw)
To: Ray Andrews; +Cc: zsh-users
On Wed, Feb 14, 2024 at 4:37 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> What are the vectors? First must be logical necessity, second
> consistency -- avoid strange exceptions -- third and fourth would
> be helpfulness and tradition, with old-school guys favoring
> tradition and guys like me favoring helpfulness.
In any debate between tradition and helpfulness, ensure your
counterpart agrees with this perspective. Should they present
arguments they consider essential for necessity and consistency, and
you categorize them merely as "tradition," dialogue ceases. From their
standpoint, your stance appears at best inconsistent, or at worst,
vague, and you fail to recognize their points even when clearly
outlined.
> I wish there were enough of us on this list to put things to a vote
> sometimes [...]
For anything to happen, somebody has to do the work. There is no point
in voting if the vote has no consequences: it's not an obligation for
anybody to do the work, nor does any work require an approval from
voters.
Bart has done the work of adding named references, so now we'll have
named references. Bart designed the feature, implemented it, and wrote
documentation. At each point everyone was free to contribute to this
effort or to oppose it. Both of these require work, too.
Compare what Bart has done to my posting an opinion on this thread.
One is work, and thus has impact, the other isn't and remains
inconsequential.
Roman.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Counting characters in command output?
2024-02-15 9:50 ` Roman Perepelitsa
@ 2024-02-15 14:30 ` Lawrence Velázquez
2024-02-15 15:29 ` Ray Andrews
2024-02-15 14:53 ` Ray Andrews
1 sibling, 1 reply; 22+ messages in thread
From: Lawrence Velázquez @ 2024-02-15 14:30 UTC (permalink / raw)
To: Roman Perepelitsa, Ray Andrews; +Cc: zsh-users
On Thu, Feb 15, 2024, at 4:50 AM, Roman Perepelitsa wrote:
> On Wed, Feb 14, 2024 at 4:37 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>>
>> What are the vectors? First must be logical necessity, second
>> consistency -- avoid strange exceptions -- third and fourth would
>> be helpfulness and tradition, with old-school guys favoring
>> tradition and guys like me favoring helpfulness.
>
> In any debate between tradition and helpfulness, ensure your
> counterpart agrees with this perspective. Should they present
> arguments they consider essential for necessity and consistency, and
> you categorize them merely as "tradition," dialogue ceases. From their
> standpoint, your stance appears at best inconsistent, or at worst,
> vague, and you fail to recognize their points even when clearly
> outlined.
I would push it further: The worst-case perception would be one of ignorant arrogance. Compatibility is not tradition, but calling it so suggests a dismissive, uncharitable belief that there are no plausible reasons for it -- only a stubborn preference for How Things Used to Be. People rarely respond well when they think they're being called sclerotic morons.
>> I wish there were enough of us on this list to put things to a vote
>> sometimes [...]
>
> For anything to happen, somebody has to do the work. There is no point
> in voting if the vote has no consequences: it's not an obligation for
> anybody to do the work, nor does any work require an approval from
> voters.
Voting is a poor mechanism for building consensus, in any case.
https://producingoss.com/en/consensus-democracy.html#when-to-vote
--
vq
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Counting characters in command output?
2024-02-15 14:30 ` Lawrence Velázquez
@ 2024-02-15 15:29 ` Ray Andrews
2024-02-15 16:16 ` Roman Perepelitsa
0 siblings, 1 reply; 22+ messages in thread
From: Ray Andrews @ 2024-02-15 15:29 UTC (permalink / raw)
To: zsh-users
[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]
On 2024-02-15 06:30, Lawrence Velázquez wrote:
> I would push it further: The worst-case perception would be one of ignorant arrogance. Compatibility is not tradition, but calling it so suggests a dismissive, uncharitable belief that there are no plausible reasons for it -- only a stubborn preference for How Things Used to Be. People rarely respond well when they think they're being called sclerotic morons.
On the contrary, compatibility is deference to tradition almost by
definition. However it does not follow that tradition is to be
deprecated or dismissed -- long standing traditions often stand long
because they deserve to, and compatibility is a value in itself -- one
breaks compatibility only if some practical advantage clearly merits the
added confusion of incompatibility. In this case Mark had an issue,
Roman agreed that the default was not optimal, and I'm agreeing with
them. Your hostility seems overwrought. Voting is a poor mechanism for
building consensus, in any case.
> https://producingoss.com/en/consensus-democracy.html#when-to-vote
Interesting!
% foo=(a b c)
% printf '<%s>' $foo; echo
<a><b><c>
% bar=$foo
% printf '<%s>' $bar; echo
<a b c>
Ok, but:
% foo=(a b c);printf '<%s>' $foo; echo; bar=($foo); printf '<%s>' $bar; echo
^ ^
<a><b><c>
<a><b><c>
... it is established that the assignment must be forced to array and will default to scalar, no? Sure, it's not exactly algebra but it is bedrock zsh grammar. And wasn't it Mark's original point that command substitution should likewise default to scalar?
Anyway these probings of mine bother you so perhaps I should say nothing.
[-- Attachment #2: Type: text/html, Size: 2624 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Counting characters in command output?
2024-02-15 15:29 ` Ray Andrews
@ 2024-02-15 16:16 ` Roman Perepelitsa
2024-02-15 16:55 ` Ray Andrews
0 siblings, 1 reply; 22+ messages in thread
From: Roman Perepelitsa @ 2024-02-15 16:16 UTC (permalink / raw)
To: Ray Andrews; +Cc: zsh-users
On Thu, Feb 15, 2024 at 4:29 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> In this case Mark had an issue, Roman agreed that the default was
> not optimal, and I'm agreeing with them.
My little opinion doesn't constitute a detailed proposal for change,
nor does it represent an alternative solution that might have been
applicable in the past. I harbor doubts about its potential to evolve
into anything substantial, acknowledging that any such development
would necessitate effort I'm not prepared to expend. Given the minimal
effort I've dedicated to forming this opinion, I recognize that others
are under no obligation to engage with or comment on it. I've aimed to
express my thoughts modestly to accurately reflect my assessment of
their value, though I concede I may not have fully succeeded. When you
agree with my opinion and wish for a vote, you give it more credit
than it deserves. It's not developed enough for either of these
things.
Roman.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Counting characters in command output?
2024-02-15 16:16 ` Roman Perepelitsa
@ 2024-02-15 16:55 ` Ray Andrews
0 siblings, 0 replies; 22+ messages in thread
From: Ray Andrews @ 2024-02-15 16:55 UTC (permalink / raw)
To: zsh-users
[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]
On 2024-02-15 08:16, Roman Perepelitsa wrote:
> My little opinion doesn't constitute a detailed proposal for change,
> nor does it represent an alternative solution that might have been
> applicable in the past. I harbor doubts about its potential to evolve
> into anything substantial, acknowledging that any such development
> would necessitate effort I'm not prepared to expend. Given the minimal
> effort I've dedicated to forming this opinion, I recognize that others
> are under no obligation to engage with or comment on it. I've aimed to
> express my thoughts modestly to accurately reflect my assessment of
> their value, though I concede I may not have fully succeeded. When you
> agree with my opinion and wish for a vote, you give it more credit
> than it deserves. It's not developed enough for either of these
> things.
Understood and taken for granted. My own thoughts on the subject should
be taken in the same spirit and then diminished further due to my lack
of experience and knowledge. It disturbs me when my comments are taken
more seriously by others than I take them myself -- they are ...
'investigations' is perhaps the right word. For example I wasn't
suggesting an actual vote, I was musing on the possibility that
arbitrary defaults might be determined by polling users as a general
principle. Dunno, I'd stop doing that sort of thing entirely since some
strongly object to it, however I do get responses which seems to
indicate that some -- notably yourself -- find discussing such matters
worth doing. I myself always come out of it the wiser. It's an
exploration. Take everything I say very litely.
[-- Attachment #2: Type: text/html, Size: 2140 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Counting characters in command output?
2024-02-15 9:50 ` Roman Perepelitsa
2024-02-15 14:30 ` Lawrence Velázquez
@ 2024-02-15 14:53 ` Ray Andrews
1 sibling, 0 replies; 22+ messages in thread
From: Ray Andrews @ 2024-02-15 14:53 UTC (permalink / raw)
To: zsh-users
[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]
On 2024-02-15 01:50, Roman Perepelitsa wrote:
> In any debate between tradition and helpfulness, ensure your
> counterpart agrees with this perspective. Should they present
> arguments they consider essential for necessity and consistency, and
> you categorize them merely as "tradition," dialogue ceases. From their
> standpoint, your stance appears at best inconsistent, or at worst,
> vague, and you fail to recognize their points even when clearly
> outlined.
Sure. Nobody wins a debate like that automatically. In this case I
agree with yourself and Mark, and I'm just saying why. If my arguments
(or yours or Mark's) fail to persuade then they go nowhere. As for me,
I'm wrong more often than I'm right. Like that last thing -- I got my
brain twisted into a pretzel and it took Mark to straighten me out
privately. (I was actually going to apologize to the list but didn't
want to waste even more keystrokes.)
>
> For anything to happen, somebody has to do the work. There is no point
> in voting if the vote has no consequences: it's not an obligation for
> anybody to do the work, nor does any work require an approval from
> voters.
Yeah, it's the ultimate worker's paradise -- if someone thinks something
is worth doing it might just get done. Still, when a default could be
considered arbitrary, one might inquire of the masses which they'd
prefer. And I think you and Mark are correct on that point.
> Compare what Bart has done to my posting an opinion on this thread.
> One is work, and thus has impact, the other isn't and remains
> inconsequential.
Unless the devs take your point, and implement it. Talk precedes work
and good talk makes for good work.
[-- Attachment #2: Type: text/html, Size: 2517 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Counting characters in command output?
2024-02-14 6:49 ` Roman Perepelitsa
2024-02-14 13:56 ` Mark J. Reed
2024-02-14 15:36 ` Ray Andrews
@ 2024-02-16 1:53 ` Bart Schaefer
2024-02-16 4:53 ` Lawrence Velázquez
2 siblings, 1 reply; 22+ messages in thread
From: Bart Schaefer @ 2024-02-16 1:53 UTC (permalink / raw)
To: Zsh Users
Entering this conversation here because it seems to be the point after
which it sort of went off the rails. Go away for a few days and look
what I get ...
On Tue, Feb 13, 2024 at 10:49 PM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> On Wed, Feb 14, 2024 at 1:46 AM Mark J. Reed <markjreed@gmail.com> wrote:
> >
> > On Tue, Feb 13, 2024 at 3:41 PM Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote:
> >>
> >> Process substitution gives you an array. Quote it if you need a scalar.
> >
> > You mean command substitution, but thanks! It wouldn't have
> > occurred to me to put quotes around it to change what the `#` was
> > counting!
>
> Right, command substitution. In my opinion, it's unfortunate that
> command substitution in zsh splits on IFS by default. I wish this
> wasn't the case.
This is a case where original author Paul Falstad chose to stick to
the behavior common to other shells. In particular ...
In all extent shells at the time, but especially in BSD csh, `command`
(backticks) splits its output into words.
$(command) and `command` are supposed to be equivalent (except for nesting).
Therefore $(command) splits its output into words, as happens in every
other shell.
The only place zsh introduced a distinction from the default splitting
behavior of other shells was in parameter expansion.
> It's not even common that one wants to split command
> output into words.
The presumption is that most uses of `command` and $(command) are in
the argument list of other commands (for example, that every word of
the output is a file name), and that anyone coming to zsh from another
shell (which again at the time was the vast majority of zsh users)
would be confused if that behavior were not preserved for backticks
and therefore also for $(...).
If you're using it in an assignment and not to create an argument
list, it's entirely consistent with the behavior of scalars and arrays
that
scalar=`command`
suppresses splitting (unless the appropriate option is set!) whereas
array=(`command`)
does not, and if you don't want the splitting behavior then you have
quoting (or prior assignment) to make your intention clear.
If you want command substitution without word splitting, then in
whatever the next version ends up being called you have
${ command }
to do that for you, and I am very sorry that I wasn't around two days
ago to say that.
Just for evidence sake:
$ csh
% ls `echo a b c`
ls: cannot access 'a': No such file or directory
ls: cannot access 'b': No such file or directory
ls: cannot access 'c': No such file or directory
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Counting characters in command output?
2024-02-16 1:53 ` Bart Schaefer
@ 2024-02-16 4:53 ` Lawrence Velázquez
2024-02-16 18:03 ` Bart Schaefer
0 siblings, 1 reply; 22+ messages in thread
From: Lawrence Velázquez @ 2024-02-16 4:53 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-users
On Thu, Feb 15, 2024, at 8:53 PM, Bart Schaefer wrote:
> If you want command substitution without word splitting, then in
> whatever the next version ends up being called you have
> ${ command }
> to do that for you
Hm, I wasn't aware of this detail. I see it's mentioned in zshexpn(1)
but don't see anything in the FAQ. Worth mentioning?
diff --git a/Etc/FAQ.yo b/Etc/FAQ.yo
index 7d46e9192..d8c1fe2dd 100644
--- a/Etc/FAQ.yo
+++ b/Etc/FAQ.yo
@@ -1081,6 +1081,11 @@ sect(Comparisons of forking and non-forking command substitution)
bash and ksh, so in emulation modes, newlines are stripped from command
output (not from mytt(REPLY) assignments).
+ Unless enclosed in double quotes, the expansion of mytt($(command)) is
+ split on mytt(IFS). In contrast, and contrary to bash and ksh, unquoted
+ mytt(${ command }) and its variants are not split unless the
+ mytt(SH_WORD_SPLIT) option is set.
+
When mytt(command) is myem(not) a builtin, mytt(${ command }) does fork, and
typically forks the same number of times as mytt($(command)), because in
the latter case zsh usually optimizes the final fork into an exec.
--
vq
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Counting characters in command output?
2024-02-16 4:53 ` Lawrence Velázquez
@ 2024-02-16 18:03 ` Bart Schaefer
2024-02-16 18:38 ` Mark J. Reed
2024-02-16 19:37 ` Lawrence Velázquez
0 siblings, 2 replies; 22+ messages in thread
From: Bart Schaefer @ 2024-02-16 18:03 UTC (permalink / raw)
To: Lawrence Velázquez; +Cc: zsh-users
On Thu, Feb 15, 2024 at 8:55 PM Lawrence Velázquez <larryv@zsh.org> wrote:
>
> + Unless enclosed in double quotes, the expansion of mytt($(command)) is
> + split on mytt(IFS). In contrast, and contrary to bash and ksh, unquoted
> + mytt(${ command }) and its variants are not split unless the
> + mytt(SH_WORD_SPLIT) option is set.
That's not quite accurate, though.
% print -l ${|reply| reply=(a b c)}
a
b
c
It's only ${| REPLY=...} and ${ command } that always behave like scalars.
Even ${| REPLY=(a b c)} behaves like a scalar (joins the array), which
I suppose is also worth mentioning. Will consider wording over the
weekend when I have more time.
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Counting characters in command output?
2024-02-16 18:03 ` Bart Schaefer
@ 2024-02-16 18:38 ` Mark J. Reed
2024-02-16 19:36 ` Bart Schaefer
2024-02-16 19:37 ` Lawrence Velázquez
1 sibling, 1 reply; 22+ messages in thread
From: Mark J. Reed @ 2024-02-16 18:38 UTC (permalink / raw)
To: zsh-users
[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]
On Thu, Feb 15, 2024, at 8:53 PM, Bart Schaefer wrote:
> If you want command substitution without word splitting, then in
> whatever the next version ends up being called you have
> ${ command }
> to do that for you
Is it also the case that *${ command}* runs in the current shell rather
than a subshell and can therefore have side effects (if it's a
function/builtin, of course)? I seem to recall seeing that syntax used that
way before, but it may have been in a different shell.
On Fri, Feb 16, 2024 at 1:03 PM Bart Schaefer <schaefer@brasslantern.com>
wrote:
> On Thu, Feb 15, 2024 at 8:55 PM Lawrence Velázquez <larryv@zsh.org> wrote:
> >
> > + Unless enclosed in double quotes, the expansion of mytt($(command)) is
> > + split on mytt(IFS). In contrast, and contrary to bash and ksh,
> unquoted
> > + mytt(${ command }) and its variants are not split unless the
> > + mytt(SH_WORD_SPLIT) option is set.
>
> That's not quite accurate, though.
>
> % print -l ${|reply| reply=(a b c)}
> a
> b
> c
>
> It's only ${| REPLY=...} and ${ command } that always behave like scalars.
>
> Even ${| REPLY=(a b c)} behaves like a scalar (joins the array), which
> I suppose is also worth mentioning. Will consider wording over the
> weekend when I have more time.
>
>
--
Mark J. Reed <markjreed@gmail.com>
[-- Attachment #2: Type: text/html, Size: 2287 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Counting characters in command output?
2024-02-16 18:38 ` Mark J. Reed
@ 2024-02-16 19:36 ` Bart Schaefer
0 siblings, 0 replies; 22+ messages in thread
From: Bart Schaefer @ 2024-02-16 19:36 UTC (permalink / raw)
To: Mark J. Reed; +Cc: zsh-users
On Fri, Feb 16, 2024 at 10:38 AM Mark J. Reed <markjreed@gmail.com> wrote:
>
> Is it also the case that ${ command} runs in the current shell
Yes.
> I seem to recall seeing that syntax used that way before, but it may have been in a different shell.
It was in another shell ... ksh has had this for quite a while, bash a
bit more recently, mksh the ${| } variation. Dev version of zsh only
for a couple of months.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Counting characters in command output?
2024-02-16 18:03 ` Bart Schaefer
2024-02-16 18:38 ` Mark J. Reed
@ 2024-02-16 19:37 ` Lawrence Velázquez
2024-02-16 21:06 ` Mikael Magnusson
1 sibling, 1 reply; 22+ messages in thread
From: Lawrence Velázquez @ 2024-02-16 19:37 UTC (permalink / raw)
To: Bart Schaefer; +Cc: zsh-users
On Fri, Feb 16, 2024, at 1:03 PM, Bart Schaefer wrote:
> On Thu, Feb 15, 2024 at 8:55 PM Lawrence Velázquez <larryv@zsh.org> wrote:
>>
>> + Unless enclosed in double quotes, the expansion of mytt($(command)) is
>> + split on mytt(IFS). In contrast, and contrary to bash and ksh, unquoted
>> + mytt(${ command }) and its variants are not split unless the
>> + mytt(SH_WORD_SPLIT) option is set.
>
> That's not quite accurate, though.
>
> % print -l ${|reply| reply=(a b c)}
> a
> b
> c
>
> It's only ${| REPLY=...} and ${ command } that always behave like scalars.
Ah, you got me. I only tested out ${ command }, and I overlooked
that var in ${|var| command } could be an array.
--
vq
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Counting characters in command output?
2024-02-16 19:37 ` Lawrence Velázquez
@ 2024-02-16 21:06 ` Mikael Magnusson
0 siblings, 0 replies; 22+ messages in thread
From: Mikael Magnusson @ 2024-02-16 21:06 UTC (permalink / raw)
To: Lawrence Velázquez; +Cc: Bart Schaefer, zsh-users
On 2/16/24, Lawrence Velázquez <larryv@zsh.org> wrote:
> On Fri, Feb 16, 2024, at 1:03 PM, Bart Schaefer wrote:
>> On Thu, Feb 15, 2024 at 8:55 PM Lawrence Velázquez <larryv@zsh.org>
>> wrote:
>>>
>>> + Unless enclosed in double quotes, the expansion of mytt($(command))
>>> is
>>> + split on mytt(IFS). In contrast, and contrary to bash and ksh,
>>> unquoted
>>> + mytt(${ command }) and its variants are not split unless the
>>> + mytt(SH_WORD_SPLIT) option is set.
>>
>> That's not quite accurate, though.
>>
>> % print -l ${|reply| reply=(a b c)}
>> a
>> b
>> c
>>
>> It's only ${| REPLY=...} and ${ command } that always behave like
>> scalars.
>
> Ah, you got me. I only tested out ${ command }, and I overlooked
> that var in ${|var| command } could be an array.
Arguably the statement is still correct; the value is not split in
this case either, it is already an array.
% print -l ${|reply| reply=(a\ b c d)}
a b
c
d
notice how 'a b' is not split on $IFS.
--
Mikael Magnusson
^ permalink raw reply [flat|nested] 22+ messages in thread