On Tue, Jun 8, 2021 at 11:54 PM Rob Landley <[email protected]> wrote:
> 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? i didn't entirely follow, but aiui it was something to do with a bios/bootloader that would suspend boot if it saw control characters, so the hack was basically "you can't have control characters in your username/password, so just ignore them until you've logged in". > (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. > yeah, it seemed like they'd be fine with a merger, but weren't exactly _excited_ about it because it would mean changing something that already works --- this is the kind of progress that helps the _next_ generation of users, not the existing users :-) > 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
