[oech3]

Closes #15803 .
Note that this causes large performance drop:

> yes|tee /dev/null|pv>/dev/null
 133GiB 0:00:02 [66.8GiB/s]
> yes|tee-memfd /dev/null|pv>/dev/null
17.7GiB 0:00:02 [8.86GiB/s]
> yes|tee-rw /dev/null|pv>/dev/null
10.1GiB 0:00:02 [5.09GiB/s]

[github-actions]

GNU testsuite comparison:

GNU test failed: tests/tee/tee. tests/tee/tee is passing on 'main'. Maybe you have to rebase?

[oech3]

Passing tee.sh now.

[oech3]

I think we should keep using tee(2) for stream input as it is always reliable (and consider that it is provider's bug if input can be changed diring copy): #15894 .

[xtqqczze]

yes|tee /dev/null|pv>/dev/null

what performance result does gnu-tee give?

[oech3]

Why? but

$ yes | pv>/dev/null
 105GiB 0:00:01 [ 105GiB/s]
$ yes | tee-memfd | pv>/dev/null
78.6GiB 0:00:01 [78.6GiB/s]
$ yes | '/home/a/bin/gnu-git/tee' /dev/null | pv>/dev/null
2.94GiB 0:00:01 [2.94GiB/s] 
$ yes | tee-rw /dev/null | pv>/dev/null
4.95GiB 0:00:01 [4.95GiB/s]
$ yes | tee-memfd /dev/null | pv>/dev/null
8.80GiB 0:00:01 [8.80GiB/s]

Note that pv must be latest version to let pv use 1 MiB pipe, and yes should be uutils version since it is faster tham GNU.

I'm sad to lost because of we need to doubt source, but it would be difficult to make tee-memfd an overhead of pipeline on the real world until people started using memfd + mmap at many utils.