From coff at tuhs.org Sun Nov 2 20:25:00 2025 From: coff at tuhs.org (Lars Brinkhoff via COFF) Date: Sun, 02 Nov 2025 10:25:00 +0000 Subject: [COFF] [TUHS] evolution of the cli In-Reply-To: (A. P. Garcia via TUHS's message of "Sat, 1 Nov 2025 10:59:21 -0400") References: Message-ID: <7wecqgu3yb.fsf@junk.nocrew.org> A. P. Garcia wrote: > The Evolution of the Command Line: From Terseness to Expression I wonder if you are also interested in some evolutionary dead ends? I'm thinking about the ITS DDT/HACTRN command line interface. It's even barely a command *line* because most commands are one or a few key strokes. It certainly fits your "from terseness" thesis. If you have used this type of user interface for a while, you may notice the fluidity, immediateness, almost subconscious transfer from thought to keystroke to action. I'd say this is something that may have been lost. But not entirely, because it still lives on in the form of Emacs. I'm rerouting this subthread away from TUHS to COFF. I have seen some hand-wringing arguments that "Emacs does too conform to Unix philosophy because ". I say no. Emacs does empathically not conform to Unix philosophy, and it doesn't have to. It very much conformss to the ITS philosophy of user interfaces. Digging deeper through the historical strata, we can find a whiff of the Stanford AI lab in the Emacs user interface. Namely the heavy use of modifiers: control, meta, and if you have them, super, hyper, greek. ITS natively used only control and added the Altmode - Escape - prefix for more commands. MIT imported the Stanford AI lab keyboard with more modifiers and made use of them in Emacs. The modifiers proliferated even more with the Lisp machines which expanded on the ITS user interface. From coff at tuhs.org Mon Nov 3 04:18:26 2025 From: coff at tuhs.org (Warner Losh via COFF) Date: Sun, 2 Nov 2025 11:18:26 -0700 Subject: [COFF] [TUHS] evolution of the cli In-Reply-To: <7wecqgu3yb.fsf@junk.nocrew.org> References: <7wecqgu3yb.fsf@junk.nocrew.org> Message-ID: On Sun, Nov 2, 2025 at 3:25 AM Lars Brinkhoff via COFF wrote: > A. P. Garcia wrote: > > The Evolution of the Command Line: From Terseness to Expression > > I wonder if you are also interested in some evolutionary dead ends? I'm > thinking about the ITS DDT/HACTRN command line interface. It's even > barely a command *line* because most commands are one or a few key > strokes. It certainly fits your "from terseness" thesis. > Yet there's another line of command lines to look at: TOPS-20 and VMS. These were quite verbose by the early 80s and provided a very rich grammar to use. These have gone the extreme other direction than ITS. Warner From coff at tuhs.org Sat Nov 8 11:48:06 2025 From: coff at tuhs.org (Dan Cross via COFF) Date: Fri, 7 Nov 2025 20:48:06 -0500 Subject: [COFF] [TUHS] Re: To NDEBUG or not to NDEBUG, that is the question In-Reply-To: References: Message-ID: On Fri, Nov 7, 2025 at 8:40 PM wrote: > Quoth Dan Cross : > > On Fri, Nov 7, 2025 at 1:54 PM Ori Bernstein wrote: > > > On Fri, 17 Oct 2025 08:22:23 -0400, Dan Cross via TUHS wrote: > > > > > > > One must question whether `assert` is the right thing or not, though; > > > > as an interface, it's pretty limited: a thing can either be true or > > > > not, but any surrounding information is not preserved; > > > > > > This is untrue -- with core dumps enabled, surrounding information is > > > preserved better than most other options. > > > > Apples and oranges. Presumably you're referring to a post-mortem > > analysis pointing a debugger at a core file and binary, but that vs > > the printed output from a failed `assert` is sufficiently dissimilar > > as to be specious. Furthermore, there's no guarantee that a failed > > `assert` will result in a core file being produced; production of core > > dumps can be disabled, but even if not, a process can catch `SIGABRT` > > and `longjmp` out of the handler; POSIX and C both explicitly allow > > for that. > > > > There is a reason people invent `ASSERT3x` macros for x in {U,P,I}, > > etc, and it's not just for kicks. And besides, as Arnold pointed out, > > it _can_ be done with `assert`: it's just ugly and painful. And of > > course, one can always use an explicit conditional, print whatever one > > likes, and call `abort()` directly if one wants (possibly resetting > > the signal handler to the default before-hand). You may still not get > > a core dump, but at least you can print whatever context you like. > > Yes, it's certainly possible for people to sabotage the usefulness > of a well placed abort. This is something I find frustrating when > debugging, because even the best stack traces lack a great deal of > information. [This is getting into COFF territory; TUHS to Bcc:] Not just users, but administrators, system policy and so forth; consider an `abort` in a setuid program. And of course, stack traces can be generated without the use of `abort()` or production of a core file; there are pre-canned libraries for pretty much all mainstream systems for doing that these days. Post mortem analysis is undeniably useful. But I maintain that it is _mostly_ orthogonal to `assert`. - Dan C. From coff at tuhs.org Sat Nov 8 13:12:20 2025 From: coff at tuhs.org (segaloco via COFF) Date: Sat, 08 Nov 2025 03:12:20 +0000 Subject: [COFF] [TUHS] Re: To NDEBUG or not to NDEBUG, that is the question In-Reply-To: References: Message-ID: On Friday, November 7th, 2025 at 17:48, Dan Cross via COFF wrote: > On Fri, Nov 7, 2025 at 8:40 PM ori at eigenstate.org wrote: > > > Quoth Dan Cross crossd at gmail.com: > > > > > On Fri, Nov 7, 2025 at 1:54 PM Ori Bernstein ori at eigenstate.org wrote: > > > > > > > On Fri, 17 Oct 2025 08:22:23 -0400, Dan Cross via TUHS tuhs at tuhs.org wrote: > > > > > > > > > One must question whether `assert` is the right thing or not, though; > > > > > as an interface, it's pretty limited: a thing can either be true or > > > > > not, but any surrounding information is not preserved; > > > > > > > > This is untrue -- with core dumps enabled, surrounding information is > > > > preserved better than most other options. > > > > > > Apples and oranges. Presumably you're referring to a post-mortem > > > analysis pointing a debugger at a core file and binary, but that vs > > > the printed output from a failed `assert` is sufficiently dissimilar > > > as to be specious. Furthermore, there's no guarantee that a failed > > > `assert` will result in a core file being produced; production of core > > > dumps can be disabled, but even if not, a process can catch `SIGABRT` > > > and `longjmp` out of the handler; POSIX and C both explicitly allow > > > for that. > > > > > > There is a reason people invent `ASSERT3x` macros for x in {U,P,I}, > > > etc, and it's not just for kicks. And besides, as Arnold pointed out, > > > it can be done with `assert`: it's just ugly and painful. And of > > > course, one can always use an explicit conditional, print whatever one > > > likes, and call `abort()` directly if one wants (possibly resetting > > > the signal handler to the default before-hand). You may still not get > > > a core dump, but at least you can print whatever context you like. > > > > Yes, it's certainly possible for people to sabotage the usefulness > > of a well placed abort. This is something I find frustrating when > > debugging, because even the best stack traces lack a great deal of > > information. > > > [This is getting into COFF territory; TUHS to Bcc:] > > Not just users, but administrators, system policy and so forth; > consider an `abort` in a setuid program. And of course, stack traces > can be generated without the use of `abort()` or production of a core > file; there are pre-canned libraries for pretty much all mainstream > systems for doing that these days. > > Post mortem analysis is undeniably useful. But I maintain that it is > mostly orthogonal to `assert`. > > - Dan C. In my mind, assert implies some knowledge of a failure condition to look for. Post mortem I usually find myself doing is to find a failure condition that I am not aware of. Once found, an assertion can be made as a regression test against the now-known failure condition, which can be omitted via NDEBUG. That feels clean to me at least. - Matt G.