The -a to -z of Command-Line Options (2003)
catb.org
catb.org
It's ironic that in 2018, the terminal is more prominent then ever in any developer scene (thinking only of package managers for diverse programming languages), while in the 90s somehow people thought the GUI could solve all problems, not only for the novices but also for computer experts.
https://en.wikipedia.org/wiki/In_the_Beginning..._Was_the_Co...
It examines the issue of GUIs vs. command line interfaces, among other things.
I'm pretty sure there is an anecdote there that says that Mac OS did have a hidden command line? It was only for Apple engineers, not for end users, but it was there. I'd appreciate a pointer if anyone remembers.
When I used it in 1986 it really needed a big machine, i.e. 512K RAM :-)
I sometimes wish there was an open source equivalent like that for Linux , but with live, interactive building of the command as the GUI options were manipulated so new users could get a feel for commands more readily. This would act as an intermediate help system for casual users that is friendlier than manpages, and more immediate than searching around the Net.
[1] https://www.macintoshrepository.org/1360-macintosh-programme...
This still lives on in a sense. For example, in VSCode, many UI commands translate to executing shell code in its internal terminal (and you can see both the commands and the output).
Command line interfaces are powerful, yes, but they're also a crutch. It's very easy to hide certain features by exposing them only through command line flags or what have you. On classic Mac OS you could not do this; you needed to attach every feature to a GUI control of some kind.
As a consequence, people came up with all kinds of GUI tools for pro/expert users. Linux, comparison, treats GUI users as second class citizens and tends to relegate them to only the most basic functionality.
In some sense, I think it has deepened the digital divide.
If you could, I think most developers didn't, since AppleScript isn't a default means of using the computer the way Unix shells are.
I think the issue is not so much "command line hides power and treats GUI like a second-class citizen", though that is true, but rather that preferring one over the other creates problems.
This issue is again rearing its head in website design - many "web applications" have states that are not reachable via linking.
You're right that a lot of GUIs aren't designed for automation, but CLIs aren't the only answer. Classic MacOS had a powerful scripting architecture. (It still exists, but it's been neglected.)
Nowadays on macOS, with the availability of the CLI, Apple engineers have decided to expose those same effects through CLI utilities that call directly into private system APIs (which are themselves usually client libraries for private Mach client-server ABIs.) If there's a switch exposed in the GUI but not the CLI, it's unlikely there's an event to reach it any more.
(Though, in macOS or Windows or Linux, it's always a possibility to write a script that has GUI effects directly in terms of "click the first button on the right"-style accessibility directions. But that's extremely brittle to system version updates, and precisely the thing that exposing an automation API is meant to avoid.)
I miss ResEdit. Pretty much every Mac app in the day used the standard system for managing their resources, so you could pick apart anything with ease using ResEdit. I don't know of any modern equivalent for Unix/Windows/Mac programs.
Also, regarding "burned-in configuration" resources—those are now found in the app bundle's Info.plist :)
Apple released their GUI operating system to consumers before most competitors had anything like it. Rough contemporaries in the GUI consumer OS space, in the mid-80s through the 90s almost all had some kind of command line interface. The addition of AppleScript was probably a response to this, while trying to stay true to Jobs' and Raskin's idea of the Macintosh as a "computer appliance".
With the raise of HTML5 & Electron and their simplicity for creating powerful GUIs and AI-Speech-Driven interfaces we might be again reach somewhere in the next decades the point where Keyboard-interfaces are in decline. And if the AI overlords take over whe don't have any need for complicated interfaces anyway.
IMHO the Amiga offered the best of both worlds at that time (except for expensive UNIX workstations). On one hand you had a modern windowing UI, and a real multitasking OS. On the other hand you had terminal windows with a command line interface that was slightly different to UNIX, but close enough to be enjoyable.
Later in the life of the Amiga it became standard that UI applications provided standardized scripting interfaces (via AREXX), so you could write complex automation tasks that glued together all sorts of UI- and command-line-programs. In a way this was a lot more advanced than anything that's available on Windows or Linux today, since it wasn't limited to a few applications that all live in their own isolated world.
Here's the best source I could dig up https://www.bleepingcomputer.com/tutorials/windows-command-p...
Windows NT's console window was properly accessible to Windows programs, as well as DOS compatibility. Windows 95/98/Me inherited limited forms of text-mode compatibility from NT.
This is not strictly true. You could launch Windows programs from the DOS box. If you tried to run something like PBRUSH.EXE from true DOS you would get "This program requires Windows" but in a DOS box it would detect that Windows was running and launch the program.
I think it is true that there were no Windows-only command line apps though.
I certainly don’t recall ever having any issues with 16 bit games (aside my weird soundcard not working with half the games I tried, but I can’t recall why that was off hand).
Thinking about it some more, I think I might have had a subset autoexec.bat I used to run for those occasions.
That technique seemed to work for me. Maybe I’m forgetting a tonne of 16 bit games that didn’t play but nothing immediately springs to mind
The closest I can think of is Siri and such automation, except AREXX was a full programming language in its own. (The language was from IBM REXX.)
The builtin IDE REPLs are pretty good and more powerful than plain old style UNIX CLI.
Usually I use the cli when I have to, not by choice.
The fun thing about it was that you were essentially interfacing with the GUI. Everything was incredibly discoverable - if you knew something was possible then it was almost always obvious how to do it in AppleScript.
It might be informative to step back and point out that this is why so many of "us" originally disliked Macs; before the "walled garden" of iOS, before even the walled garden of needing iTunes to load music onto your iPod, there was the GUI-only MacOS. Now, those in the know could dramatically alter Mac OS with Resedit, but I wasn't a "Mac guy", so I never really knew anything about it; I hated a locked down OS that only let you do things you could click on.
It was such a step forward to many of us hobbyists that OS X was based on Unix, and suddenly we had the best of both worlds -- a good GUI and a good CLI. Suddenly Windows was no longer the commercial OS that let you "do whatever you wanted" with it (relatively speaking).
In fact, (to personalize this for a paragraph), as a Linux desktop person buying his first laptop in 2002, I decided "well, I guess I might as well buy a Windows laptop instead of trying to hassle with running Linux on it." It felt like "giving in" to buy the commercial OS just to have easy access to Office and DVD players and the like. It slowly dawned on me "wait, if I'm going to buy a commercial OS, maybe I could buy a Mac?" I had never considered a Mac in my life, but I realized, wait, I can have Office on it (which not everyone realized, even then), AND easily play DVDs, AND this new OS X thing (which had come out a year before). It was a huge leap of faith, though.
The reputation of Apple building things that are just "pretty and shiny", I think, still stems from this sense that it's a consumer device that only does what Apple lets you do with it. And yes, some of these criticisms are still valid, but for those who weren't aware of the no-CLI Mac OS, I think it's very useful context that many of us take for granted.
In some ways these could be even more powerful than a Unix shell. What's the Unix way to say "Select a menu item", if the developer of your favorite app didn't think to also include a command-line interface to it?
(Yeah, I know: accessibility APIs. Do all your apps include a complete set of those, too?)
Being a Unix user and dev (above, not at the kernel level) for a long time before reading it, it crystallized and verbalized for me many concepts and unspoken techniques that are sort of hazily known and used but taken for granted (although applied instinctively) - although I had also figured out and sort of verbalized some of those on my own before reading the book.
Also, related, anyone interested in learning to write (not just use) their own command-line utilities in C on Linux, may like to check out this tutorial I wrote for IBM developerWorks:
https://jugad2.blogspot.com/2014/09/my-ibm-developerworks-ar...
It was on the site for long, got 30-40K views, and good ratings (4/5). Clients and others I know have used the tutorial as a guide to creating production command-line utilities. Follow the selpg links recursively to get to the PDF of the article and the source code.
I first wrote the utility that is used as a case study in the article, for production use at one of the largest motorcycle manufacturers in the world.
http://www.gnu.org/prep/standards/html_node/Option-Table.htm...
[edit] forgot to mention that for grep-like utilities -v negates the match.
This led to an unfortunate incident in which I attempted to get verbose output from pkill and instead killed every single process on the machine except for my target. To make it worse I had no console access so I had to email another team to reboot and explain what I did.
I think this is one of the big problems with both CLIs and (most) GUIs. We're stuck in a particular mode of thinking. For CLIs, it's that pressing a letter key must append that letter (and only that letter) on the screen, like a typewriter. Traditional GUIs have their own problems, which I'm sure half the crowd here can recite in their sleep.
When developing my app Strukt, I discovered I really needed to decouple "how you type it on the keyboard" from "what it looks like on screen". You get autocomplete on all operations and flags, so you can type just the first letter of a flag, but still see the whole thing on screen. It appears that some other modern editors (like Atom) have adopted a similar system, which is great. Emacs, of course, has had this forever (but has its own UI issues). :-)
Not something simplistic like keyword completion, more like the best state of the art code editors or ides.
In those environments its just text based still, but can be incredibly rich and efficient. You can get seamless acesss to info on any language command or param, predictive code completion suggestions, based on machine learning, easily refactor/correct parts of a line you’ve already started typing, etc.
The thing is it doesn’t have to get in the way if designed right. So someone can also just sit down and blaze away typing and ignore it.
One example: /bin/rm has the -i (for interactive option). Some people alias 'rm' (or if they are newbs, it is sometimes aliased for them by someone senior in their org) to 'rm -i', which helps avoid deleting files by mistake, due to typos or typing too fast. With -i, rm asks for confirmation before deleting each file. This is more important in Unixes because most of them do not have any undelete utility; nor does Windows, AFAIK, except for 3rd-party ones like the Norton Utilities (does it still exist?), which need to be installed. And installing the utility (if you can get it) after an accidental delete, has some chance of the utility getting installed onto disk blocks earlier occupied by the deleted file.
GNU getopt() uses this to make --foo and -Wfoo equivalent, but this is GNUism of questionable utility.
I have feeling that original reason for this is that there historically was libc which implemented wordexp(3) by exec'ing /bin/sh -W, but I have no way to confirm that.
Notably, GCC's -W<foo> works the same way. You could do "gcc --all" if you wanted to.
paths() { echo $PATH | tr : '\n'; }
paths | cut -d / -f 3
paths | column -s / -t
paths | sort -t / -k 1
paths | awk -F / '{ print $1 }'
This one does surprise me. It is almost always one of the first options I try. That or "--help".
I'm sure it's just default "I don't recognize the option so here's how to use this tool" message but the result is the same.
There are exceptions of course, e.g. mysql uses -h for host so you just get an error message about requiring an argument. --help is implemented properly in this case though.
wc: invalid option -- 'h'
Try 'wc --help' for more information.For this reason, I always use "man <command>". The prevalence of "--help" has always bothered me since a badly-written command could start doing all sorts of unexpected things, when you just wanted to see the documentation. I've seen all sorts of ISV software not implement --help correctly. "man" always works.
"man oven" = look up your oven model in your Home Manual
"oven -h" = turn your oven dial past "Broil" and hope it pops out a hidden cheat sheet
-a could also be "ask"; Gentoo, for example, uses it to ask you to confirm before proceeding with emerge.
-h is very often "host".
-v, --inverse
Negates the matching. This option is usually used in pgrep's context. In pkill's context the short option is disabled to avoid accidental usage of the option