On Thu, May 16, 2024 at 1:12 AM enh <e...@google.com> wrote: > 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.) >
Regretfully no... not until now. Just tried it and I think it perfectly suits my need =) > > > 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