Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.unix.shell
Subject: Re: Different variable assignments
Date: Sat, 12 Oct 2024 13:08:48 +0200
Organization: A noiseless patient Spider
Lines: 81
Message-ID: <vedlc2$4vi6$1@dont-email.me>
References: <lmt83dFsvbvU3@mid.individual.net>
 <lmt90sFr1idU1@mid.individual.net> <lmta1jFsvc0U1@mid.individual.net>
 <vecl6n$d0r$1@dont-email.me> <lmuniuF632tU1@mid.individual.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 12 Oct 2024 13:08:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1bb6ba8d9a0743d0ec7c52c2bf248c5a";
	logging-data="163398"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+KULTGmSz+aZPXdrL3yVpZ"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:czeosVGXXyffePCAQcz7bTeh1T4=
In-Reply-To: <lmuniuF632tU1@mid.individual.net>
X-Enigmail-Draft-Status: N1110
Bytes: 4274

On 12.10.2024 09:42, Frank Winkler wrote:
> On 12.10.2024 03:59, Janis Papanagnou wrote:
> 
>  >It depends on your shell. If you choose Kornshell you won't have that
>  >issue and can write it as you've done with the output as you'd expect.
>  >
>  >$ uname -a | read var
>  >$ echo "$var"
>  >Linux [...snip...]
>  >
>  >The reason is that the last command in a pipeline will (in Kornshell)
>  >be executed in the "current" shell context.
> 
> Interesting hint! I wasn't aware that there are such differences between
> the shells.

Yes, it's a subtle difference, but an important one; many shell users
wondered about the behavior of other shells, and you need to know the
internal information about subprocesses used in pipes to understand
why it doesn't work (in other shells), or why it does in ksh.

> And indeed, some simple tests seem to work in an interactive
> ksh.

You can rely on it with any official ksh (since ksh88) and branches of
them. (But don't count on it if you're using some inferior ksh clone.)

> 
> Let's see the whole story. For historical reasons, I'm actually using
> ksh for almost all scripts instead of bash for interactive use - not
> knowing about the fact above.

From your description below I'm not sure you still have a question or
whether you're just describing what you intended to do and are fine
with ksh's pipeline behavior. (Specifically I'm unsure about the 'B'
and what you mean by "sub-command B" in your example(s).)

If something is still not working for you, please clarify.

> 
> There, I run command A which is producing output and which is calling
> sub-command B, also producing output. This works fine.
> What I want to achieve is to grab some parts of the output and store it
> in a variable but without changing the output on the screen.
> 
> So I tried something like
> 
> tty=`tty`
> A | tee $tty | ... | read var

$ man tty
tty - print the file name of the terminal connected to standard input

The 'tty' command in your 'tee' pipeline command has no tty attached;
it reads from the pipe. That's why   A | tee $(tty) | ... | read var
doesn't work as you expected. You have to grab the tty information
outside the pipeline (as you've experienced).

Janis

> 
> "tee `tty`" inside the command fails, so I do it outside. The output of
> A is still there but B's is gone (because B doesn't know anything about
> the "tee"?) and the whole thing doesn't seem to be still working. $var
> is empty, though this is a ksh script and the stuff behind "tee" is also
> working.
> To my understanding, the default B can be changed with an option but
> when I set it to "B | tee $tty", there's still no output.
> 
> AFAIR, "var=`...`" works better but as the primary job is the command
> itself and the variable is just a spin-off product, I'd prefer to do the
> assignment at the end. I believe it looks better then ;) ...
> 
> Probably it would also be feasible with some temp files but I try to
> avoid them wherever possible.
> 
> Happy week-end!
> 
>     fw
>