<div dir="ltr">This is the updated patch.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 11, 2024 at 3:11 PM Yi-Yo Chiang <<a href="mailto:yochiang@google.com">yochiang@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 11, 2024 at 1:30 AM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What's your use case triggering this patch? Because without that, I go off on<br>
various design tangents, as seen below:<br></blockquote><div><br></div><div>I just wanted some tool to communicate with a pty or socket node on android.</div><div>Wanted a program to be able to send/recv towards a duplex data stream. (more precisely I want a command that does exactly what pollinate() does)</div><div>Since socat nor minicom is available on Android, I'm just using `stty raw -echo && nc -f` to "talk" to my pty.</div><div><br></div><div>Why didn't I use <> redirector? Because I wasn't aware of that feature before reading this mail...</div><div>Let me fiddle with it a bit:</div><div><br></div><div>cat <>/dev/pts/0</div><div>> Shows the pts output, but my input doesn't get passed back</div><div>cat <>/dev/pts/0 >&0 2>&0</div><div>> Shows nothing on my terminal. All the output of the pts node got uno reversed back to it. The ptm side just sees all their data got echoed back.</div><div><br></div><div>Seems <> doesn't sate my need, or I'm still using it wrong?</div><div>Anyway actually what I need could just be as simple as starting 2 cat processes as bidirection data stream. Though this wouldn't be a true duplex...</div><div><br></div><div>cat /dev/pts/0 & stty raw isig -echo && cat >/dev/pts/0<br></div><div>> This actually works and behave similarly enough to `stty raw -echo && nc -f` for me.</div><div><br></div><div>(but it's still much more convenient if I can do all that (double `cat` and background process handling) with a single shorter `nc -f` command)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On 5/10/24 06:09, Yi-Yo Chiang via Toybox wrote:<br>
> Hi,<br>
> The -f option for netcat doesn't seem to be doing anything right now.<br>
<br>
I should have a test for that, but to be honest I came up with netcat -f back in<br>
busybox (commit 1cca9484db69 says 2006) before I knew about bash's <> redirector<br>
to open a file for both reading _and_ writing (or had bash not added it yet?),<br>
meaning the example in that commit probably _should_ have been stty 115200 -F<br>
/dev/ttyS0 && stty raw -echo -ctlecho && cat <>/dev/ttyS0 >&0 2>&0<br>
<br>
(I should NOT ask Chet for "{0-2}<>/dev/ttyS0" syntax operating on a filehandle<br>
range. I should not do it. That would be... I dunno, rude? I mean in theory I'd<br>
just want him to fix the existing {1..2} syntax to do one open() and then dup()<br>
redirects instead of opening the device multiple times, which was the initial<br>
problem because reopening the /dev node instead of dup() an existing filehandle<br>
to it either gave -EBUSY or hardware reset the UART depending on the underlying<br>
driver, and the reason chet would give me a LOOK if I asked is {brace,expansion}<br>
is resolved _before_ variable expansion and redirection, so it literally turns<br>
INTO 3 arguments with different numbers and thus three separate open() calls to<br>
the char device, and making it do something else is basically a layering<br>
violation...)<br>
<br>
Ahem. Sorry. Tangent.<br>
<br>
It's possible netcat -ft makes it still useful, but A) that implies there should<br>
be some sort of tty wrapper in the nice/taskset/time/chroot/nohup mold, B) I<br>
think -t is currently broken because I needed to rewrite it to add nommu support<br>
(decompose forkpty() into the underlying openpty() and login_tty() calls around<br>
the vfork() instead of fork()) and just commented it out and put it on the todo<br>
list...<br>
<br>
The original theory was -f should fall through to the "else" case on line 191,<br>
and thus naturally inherit any other applicable options. Which is hard to see in<br>
my current tree because with a bunch of half-finished work in it:<br>
<br>
$ git diff toys/*/netcat.c | diffstat<br>
 netcat.c |   62 +++++++++++++++++++++++++++++++++++++++++++++++++-------------<br>
 1 file changed, 49 insertions(+), 13 deletions(-)<br>
<br>
Sorry for falling behind...<br>
<br>
> It is<br>
> missing a call to pollinate() after opening the specified device file.<br>
> The patch adds back that line of pollinate().<br>
<br>
Which makes it not work with running commands (ala -f should work like -l).<br></blockquote><div><br></div><div>yeah like you said it should had fall through and be like -l. </div><div>However digging the git history the fall through line got removed here <a href="https://github.com/landley/toybox/commit/67bf48c1cb3ed55249c27e6f02f5c938b20e027d" target="_blank">https://github.com/landley/toybox/commit/67bf48c1cb3ed55249c27e6f02f5c938b20e027d</a></div><div>which is unintentional I think?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Also make sure that the timeout handler is not armed for -f mode as -f shouldn't<br>
> timeout. File open() should just succeed or fail immediately.<br>
<br>
Why shouldn't -f timeout? Various /dev nodes take a while to open, automount<br>
behind the scenes... Is there a downside to leaving that part as is? (Other than<br>
the new case you added not alarm(0) disarming it?)<br></blockquote><div><br></div><div>I was wrong. What you pointed out is correct. Reading `man open` again it also clearly says that opening a fifo could block until the other end is open-ed also.</div><div>Please ignore my claim about moving the signal handler lines. Yes I think after open() succeeded then alarm(0) to disarm is good.</div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Rob<br>
</blockquote></div></div>
</blockquote></div>