On 6/7/21 11:14 AM, enh wrote: > On Fri, Jun 4, 2021 at 10:54 PM Rob Landley <[email protected] > <mailto:[email protected]>> wrote: > I've always been slightly unclear on what getty.c _does_ and why it's > separate > from login.c. (Is it related to stty?) > > > in case i never sent the response to the list, TL;DR "yeah"... > > [i'm told that] if you're using real serial ports, you still need the baud > rate > setting features. if you're using real serial cables in an electrically noisy > environment, you have another local getty patch that i honestly haven't > understood well enough to even try to work out whether it makes any sense to > upstream :-(
I fairly regularly use stty with actual serial ports, so I'm familiar with that part. That's why I brought up "maybe this still useful bit is related"... The local getty patch is probably reading and ignoring data that comes in immediately after bringing the serial port up and changing the speed? (Because you can get a little static when the hardware powers on, and especially when you plug/unplug actual serial cables. A common hack back in the day was to wait for DTR to assert and just drop data that comes in when it isn't.) What I don't understand is why it isn't stty+login. Or if you're going to build this functionality _into_ something, why it isn't directly in login? A glue tool like getty sending out /etc/issue is just weird. Long long ago modems dialed in at various rates and actually set the serial port to the rate of each call rather than keeping it fixed at the highest supported one and buffering the data. (Which is odd when you have cts/rts and such? It has to buffer anyway? But they wanted cheap...) But I had a 1200 baud modem on the commodore 64 that kept the serial connection at 1200bps when connecting at 300. (In part because it had no way to signal the C64 what speed it the other end had connected at.) By the time v.42bis was adopted in 1990 (https://ieeexplore.ieee.org/document/403565) you HAD to set the serial port to a fixed rate faster than the hardware could actually GO (data compression!) and keep it there, and then the modem would buffer and handle the flow control for the actual data going through. (And before the ccitt standards the Hayes HST modems were doing something similar with a different wire protocol.) And this was backwards compatible all the way back to 300 baud (the new modems spoke the old protocols, but in the buffered way), so you haven't NEEDed what getty does even for "modem-over-actual-land-phone-line" for 31 years now? > aiui they were sometimes seeing XOFF sent to init, causing boot to hang. I always disable xon/xoff flow control. In-band signaling for flow control is just sad. (The Joe editor on SunOS had to handle the fact that "ctrl-K Ctrl-S" to save a cut and paste buffer was a common wordstar key binding, but Ctrl-S stopped terminal output until it got a Ctrl-Q. Wordstar originated on CP/M and took over the DOS world until Windows monopoly leveraged it out, and Unix wanted to keep the ASR-33 teletype happy because it was durable enough and simple enough to take apart and clean/oil to be available cheap secondhand...) The Apple II and Vic 20 had builtin keyboards and video display output, and IBM did an Ascii keyboard on a mass produced machine capable of running unix (hence xenix) in 1981 and had finalized the layout by the PC/AT in 1984. The Stanford University Network boxes that Sun commercialized had keyboards and displays. All the AIX hardware did too. x11 standardized GUI plumbing in 1987 (which made the NeWS guys with their competing postcript-based implementation sad; they went on to create Java at Sun, http://www.blinkenlights.com/classiccmp/javaorigin.html). I look askance at the continued default deployment any technology that last had good reason to exist before the birth of a sitting US senator. > (although i understand that XOFF/XON is useful in theory, i've been disabling > it > since the early 1990s because i've haven't deliberately used it since the > early > 1980s when computers were still slow enough for human reaction times to be > somewhat meaningful there.) In theory this is what the "scroll lock" key was for on the 1981 IBM PC keyboard. In practice text output by programs running locally scrolled by too fast for it to matter, and third party modem control programs didn't reliably wire it up to rts/cts. (Because it didn't start with an LED so you couldn't tell when it was pressed, and leaving scroll lock on and then calling tech support because you got no output was most cost effectively fixed by disabling scroll lock support.) > It'd be great if somebody could tackle stdbuf,... > (i thought we'd already argued that this means you'll have the glibc-provided > binary if you're using glibc, which means this doesn't make sense for toybox?) Good point. It was added to the roadmap at the request of the tizen people ages ago, but I'm happy to yank it out again now that I know more about it. I have no idea what the status of Tizen is, I hear conflicting things: https://www.theverge.com/2021/5/18/22440483/samsung-smartwatch-google-wearos-tizen-watch https://www.engadget.com/samsung-tizen-smart-tvs-195125512.html > > http://lists.landley.net/pipermail/toybox-landley.net/2020-December/012158.html > > Rich Felker said he had a simple way to do it, but we've never sat down > to have > him explain it to me. > > > (i'd be curious to hear that, because every implementation i'm aware of -- and > the Unicode standard --literally end up with a huge table *and* hard-coded > special cases in the code. the closest i've come to "clever" with this was to > hoist the hard-coded special cases out and have a separate "easy case" copy of > the loop. but that's only a run-time "simplification", and makes the > implementation strictly larger.) > > but more than that, i'd still like to hear an argument that trying to be > clever > here makes any _sense_ :-) I did cc: Rich on the email. :) > i'd ask for a single real-world example where someone's actually using this, > but > since BSD and GNU and Plan 9 trs don't, that doesn't exist. > > (and this ignores the question of "sure, but aren't we going to harm more > ASCII-only 'kernel build' users by accidentally taking their locale into > account > than we are going to help imaginary Turkish AT&T lawyers still using the Unix > command line for writing their patent applications in 2021", to which i'm > pretty > sure the answer is "yes, the only net result of implementing this would be > that > we'd need to tell a bunch of people to set their locale to "C" for their > builds...".) > > fwiw, getting back to something you said earlier, i think *this* is where one > true awk "doesn't support utf-8" --- "convert Turkish input to > upper/lowercase" > _ought_ to be something that awk can do that tr can't (because tr is all about > characters/bytes, but awk is all about strings), but one true awk can't do it > either. perl and python can. realistically i think anyone who falls into the > "no, i really do want to deal with all the weirdness of human scripts [in the > Cyrillic/Hangeul sense of the word]" category (a) should use and (b) is > already > using python anyway. even the kernel and toybox use perl or C where awk would > do. "it's POSIX", sure, but "no-one who wasn't doing this kind of thing in the > 1990s has ever used it, and those of us who were don't want to write things > that > only we can maintain". I basically want to hear Rich's idea for utf8 support in tr before doing the non-utf8 one. > your non-POSIX cut(1) extension covers 80% of the in-the-wild use of awk > anyway > :-) if you still talk to any of the busybox folks, we should suggest they copy > that I hath poked. If they dowanna but would be interested in merging an external contribution, I can probably whip up a patch... > --- it would be nice for it to be a de facto standard so we can get it into > POSIX sometime around the 2040s... (and have made lives better for the folks > who > don't care about standards and just want to "get things done" in the > intervening > decades!) Indeed. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
