Counting characters in command output?

Counting characters in command output?

[Mark J. Reed]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

I thought this would give me the length of the string, but it seems to be
counting words instead:

     zsh% echo ${#$(echo hello)}
     1

Is this a bug? I thought I'd need a modifier flag to treat output as an
array and give me  a word count, while character count would be the default.

-- 
Mark J. Reed <markjreed@gmail.com>

[-- Attachment #2: Type: text/html, Size: 701 bytes --]

Re: Counting characters in command output?

[Roman Perepelitsa]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

On Tue, 13 Feb 2024 at 21:39, Mark J. Reed <markjreed@gmail.com> wrote:

> I thought this would give me the length of the string, but it seems to be
> counting words instead:
>
>      zsh% echo ${#$(echo hello)}
>      1
>
> Is this a bug? I thought I'd need a modifier flag to treat output as an
> array and give me  a word count, while character count would be the default.
>

Process substitution gives you an array. Quote it if you need a scalar.

Roman.

>

[-- Attachment #2: Type: text/html, Size: 1306 bytes --]

Re: Counting characters in command output?

[Mark J. Reed]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

On Tue, Feb 13, 2024 at 3:41 PM Roman Perepelitsa <
roman.perepelitsa@gmail.com> wrote:

> On Tue, 13 Feb 2024 at 21:39, Mark J. Reed <markjreed@gmail.com> wrote:
>
>> I thought this would give me the length of the string, but it seems to be
>> counting words instead:
>>
>>      zsh% echo ${#$(echo hello)}
>>      1
>>
>> Is this a bug? I thought I'd need a modifier flag to treat output as an
>> array and give me  a word count, while character count would be the default.
>>
>
> 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!


-- 
Mark J. Reed <markjreed@gmail.com>

[-- Attachment #2: Type: text/html, Size: 1786 bytes --]

Re: Counting characters in command output?

[Roman Perepelitsa]

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.

Re: Counting characters in command output?

[Mark J. Reed]

[-- 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 --]

Re: Counting characters in command output?

[Ray Andrews]

[-- 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 --]

Re: Counting characters in command output?

[Mark J. Reed]

[-- 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 --]

Re: Counting characters in command output?

[Ray Andrews]

[-- 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 --]

Re: Counting characters in command output?

[Roman Perepelitsa]

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.

Re: Counting characters in command output?

[Lawrence Velázquez]

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

Re: Counting characters in command output?

[Lawrence Velázquez]

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

Re: Counting characters in command output?

[Ray Andrews]

[-- 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 --]

Re: Counting characters in command output?

[Ray Andrews]

[-- 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 --]

Re: Counting characters in command output?

[Roman Perepelitsa]

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.

Re: Counting characters in command output?

[Ray Andrews]

[-- 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 --]

Re: Counting characters in command output?

[Bart Schaefer]

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

Re: Counting characters in command output?

[Lawrence Velázquez]

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

Re: Counting characters in command output?

[Bart Schaefer]

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.

Re: Counting characters in command output?

[Mark J. Reed]

[-- 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 --]

Re: Counting characters in command output?

[Bart Schaefer]

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.

Re: Counting characters in command output?

[Lawrence Velázquez]

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

Re: Counting characters in command output?

[Mikael Magnusson]

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