Why tail coreutil cannot work as its input is from tee
How come tail coreutil cannot work as its input is from tee $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tail -1 1 But : $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tee >(head -1) |tail -1 9 Please help explain
Re: Why tail coreutil cannot work as its input is from tee
if u d try echo .. | tee >( >/dev/null ) | tail -1 i havent tested, but im trying to say, the stdout by head seems to be taken i mean heads stdout prioritizes im not sure.. ppl ( that know .. ) .. write about it :) -- Forwarded message - From: Budi Date: Mon, Sep 6, 2021, 09:38 Subject: Why tail coreutil cannot work as its input is from tee To: How come tail coreutil cannot work as its input is from tee $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tail -1 1 But : $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tee >(head -1) |tail -1 9 Please help explain
Re: Why tail coreutil cannot work as its input is from tee
On Mon, Sep 06, 2021 at 07:38:03AM +, Budi wrote: > How come tail coreutil cannot work as its input is from tee > > $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tail -1 > 1 > > But : > > $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tee >(head -1) |tail -1 > 9 > > Please help explain Not a bug. If you leave out the |tail -1', you will see that the output of head -1 gets appended to that of tee. -- Regards, Mike Jonkmans
Re: Why tail coreutil cannot work as its input is from tee
Because your last pipe will pipe BOTH output of `echo` AND `head` with delay due to fork, head output will comme after. try this: echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tee >(head -1 >&2) |tail -1 or echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tee >(head -1 >&2) >(tail -1 >&2) >/dev/null ... On Mon, Sep 06, 2021 at 07:38:03AM +, Budi wrote: > How come tail coreutil cannot work as its input is from tee > > $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tail -1 > 1 > > But : > > $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tee >(head -1) |tail -1 > 9 > > Please help explain > -- Félix Hauri -- http://www.f-hauri.ch
Re: Why tail coreutil cannot work as its input is from tee
On Mon, Sep 06, 2021 at 07:38:03AM +, Budi wrote: > How come tail coreutil cannot work as its input is from tee > > $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tail -1 > 1 > > But : > > $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tee >(head -1) |tail -1 > 9 > > Please help explain I don't see how this is a bug report against the bash shell. Note that the output from your pipeline is non-deterministic: $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tee >(head -1) | tail -1 1 $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tee >(head -1) | tail -1 9 This is on an OpenBSD system. This depends on whether tee has a chance of outputting the complete data from echo to its standard output first, before the head outputs its data. With GNU tools, I can't get the pipeline to output 1, but I know there's a chance it may eventually output 1 rather than 9. -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: ?maybe? RFE?... read -h ?
On Mon, Sep 06, 2021 at 08:41:33AM +0200, Alex fxmbsw7 Ratchev wrote: > btw in the help you pasted there is the -a arr in question Can you for the love of glob please STOP top-posting? > On Mon, Sep 6, 2021, 08:36 felix wrote: > > It would be nice if builtins intended to produce *answer* use more or less > > common switch like `printf -v` behaviour. > > > > usage: realpath [-a array] [-csv] pathname [pathname...] > > > > options: -a NAME assign the output to shell array NAME rather than > >display it on the standard output > >-c check whether or not each resolved path exists > >-s no output, exit status determines whether path is > > valid > >-v produce verbose output Felix's synopsis is not the real one. It's a proposal. The real one looks like this: unicorn:~$ enable -f /usr/lib/bash/realpath realpath unicorn:~$ help realpath realpath: realpath [-csv] pathname [pathname...] Display pathname in canonical form. Display the canonicalized version of each PATHNAME argument, resolving symbolic links. The -c option checks whether or not each resolved name exists. The -s option produces no output; the exit status determines the validity of each PATHNAME. The -v option produces verbose output. The exit status is 0 if each PATHNAME was resolved; non-zero otherwise. Since -v is already taken, the proposed modification used -a instead, I have no idea why the proposal tries to write the result into an array variable, though. That makes no sense to me.
Re: ?maybe? RFE?... read -h ?
thanks sorry ill try other mail clients somewhen.. i suppose he tries like me to save the cpu for speed measure 1k $( : ) .. i not but i suppose last time the nothingly difference was big On Mon, Sep 6, 2021, 14:11 Greg Wooledge wrote: > On Mon, Sep 06, 2021 at 08:41:33AM +0200, Alex fxmbsw7 Ratchev wrote: > > btw in the help you pasted there is the -a arr in question > > Can you for the love of glob please STOP top-posting? > > > On Mon, Sep 6, 2021, 08:36 felix wrote: > > > It would be nice if builtins intended to produce *answer* use more or > less > > > common switch like `printf -v` behaviour. > > > > > > usage: realpath [-a array] [-csv] pathname [pathname...] > > > > > > options: -a NAME assign the output to shell array NAME rather > than > > >display it on the standard output > > >-c check whether or not each resolved path exists > > >-s no output, exit status determines whether path > is > > > valid > > >-v produce verbose output > > Felix's synopsis is not the real one. It's a proposal. > > The real one looks like this: > > unicorn:~$ enable -f /usr/lib/bash/realpath realpath > unicorn:~$ help realpath > realpath: realpath [-csv] pathname [pathname...] > Display pathname in canonical form. > > Display the canonicalized version of each PATHNAME argument, resolving > symbolic links. The -c option checks whether or not each resolved name > exists. The -s option produces no output; the exit status determines > the > validity of each PATHNAME. The -v option produces verbose output. The > exit status is 0 if each PATHNAME was resolved; non-zero otherwise. > > Since -v is already taken, the proposed modification used -a instead, > > I have no idea why the proposal tries to write the result into an > array variable, though. That makes no sense to me. > >
Re: Why tail coreutil cannot work as its input is from tee
On Mon, Sep 06, 2021 at 07:38:03AM +, Budi wrote:
> How come tail coreutil cannot work as its input is from tee
>
> $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tail -1
> 1
>
> But :
>
> $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tee >(head -1) |tail -1
> 9
>
> Please help explain
It would be better if you explained what you actually want to do, so
that we can tell you a correct way to do it.
What you've got here is a race condition. Your pipeline has three
commands in it. The race condition is in the second command:
... | tee >(head -1) | ...
When the shell sets up this command, this is what happens:
1) Stdin is coming from an anonymous pipe already. Call this "the
input pipe".
2) A second anonymous pipe is created for the output, and stdout is
redirected to that pipe. Let's call this "the output pipe".
3) A background job is created to run "head -1". This background job
inherits stdout from its parent. Therefore, the output of the
"head -1" job will be the output pipe.
4) The stdout of tee is *also* the output pipe.
So, you have two processes both writing to the same output pipe: tee
and head. The actual result you see will depend on which one
finishes writing its output last. And also how the output is divided up
(i.e. whether the echo command writes it all in one atomic chunk, or
multiple chunks).
Your failing command is so abstract and "homework-y" that it's clearly
a !b9. Nobody can tell what it was meant to do. If you would please
tell us what you're *actually* trying to do, we could help you a lot more.
9. All examples given by the questioner will be broken, misleading,
wrong, incomplete, and/or not representative of the actual question.
My best guess about what you *thought* it would do is: print the first
and last lines of the input.
If you want to print the first and last lines of input, I would recommend
either sed or awk.
unicorn:~$ printf %s\\n {1..9} | sed -n -e 1p -e \$p
1
9
unicorn:~$ printf %s\\n {1..9} | awk 'NR==1 {print} END {print}'
1
9
If that's *not* what you want, then again, I implore you, please tell
us what you *do* want.
Re: ?maybe? RFE?... read -h ?
On Mon, Sep 06, 2021 at 08:11:20AM -0400, Greg Wooledge wrote: > The real one looks like this: > unicorn:~$ help realpath > realpath: realpath [-csv] pathname [pathname...] > Display pathname in canonical form. > > Display the canonicalized version of each PATHNAME argument, resolving > symbolic links. The -c option checks whether or not each resolved name > exists. The -s option produces no output; the exit status determines the > validity of each PATHNAME. The -v option produces verbose output. The > exit status is 0 if each PATHNAME was resolved; non-zero otherwise. > > Since -v is already taken, the proposed modification used -a instead, > > I have no idea why the proposal tries to write the result into an > array variable, though. That makes no sense to me. Because `realpath` accept more than one *pathname*. So if you pass many path entries to realpath as arguments, all answer could be stored into an array. realpath /bin/sh /usr/bin/X /bin/dash /usr/bin/Xorg -- Félix Hauri -- http://www.f-hauri.ch
Re: ?maybe? RFE?... read -h ?
On 2021/09/05 20:54, Lawrence Velázquez wrote: On Sun, Sep 5, 2021, at 11:11 PM, Dale R. Worley wrote: L A Walsh writes: I know how -h can detect a symlink, but I was wondering, is there a way for bash to know where the symlink points (without using an external program)? My understanding is that it has been convention to use the "readlink" program for a very long time, so there's never been much demand to add it to bash. ??? convention has nearly all of the builtins as local programs. Since 'read' (or "read -l") isn't a local program, what are you saying? Of course, looking at the options to readlink shows that there are several different meanings of "where a symlink points". Irk! I just wanted the raw data! (sigh), like 'ls-l' gives: # /bin/ls -l named.pid ... named.pid -> named.d/named.pid # /bin/ls -l named.d ... named.d -> ../lib/named/var/run/named Sure I could (and usually do when I need to) parse output of ls -l, but thats tedious and error prone. The distribution ships with a "realpath" loadable builtin, FWIW. I didn't know that... um, my bash isn't quite there yet: Ishtar:/> enable -f /opt/local/lib/bash/realpath realpath -bash: enable: cannot open shared object /opt/local/lib/bash/realpath: /opt/local/lib/bash/realpath: cannot open shared object file: No such file or directory Ishtar:/> whence realpath realpath is /usr/bin/realpath
Re: ?maybe? RFE?... read -h ?
On Mon, Sep 6, 2021, at 6:46 PM, L A Walsh wrote: > On 2021/09/05 20:54, Lawrence Velázquez wrote: > > The distribution ships with a "realpath" loadable builtin, FWIW. > > > > I didn't know that... um, my bash isn't quite there yet: > > Ishtar:/> enable -f /opt/local/lib/bash/realpath realpath > > -bash: enable: cannot open shared object /opt/local/lib/bash/realpath: > /opt/local/lib/bash/realpath: cannot open shared object file: No such > file or directory You have to adapt the path for your own installation (assuming your installation includes the loadables to begin with). -- vq
