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