On Sat, May 11, 2024 at 3:12 AM Yi-Yo Chiang via Toybox <toybox@lists.landley.net> wrote: > > > > On Sat, May 11, 2024 at 1:30 AM Rob Landley <r...@landley.net> wrote: >> >> What's your use case triggering this patch? Because without that, I go off on >> various design tangents, as seen below: > > > I just wanted some tool to communicate with a pty or socket node on android. > 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) > Since socat nor minicom is available on Android, I'm just using `stty raw > -echo && nc -f` to "talk" to my pty.
you know there's a _microcom_ though, right? (there's even a symlink in /system/bin.) > Why didn't I use <> redirector? Because I wasn't aware of that feature before > reading this mail... > Let me fiddle with it a bit: > > cat <>/dev/pts/0 > > Shows the pts output, but my input doesn't get passed back > cat <>/dev/pts/0 >&0 2>&0 > > 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. > > Seems <> doesn't sate my need, or I'm still using it wrong? > 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... > > cat /dev/pts/0 & stty raw isig -echo && cat >/dev/pts/0 > > This actually works and behave similarly enough to `stty raw -echo && nc > > -f` for me. > > (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) > >> >> >> On 5/10/24 06:09, Yi-Yo Chiang via Toybox wrote: >> > Hi, >> > The -f option for netcat doesn't seem to be doing anything right now. >> >> I should have a test for that, but to be honest I came up with netcat -f >> back in >> busybox (commit 1cca9484db69 says 2006) before I knew about bash's <> >> redirector >> to open a file for both reading _and_ writing (or had bash not added it >> yet?), >> meaning the example in that commit probably _should_ have been stty 115200 -F >> /dev/ttyS0 && stty raw -echo -ctlecho && cat <>/dev/ttyS0 >&0 2>&0 >> >> (I should NOT ask Chet for "{0-2}<>/dev/ttyS0" syntax operating on a >> filehandle >> range. I should not do it. That would be... I dunno, rude? I mean in theory >> I'd >> just want him to fix the existing {1..2} syntax to do one open() and then >> dup() >> redirects instead of opening the device multiple times, which was the initial >> problem because reopening the /dev node instead of dup() an existing >> filehandle >> to it either gave -EBUSY or hardware reset the UART depending on the >> underlying >> driver, and the reason chet would give me a LOOK if I asked is >> {brace,expansion} >> is resolved _before_ variable expansion and redirection, so it literally >> turns >> INTO 3 arguments with different numbers and thus three separate open() calls >> to >> the char device, and making it do something else is basically a layering >> violation...) >> >> Ahem. Sorry. Tangent. >> >> It's possible netcat -ft makes it still useful, but A) that implies there >> should >> be some sort of tty wrapper in the nice/taskset/time/chroot/nohup mold, B) I >> think -t is currently broken because I needed to rewrite it to add nommu >> support >> (decompose forkpty() into the underlying openpty() and login_tty() calls >> around >> the vfork() instead of fork()) and just commented it out and put it on the >> todo >> list... >> >> The original theory was -f should fall through to the "else" case on line >> 191, >> and thus naturally inherit any other applicable options. Which is hard to >> see in >> my current tree because with a bunch of half-finished work in it: >> >> $ git diff toys/*/netcat.c | diffstat >> netcat.c | 62 >> +++++++++++++++++++++++++++++++++++++++++++++++++------------- >> 1 file changed, 49 insertions(+), 13 deletions(-) >> >> Sorry for falling behind... >> >> > It is >> > missing a call to pollinate() after opening the specified device file. >> > The patch adds back that line of pollinate(). >> >> Which makes it not work with running commands (ala -f should work like -l). > > > yeah like you said it should had fall through and be like -l. > However digging the git history the fall through line got removed here > https://github.com/landley/toybox/commit/67bf48c1cb3ed55249c27e6f02f5c938b20e027d > which is unintentional I think? > >> >> >> > Also make sure that the timeout handler is not armed for -f mode as -f >> > shouldn't >> > timeout. File open() should just succeed or fail immediately. >> >> Why shouldn't -f timeout? Various /dev nodes take a while to open, automount >> behind the scenes... Is there a downside to leaving that part as is? (Other >> than >> the new case you added not alarm(0) disarming it?) > > > 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. > Please ignore my claim about moving the signal handler lines. Yes I think > after open() succeeded then alarm(0) to disarm is good. > > >> >> >> Rob > > _______________________________________________ > Toybox mailing list > Toybox@lists.landley.net > http://lists.landley.net/listinfo.cgi/toybox-landley.net _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net