<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 16, 2024 at 1:12 AM enh <<a href="mailto:enh@google.com" target="_blank">enh@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">On Sat, May 11, 2024 at 3:12 AM Yi-Yo Chiang via Toybox<br>
<<a href="mailto:toybox@lists.landley.net" target="_blank">toybox@lists.landley.net</a>> wrote:<br>
><br>
><br>
><br>
> 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>
>><br>
>> What's your use case triggering this patch? Because without that, I go off on<br>
>> various design tangents, as seen below:<br>
><br>
><br>
> I just wanted some tool to communicate with a pty or socket node on android.<br>
> 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)<br>
> Since socat nor minicom is available on Android, I'm just using `stty raw -echo && nc -f` to "talk" to my pty.<br>
<br>
you know there's a _microcom_ though, right? (there's even a symlink<br>
in /system/bin.)<br></blockquote><div><br></div><div>Regretfully no... not until now. Just tried it and I think it perfectly suits my need =)</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>
> Why didn't I use <> redirector? Because I wasn't aware of that feature before reading this mail...<br>
> Let me fiddle with it a bit:<br>
><br>
> cat <>/dev/pts/0<br>
> > Shows the pts output, but my input doesn't get passed back<br>
> cat <>/dev/pts/0 >&0 2>&0<br>
> > 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.<br>
><br>
> Seems <> doesn't sate my need, or I'm still using it wrong?<br>
> 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...<br>
><br>
> cat /dev/pts/0 & stty raw isig -echo && cat >/dev/pts/0<br>
> > This actually works and behave similarly enough to `stty raw -echo && nc -f` for me.<br>
><br>
> (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)<br>
><br>
>><br>
>><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>
><br>
><br>
> yeah like you said it should had fall through and be like -l.<br>
> However digging the git history the fall through line got removed here <a href="https://github.com/landley/toybox/commit/67bf48c1cb3ed55249c27e6f02f5c938b20e027d" rel="noreferrer" target="_blank">https://github.com/landley/toybox/commit/67bf48c1cb3ed55249c27e6f02f5c938b20e027d</a><br>
> which is unintentional I think?<br>
><br>
>><br>
>><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>
><br>
><br>
> 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.<br>
> Please ignore my claim about moving the signal handler lines. Yes I think after open() succeeded then alarm(0) to disarm is good.<br>
><br>
><br>
>><br>
>><br>
>> Rob<br>
><br>
> _______________________________________________<br>
> Toybox mailing list<br>
> <a href="mailto:Toybox@lists.landley.net" target="_blank">Toybox@lists.landley.net</a><br>
> <a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" rel="noreferrer" target="_blank">http://lists.landley.net/listinfo.cgi/toybox-landley.net</a><br>
</blockquote></div></div>