[Toybox] [PATCH] pidof.test: block on sleep rather than read.

[scsijon]

On 24/01/20 18:17, toybox-request at lists.landley.net wrote:

> ------------------------------
> 
> Message: 2
> Date: Fri, 24 Jan 2020 00:48:58 -0600
> From: Rob Landley <rob at landley.net>
> To: enh <enh at google.com>, toybox <toybox at lists.landley.net>
> Subject: Re: [Toybox] [PATCH] pidof.test: block on sleep rather than
> 	read.
> Message-ID: <ad0b5641-585e-f1dd-c9af-a1c6ad619295 at landley.net>
> Content-Type: text/plain; charset=utf-8
> 
> On 1/23/20 6:24 PM, enh via Toybox wrote:
>> okay, i can reproduce this locally now: just run the test via adb
>> (without -t to allocate a pty). my own script conspired against me
>> here by adding -t to adb if `tty -s`, so locally i was always running
>> with a pty where you _can_ do a blocking read on stdout. but with just
>> regular adb you're talking to a socket and see these failures.
>>
>> i've attached a new version of the patch with a less vague and more
>> convinced checkin comment (but the same fix)...
> 
> The problem is we came to this fix because of a previous issue this reintroduces.
> 
> Maybe we should define stdin as "always there, reading from it will block", and
> make the environment we run the tests from reliably provide that? I've been
> meaning to make the tests run in a subshell anyway. "cat | source hello.sh" is
> kind of hilarously bad but shouldn't break anything (locals and functions would
> still be present in hello.sh without explicitly exporting them)...
> 
> Except cat still depends on the inherited stdin being there. Grr. I think I want
> some sort of "COMMAND | true" where when true exits COMMAND does, but not
> before? But I don't want to have to write a new C program (or toybox command)
> for this?
> 
> I've gotta be missing something obvious... How about:
> 
>    cat >(echo hello; read i; echo $i)
> 
> That seems to have read block, but... no, it's still wrong:
> 
>    $ cat >(echo hello)
>    hello
> 
and i'm getting a cursor on the next line, it's visable but doesn't do 
anything, plus a message telling me I have a running process still 
awaiting an input from me??? just to confuse things, sorry.

> It hangs, don't get my cursor back. Grrr. (echo exiting should close the pipe!
> Is this because nobody consumed the hello output? The pipe is going the WRONG
> WAY, I'd halfway expect the read to fail but blocking past close I did not
> expect...)
> 
> This is hard. :(
> 
> Rob

scsijon