[not braindead issue] rish mixes up stdout and stderr

[haarp]

(Seriously, what is going on in this issue tracker?!)

I have an actual bug report in relation to Shizuku 13.5.4. Rish is very useful, but it has one flaw: It conflates stdout and stderr. As I'm trying to do some backups over the network over rish, this is a major problem.

Simple test case: rish -c 'echo stderr >&2' >/dev/null
This should print stderr. But it prints nothing, because the echo that ends up in stderr will end up on stdout.

Hope this can be fixed somehow. Thanks a lot!

[haarp]

Actually, this also prints nothing:
rish -c 'echo stderr >&2' 2>/dev/null
so it really seems like rish is treating both streams as one, and treats them as the same. Never seen such behavior before.

[haarp]

Ok, whatevre is going on with stdout/stderr, it's very confusing and I can't figure out what happens to it. It seems rish can't be trusted to properly transfer these to the caller. This breaks tools like tar or rsync.

[haarp]

I'm starting to figure out what's happening.

Bug 1: If either stdout or stderr of the rish process are redirected or piped in any way, then rish closes the stderr file descriptor on the process it spawns.

$ rish -c 'echo stdout; echo stderr >&2'
stdout
stderr
$ rish -c 'echo stdout; echo stderr >&2' | cat
stdout
$ rish -c 'echo stdout; echo stderr >&2' 2>stderr
stdout
$ cat stderr
$

Bug 2: Sometimes stderr is not closed, but stdout bleeds into stderr! This reproduces sometimes. Race condition?

$ rish -c 'echo stdout; echo stderr >&2' 2>stderr
$ cat stderr
stdout
$ #wtf?!

Bug 3: Related to bug 1, processes inside rish that write a lot into stderr will eventually stall inside n_tty_write or pipe_write due to the closed file descriptor. This causes programs like tar to freeze for seemingly no reason.

$ rish -c '/system/bin/tar vc /storage/emulated/0/Android/data' | pv -n -b -X
330560
330560
330560
# stalled
^C
# now without `v`:
rish -c '/system/bin/tar c /storage/emulated/0/Android/data' | pv -n -b -X
131105280
239734272
$ # done