piping surprise

piping surprise

[Ray Andrews]

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

Speaking of female logic, I stumbled upon this:

function bbb ()
{
     vvar=4
     print -l "\nShall\nI\ncompare thee\nto a\nsummer's day?"
}

function aaa ()
{
     local vvar=1
     bbb
     echo "\nvvar is $vvar"
     vvar=2
     echo "\n=============\n"
     bbb | grep 'a'
     echo "\nvvar is $vvar"
}

%  aaa

Shall
I
compare thee
to a
summer's day?

vvar is 4

=============

Shall
compare thee
to a
summer's day?

vvar is 2

------------------------------------------------------------------

By what thinking does the piping of a function's output thru grep cancel 
the assignment to the variable?  Do we really want that?



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

Re: piping surprise

[Mikael Magnusson]

On Wed, Apr 3, 2024 at 3:19 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Speaking of female logic, I stumbled upon this:

Keep your sexism to yourself, although in this case you're just
insulting yourself anyway.

> function bbb ()
> {
>     vvar=4
>     print -l "\nShall\nI\ncompare thee\nto a\nsummer's day?"
> }
>
> function aaa ()
> {
>     local vvar=1
>     bbb
>     echo "\nvvar is $vvar"
>     vvar=2
>     echo "\n=============\n"
>     bbb | grep 'a'
>     echo "\nvvar is $vvar"
> }
>
> %  aaa
>
> Shall
> I
> compare thee
> to a
> summer's day?
>
> vvar is 4
>
> =============
>
> Shall
> compare thee
> to a
> summer's day?
>
> vvar is 2
>
> ------------------------------------------------------------------
>
> By what thinking does the piping of a function's output thru grep cancel the assignment to the variable?  Do we really want that?

Surely by now you know how pipes work? One process has to run on
either side of the pipe, only one of them can be your current shell
(the one on the left is not it).

-- 
Mikael Magnusson

Re: piping surprise

[Ray Andrews]

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



On 2024-04-03 08:00, Mikael Magnusson wrote:
> Surely by now you know how pipes work? One process has to run on
> either side of the pipe, only one of them can be your current shell
> (the one on the left is not it).
Ah!  Yes, of course, there's a subshell.  It's easy to forget -- one of 
those 'invisible' things.  But do I recall ... yes, I believe Bart had a 
solution to that.  Anyway for now that's very clear, thanks.

BTW

> Keep your sexism to yourself, although in this case you're just
insulting yourself anyway.


I was being self-deprecating. I was trying to leave the 'gender' issue 
behind but on a lighthearted note. Never again.

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

Re: piping surprise

[Bart Schaefer]

On Wed, Apr 3, 2024 at 11:49 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> I believe Bart had a solution to that.

I can't think what you're referring to, but in the realm of the baroque ...

typeset -gi Pnum
alias -g '|'='> ${TMPPREFIX}pipe$$.$((++Pnum)) ; < ${TMPPREFIX}pipe$$.$((Pnum))'

This uses global aliasing to replace the '|' token with I/O
redirection through a (relatively) uniquely named temporary file.
Only works if the left side actually finishes writing so that the
right side can start reading.

However, there's a bug (?) in that if you chain together several
commands this way, only the first $((++Pnum)) actually increments the
parameter, so all the commands end up with the same file names.  E.g.

echo foo | tr a-z A-Z | cat

just prints "foo".  You can see this by writing it all out and
inserting an extra "echo":

echo PIPE > pipe.$((++Pnum)); echo $Pnum;\
 < pipe.$((Pnum)) cat > pipe.$((++Pnum)); echo $Pnum ; < pipe.$((Pnum)) cat

This will echo the same number twice, where it should echo consecutive
numbers.  This only happens if the autoincrement appears in a
redirection.

Re: piping surprise

[Ray Andrews]

On 2024-04-05 13:32, Bart Schaefer wrote:
> On Wed, Apr 3, 2024 at 11:49 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>> I believe Bart had a solution to that.
> I can't think what you're referring to, but in the realm of the baroque ...
It was a few years ago.  I'd plum forgotten to the point where I was 
mystified when the above happened because I've not thought about it 
since.  But I do remember that Roman was running all sorts of 
interesting speed tests.  I wish we could search the archives, I'd go 
looking for it.  I do remember making a typical comment to the effect 
that there's nothing intuitive about this subshell business but it turns 
out that there are deep reasons for it just the same.

func  | ...

... I sorta expect func to do whatever it does, even if the *output* is 
piped into a subshell.  In the above, I'm expecting my variable to be 
modified, pipe or  no pipe since the intention of the pipe would seem to 
be to modify the output and -- I might have thought -- that's all.


> typeset -gi Pnum
> alias -g '|'='> ${TMPPREFIX}pipe$$.$((++Pnum)) ; < ${TMPPREFIX}pipe$$.$((Pnum))'
Not for thumb-suckers like myself!

Re: piping surprise

[Lawrence Velázquez]

On Fri, Apr 5, 2024, at 4:32 PM, Bart Schaefer wrote:
> However, there's a bug (?) in that if you chain together several
> commands this way, only the first $((++Pnum)) actually increments the
> parameter, so all the commands end up with the same file names.  E.g.
>
> echo foo | tr a-z A-Z | cat
>
> just prints "foo".

And sometimes the parameter is not incremented at all:

	% (echo foo) | tr a-z A-Z | cat
	zsh: no such file or directory: /tmp/zshpipe39158.0
	zsh: no such file or directory: /tmp/zshpipe39158.0
	% cat <<<foo | tr a-z A-Z | cat
	zsh: no such file or directory: /tmp/zshpipe39158.0
	zsh: no such file or directory: /tmp/zshpipe39158.0
	% typeset -p Pnum
	typeset -i Pnum=0

But:

	% echo foo | { tr a-z A-Z } | cat
	FOO
	% typeset -p Pnum
	typeset -i Pnum=2

-- 
vq