This is specifically for the command-line and system tools stuff, including #nosh and #djbwares.
For anything else, including general computer programming, the non-politics account is @JdeBP and the politics account is @JdeBP. #senryu and #SlowLife tasks are at @JdeBP.
It's not even a hot take. It's actual history.
STEVIE came from the days when people were re-inventing Joy vi for other platforms and systems with (gasp!) arrow keys and console-paradigm I/O.
It was less than a decade until people were thinking that Joy vi could be improved and were actively trying to make things that were better.
Watcom vi, for another example, came out in the early 1990s and that had windows, and uses for function keys.
Digging into the talk page of the article on the FAT filesystem and Linux, one finds that, back in 2009, #Wikipedia people thought the same thing. (-:
https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/UMSDOS
It was past tense even then. Linux 2.6 had come out some 6 years beforehand.
Amusingly, the Linux Documentation Project has a UMSDOS how-to written in the present tense that has not been updated since 2001.
Indeed so. Linux had a filesystem type named umsdos that layered a raft of non-native semantics on top of the FAT on-disc data structures with the use of magic '--LINUX.---' files.
I think that we can safely say in the 2020s that, across the world of Windows NT, BSDs, Linux, et al., use of the FAT filesystem format has been relegated to edge cases like some boot volumes (e.g. the EFISP) and some data interchange, and isn't in general use for system volumes.
I suspect that this has changed over the years. Kay Sievers's original proposal in 2010 indeed had the active device as the last one. But Lennart Poettering writing in 2012, after things had settled down amongst the kernel developers, wrote that the active device was the first one. I vaguely remember inspecting the code that constructed the string to check, at the time. I'll try to remember to have another look.
I write a console(4) and a vt(4) manual page for #Linux, too, as there is a larger gap there, Linux doco not having a vt(4) page as #FreeBSD does.
http://jdebp.info/Softwares/nosh/guide/commands/linux-console.xml
http://jdebp.info/Softwares/nosh/guide/commands/linux-vt.xml
People have brought up the TOPS-20 command processor already.
Just for completeness, I'll mention DCL on VMS, which had long parameter names (e.g. /COPIES to PRINT and /FULL to DIRECTORY).
There's also MCR on VMS (and RSX), with HELLO and BYE for logging on and off.
Don't forget the whole "* commands" system on the BBC MIcro, either.
#VMS #CLI #TOPS20 #DCL #DIGITAL #retrocomputing #MCR #RSX #BBCMicro
My schools did not teach C or any language like it.
I learned about -- and #getopt from a combination of FidoNet, Usenet, and a 1985 book on Unix by Eric Foxley.
The habit of using -- probably cemented when I wrote a load of command-line utilities for DOS and OS/2 in the 1990s which all supported an end-of-options marker in their command-tail parsing library.
https://groups.google.com/g/comp.os.os2.utilities/c/415LDKL3_Lw/m/P9tPDLd7VAUJ
I made use of what my own tools could do. (-:
My first suspect for a #login not supporting -- would be something with a 1980s history pre-dating standard #getopt, such as Solaris, which is ironic given that #inetutils has its only -- present in conditionally compiled code targetting Solaris.
#FreeBSD, #NetBSD, and #OpenBSD login all use getopt(), pervasive in these worlds for decades, as do the util-linux login (used by Debian et al.), and the #Illumos and #BusyBox logins.
#suckless login supports -- via ARGBEGIN.
Looking at the commit and the code as it still stands today, it is interesting that only on Solaris does it even try to use -- in the arguments to login to signal the end of options, and even then only in limited circumstances.
#FreeBSD telnetd, for comparison, always puts -- in before the supplied account name.
I wonder how long it will be before the lesson is properly learned.
If you look around you should still be able to find Luke Mewburn's paper on #MewburnRC .
Similarly, what Linux people erroneously call "sysvinit" is actually van Smoorenburg init+rc created (by Miquel van Smoorenburg) for Minix in 1992.
It's not from #Unix System 5 at all, as that had obsoleted R3's init+rc system years before 1992 and gone on to the AIX SRC, and the SAF, SAC, ttymon, SMF, and stuff still in #Illumos today.
Don't use rc.local. It has been obsolete since 1983. #FreeBSD has actually discontinued it twice in its history.
FreeBSD has had Mewburn rc for most of this century. It's what #NetBSD uses and #OpenBSD has a similar but NIH system. At minimum, use Mewburn rc scripts.
http://jdebp.info/FGA/rc.local-is-history.html
The rc(8) manual page has an example script. There's tutorial doco as well.
Credit, specifically, to @summertime for tracking this down on Twitter. I had something like 3 characters left in that post and couldn't fit this in. (-:
As someone who knows how terminals, and indeed terminal emulators, work (having used actual terminals years ago, and having written several terminal emulators) I encourage you not to promote this AI-generated bunk as a source of learning.
It is incorrect on a lot of points, beginning with erroneous descriptions of the colour models and what line discipline modes the Bourne Again and Z shells use.
There are subtle omissions and errors in the "terminal stack" and TUI sections.
The "how they fit together" part is blatantly wrong, and the descriptions of the shells and the terminal emulators are laughable (but also regurgitate some widespread myths, which is likely why the AI slop here has what it has).
This is a sad+bad successor to the years of answers that I and other people gave on StackExchange and the like.
https://mastodon.social/@lobsters/115861488474520435
https://how-terminals-work.vercel.app
The lobste.rs people have already identified the source on Twitter for this AI slop.
tr -d works on more systems than tr --delete will.
You can also use that function with the Korn and Watanabe shells.
For what it's worth:
The hyperlinked article is purely about Linux and its two major C libraries (GNU and #musl), and does not cover #Unix, historical or otherwise, at all.
There are systems still around where grantpt and unlockpt are important. On #NetBSD with certain options set they are not actually no-ops. They are definitely not no-ops on #Illumos-based operating systems, where (for starters) STREAMS stuff happens on pseudo-terminal front-end devices.
@rl_dane hit the nail on the head.
This isn't really specific to completion. It's just general overlong input line editing behaviour.
The PD #KornShell and its derivatives (e.g. the #MirBSD Korn Shell) only have line editing with a single line that sideways scrolls.
ksh93, however, has a
set -o multiline
option for switching to a multiple-line line editing mode. (The Z and Bourne Again shells have similar.)
You might like the Watanabe shell. It's in ports.
I was curious as to what this meant, so I fired up PD ksh and tried what I thought long command-prompt entries meant.
The PD #KornShell uses a column width greater than the terminal width (which I set to 50 columns here, just to make things easier) because it SPC-pads everything to the length of the longest string; and ends up double-spacing most rows in the table as a consequence.
I couldn't figure out how to get it to specifically clip rows, though.
I knew that there was #HJKL navigation and #WASD navigation, and some of the full-screen utilities in the #nosh toolset support both.
I read that there's also QAOP, which alas contradicts the conventional use of 'q' that those utilities already have, and ESDF which alas overlaps WASD.
One cannot be all things to all people, and it seems excessive to make this configurable somehow when they're only limited-use bonuses over just using the normal arrow keys.
