sh - function to pass data stdin -> stdout unchanged

[Zucca]

I have this function, which takes tsv formatted stdin:

[szatox]

Can you pass the second command either as a parameter to your function or though env, and then call it from within your function either with pipe or directly, depending on which branch you hit?

Actually, do you even need a function for just a single test with one-line paths?
_________________
Make Computing Fun Again

[pingtoo]

Couldn't you use read and echo to replace cat?

like while read line; do
echo $line
done

[Zucca]

@pingtoo, I think cat performs better than echo inside a loop.

@szatox, I didn't quite follow. The point of this function it to recognize if the user ran the script inside a pipeline, so it won't try to columnize the output, but keep the original tsv formatting for easier parsing.
EDIT: My wording in the first post was maybe misleading. EDIT2: Edited the first post.
_________________
..: Zucca :..

[Hu]

[pingtoo]

[Zucca]

[szatox]

Ah, ok, had a brain fart here. After a second read I get what what you want.

[pingtoo]

I would bet my version of using "read" and "echo" together with 'IFS=' is just efficient as cat in a pipe line. May be the while loop can be remove because the "read" and "echo" happen in middle of pipe line anyway.

if I had Dtrace setup than I can trace for syscall in that context compare to "cat" in the middle of pipe.

I am thinking my version have one less cost for invoke a external program. since "read" and "echo" are universal in every shell.

However I admit if the invoke logic can be change to detect pipe condition prior to invoke tsv_column that "cat" is more efficient than read/echo loop.

[Zucca]

[Zucca]

[eschwartz]

"cat" is an unbelievably efficient program that is extremely good at doing what it does. People have written blog posts about how they tried to rewrite cat in Rust for the fearless concurrency and blazing fast speed, and were shocked to discover that rust was in fact extremely slow and it's because they incorrectly thought all you need to do is "just read data from one end and print it on the other end". It turns out that smart programmers who have spent decades optimizing a program have a few tricks up their sleeves and it has nothing to do with programming languages (yes, bash is a programming language, and bash does NOT provide primitives for the functionality the GNU cat developers have relied on here).

You will also find that "cat" is used all over the place as basically the canonical way to implement a pipeline filter that sometimes does something, but in the "cat" case, does nothing. There is a reason for this. The only faster thing to do would be to complexify a different part of your program by introducing branching that determines whether or not to invoke a pipeline filter.

[pingtoo]

[Hu]

The shown pipeline puts everything in a single shell, but if the | tsv_column part is buried in a script, and the potentially present | some_other_command isn't, then that's not the same pipeline as shown.

You can play games with exec to save aside and restore stdout, and if you commit to using Bash, you can use process substitution to conditionally insert your final stage. I think if you want non-Bash Bourne, then you will need to follow szatox's suggestion.

[Zucca]

Thanks guys.
I'll see the alternatives, as "skipping cat" seems almost impossible in terms of having function just pass the data forward.

My problem is that there are a lot of functions that output tsv (or NUL separated (nsv?)) data.
It has been easy (to write, that is) just to construct the pipeline with this tsv_column at the end.
After some time I decided to go trough the scripts and see if I could improve any places where I had left TODO or BUG comment. This useless use of cat was one.
_________________
..: Zucca :..