17 ms·

The -a to -z of Command-Line Options (2003)

132 points by polm23 8y ago

ktpsns 8y ago
Wow, the fact that Mac OS Classic did not even have a command line interface really baffles me. I looked it up and https://news.ycombinator.com/item?id=18646286 https://news.ycombinator.com/item?id=18646286 - it seems to be true. 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.
- aequitas 8y ago
  I remember vaguely having to create a bootable floppy for an old os9 installation. It had to be done by dragging a system file from the OS onto the floppy in a special way which is termed "Blessing".
  - saagarjha 8y ago
    You can now do this from the command line using bless(8).
- chubot 8y ago
  It's indeed interesting how important the command line is now. You might like this mini-book / essay by Neal Stephenson: https://en.wikipedia.org/wiki/In_the_Beginning..._Was_the_Command_Line 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.
  - bboreham 8y ago
    The Macintosh Programmers Workbench (MPW), the first IDE for Mac, had a command-line with a simple shell. When I used it in 1986 it really needed a big machine, i.e. 512K RAM :-)
    - yourapostasy 8y ago
      MPW had an interesting way to ease GUI-centric users into its CLI-centric world. There was a mode you could trigger for commands that brought up a help-oriented GUI for the command to build the command argument list, which would then echo onto the command line. Depending upon who built the GUI, it was usually a less terse and friendlier help for new users than AIX's SMIT, for those who are familiar with that. 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-programmer-s-workshop-mpw-3-0-to-3-5 https://www.macintoshrepository.org/1360-macintosh-programme...
      - int_19h 8y ago
        > There was a mode you could trigger for commands that brought up a help-oriented GUI for the command to build the command argument list, which would then echo onto the command line. 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).
    - chubot 8y ago
      Thanks, I'm pretty sure that's what Stephenson mentioned in his essay / book.
- chongli 8y ago
  Yes, classic Mac OS truly did not have a command line interface of any kind. As a consequence, everything your application did must have had a GUI command or preference corresponding to it. 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.
  - ktpsns 8y ago
    Well, I was too young to really explore classic Mac OS at that time. But from my feeling, the unixoidity of Mac OS X was really a blessing for the hacking community. So there definetly was a need.
    - chongli 8y ago
      Oh don't get me wrong, I live in the terminal these days. It's immensely satisfying to whip up a quick bash or Perl script to solve a problem. That being said, I believe the reliance Unix command line tools has made this computing power inaccessible to ordinary users. In some sense, I think it has deepened the digital divide.
      - laumars 8y ago
        You could still do scripting akin to Bash scripts on OS 7 and above via AppleScript[1]; which worked a little bit like WSH did on Windows. [1] https://en.wikipedia.org/wiki/AppleScript https://en.wikipedia.org/wiki/AppleScript
        chongli 8y ago
        Yes, and I'm an old fan of AppleScript as well. The difference, as far as I know, is that you couldn't hide core application functionality behind that API, could you? 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.
- boomlinde 8y ago
  It's worth considering what about command line interfaces makes them useful, who they are useful for and whether Mac OS offered an analogous interface somehow that fit the bill for their users. For me, the main gain of using a shell is that you can easily automate and document workflows. Apple added this to System 7 with AppleScript, to some extent. I haven't used AppleScript, so I have no idea of how successful it was to this end, but it does seem to cover some surface that would traditionally be in the domain of a command line shell. 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".
  - deleted 8y ago
    [deleted]
- PurpleRamen 8y ago
  Well, to be fair, GUIS can be powerful commandlines, to the point that they even satisfy most experts. But it needs more work, and you either end up using textinput anyway, or have a slightly worst performing interface. So at the end most invest into the simple solution. 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.
- flohofwoe 8y ago
  IFIR, Win3.1 didn't have a command line either, you had to exit Windows completely back to DOS. 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.
  - np_tedious 8y ago
    I think Windows 3.1 did have one. Accessible at command.com Here's the best source I could dig up https://www.bleepingcomputer.com/tutorials/windows-command-prompt-introduction/ https://www.bleepingcomputer.com/tutorials/windows-command-p...
    - chungy 8y ago
      Windows 1.x-3.x didn't really have a command line, the window you use to run command.com was for DOS programs only. Windows programs didn't have a text mode to utilize it. 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.
      - einr 8y ago
        the window you use to run command.com was for DOS programs only. 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.
- pjmlp 8y ago
  I use my package managers from within Eclipse and Visual Studio. 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.
- mjlee 8y ago
  AppleScript existed on System 7 - I used to use it like a very limited command line (scripting common activities and complex workflows.) 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.
- rconti 8y ago
  Wow, the fact that this is baffling to someone is, in turn, baffling to me! I don't mean this to be insulting, it's just one of those generational things. It hadn't occurred to me that someone (someone who cares about CLIs, at least) wouldn't know this. 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.
- ken 8y ago
  It didn't have a Unix shell, but you likely had some way to type commands and get the computer to run them. Depending on context, you might have had HyperTalk, or AppleScript, or the MPW Shell. 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?)
deleted 8y ago
[deleted]
FASTasdf 8y ago
pkill -v 1
- lunchables 8y ago
  In my version of pkill the short version is specifically disabled. -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
teddyh 8y ago
See also the canonical table of long GNU-style options: http://www.gnu.org/prep/standards/html_node/Option-Table.html#Option-Table http://www.gnu.org/prep/standards/html_node/Option-Table.htm...
vram22 8y ago
That whole book (not just the linked chapter about command-line options) - i.e. TAOUP - The Art Of Unix Programming - by ESR (Eric Steven Raymond, of Cathedral and Bazaar fame) - is good (although verbose and using many heavy words and verbal flourishes in his trademark style). I've read most of it. The Rules section stands out. 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-article.html 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.
amyjess 8y ago
-p is also very commonly "password". It may take an argument, or it may cause the program to interactively prompt you for a password when you run it. Similarly, -k is often "key". -a could also be "ask"; Gentoo, for example, uses it to ask you to confirm before proceeding with emerge. -h is very often "host".
znpy 8y ago
All I can think of, while noting all the numerous exceptions to the rule is https://www.xkcd.com/293/ https://www.xkcd.com/293/
dfox 8y ago
One interesting thing to note is that IEEE 1003 says: "The -W (capital-W) option shall be reserved for vendor options." 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.
- cyphar 8y ago
  I can imagine one of the reasons it might be useful is if you have a badly written argument parser that only accepts single-dash commands, but you need to pass a long argument (that gets shelled out). However, it's entirely opt-in so I imagine this is not practically useful for most programs. Notably, GCC's -W<foo> works the same way. You could do "gcc --all" if you wanted to.
nouseforaname 8y ago
Fun fact: -v typically stands for verbose except when using any "grep-like" utilities such as pgrep, pkill, etc. [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.
- mehrdadn 8y ago
  I'll get crucified for saying this but this is one of the differences between a CLI and a GUI. A button/menu item/etc. always tells you what it does (even if it's just a brief description) before you click it. A command line parameter, well, reduces the information redundancy to near zero... you have to go out of your way to figure out its meaning.
  - amaccuish 8y ago
    That's why I prefer the more wordy -- alternatives, like --verbose
    - ken 8y ago
      I use one-letter flags when working interactively, to save time, but my shell scripts always use the --verbose form. It makes them much easier to read.
  - ken 8y ago
    Unless you use a keyboard shortcut in your GUI, in which case all bets are off. I remember being constantly frustrated back in the Adobe Illustrator 10 / Photoshop 7 days that the standard shortcuts (like cmd-H and cmd-M) did something completely different than I expected. 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). :-)
twic 8y ago
What's the flag to specify a separator character? paths() { echo $PATH | tr : '\n'; } paths | cut -d / -f 3 paths | column -s / -t paths | sort -t / -k 1 Any more?
- jdeca568 8y ago
  paths | awk -F / '{ print $1 }' (edit: format)
pwaivers 8y ago
> -h Help. This is actually less common than one might expect offhand — for much of Unix's early history developers tended to think of on-line help as memory-footprint overhead they couldn't afford. This one does surprise me. It is almost always one of the first options I try. That or "--help".
- smhenderson 8y ago
  I find in most modern tools whether or not -h or --help is implemented using them often yields at least a usage statement. 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.
  - mort96 8y ago
    I usually use `-h`, because it's shorter to type than `--help`. I find I encounter this kind of message way too frequently: wc: invalid option -- 'h' Try 'wc --help' for more information.
    - smhenderson 8y ago
      That is annoying, I actually prefer the behavior I described. If an argument is not recognized I just want a usage message so I can check my syntax quickly.
- cyphar 8y ago
  A friend of mine once had telnet'd into their (awful) ISP home router, and started playing with the various commands. Not thinking, they typed "init -h" and the router then promptly stopped routing packets. Turns out the (probably custom-written) "init" automatically sets the runlevel to single-user mode, and they handn't bothered to implement "-h". 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.
timerol 8y ago
For everyone who finds this (and similar work by ESR) valuable, consider supporting him on Patreon: https://www.patreon.com/esr https://www.patreon.com/esr

132 points by polm23 8y ago

Wow, the fact that Mac OS Classic did not even have a command line interface really baffles me. I looked it up and https://news.ycombinator.com/item?id=18646286 https://news.ycombinator.com/item?id=18646286 - it seems to be true. 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.

aequitas 8y ago
I remember vaguely having to create a bootable floppy for an old os9 installation. It had to be done by dragging a system file from the OS onto the floppy in a special way which is termed "Blessing".
- saagarjha 8y ago
  You can now do this from the command line using bless(8).
chubot 8y ago
It's indeed interesting how important the command line is now. You might like this mini-book / essay by Neal Stephenson: https://en.wikipedia.org/wiki/In_the_Beginning..._Was_the_Command_Line 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.
- bboreham 8y ago
  The Macintosh Programmers Workbench (MPW), the first IDE for Mac, had a command-line with a simple shell. When I used it in 1986 it really needed a big machine, i.e. 512K RAM :-)
  - yourapostasy 8y ago
    MPW had an interesting way to ease GUI-centric users into its CLI-centric world. There was a mode you could trigger for commands that brought up a help-oriented GUI for the command to build the command argument list, which would then echo onto the command line. Depending upon who built the GUI, it was usually a less terse and friendlier help for new users than AIX's SMIT, for those who are familiar with that. 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-programmer-s-workshop-mpw-3-0-to-3-5 https://www.macintoshrepository.org/1360-macintosh-programme...
    - int_19h 8y ago
      > There was a mode you could trigger for commands that brought up a help-oriented GUI for the command to build the command argument list, which would then echo onto the command line. 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).
  - chubot 8y ago
    Thanks, I'm pretty sure that's what Stephenson mentioned in his essay / book.
chongli 8y ago
Yes, classic Mac OS truly did not have a command line interface of any kind. As a consequence, everything your application did must have had a GUI command or preference corresponding to it. 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.
- ktpsns 8y ago
  Well, I was too young to really explore classic Mac OS at that time. But from my feeling, the unixoidity of Mac OS X was really a blessing for the hacking community. So there definetly was a need.
  - chongli 8y ago
    Oh don't get me wrong, I live in the terminal these days. It's immensely satisfying to whip up a quick bash or Perl script to solve a problem. That being said, I believe the reliance Unix command line tools has made this computing power inaccessible to ordinary users. In some sense, I think it has deepened the digital divide.
    - laumars 8y ago
      You could still do scripting akin to Bash scripts on OS 7 and above via AppleScript[1]; which worked a little bit like WSH did on Windows. [1] https://en.wikipedia.org/wiki/AppleScript https://en.wikipedia.org/wiki/AppleScript
      - chongli 8y ago
        Yes, and I'm an old fan of AppleScript as well. The difference, as far as I know, is that you couldn't hide core application functionality behind that API, could you? 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.
boomlinde 8y ago
It's worth considering what about command line interfaces makes them useful, who they are useful for and whether Mac OS offered an analogous interface somehow that fit the bill for their users. For me, the main gain of using a shell is that you can easily automate and document workflows. Apple added this to System 7 with AppleScript, to some extent. I haven't used AppleScript, so I have no idea of how successful it was to this end, but it does seem to cover some surface that would traditionally be in the domain of a command line shell. 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".
- deleted 8y ago
  [deleted]
PurpleRamen 8y ago
Well, to be fair, GUIS can be powerful commandlines, to the point that they even satisfy most experts. But it needs more work, and you either end up using textinput anyway, or have a slightly worst performing interface. So at the end most invest into the simple solution. 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.
flohofwoe 8y ago
IFIR, Win3.1 didn't have a command line either, you had to exit Windows completely back to DOS. 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.
- np_tedious 8y ago
  I think Windows 3.1 did have one. Accessible at command.com Here's the best source I could dig up https://www.bleepingcomputer.com/tutorials/windows-command-prompt-introduction/ https://www.bleepingcomputer.com/tutorials/windows-command-p...
  - chungy 8y ago
    Windows 1.x-3.x didn't really have a command line, the window you use to run command.com was for DOS programs only. Windows programs didn't have a text mode to utilize it. 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.
    - einr 8y ago
      the window you use to run command.com was for DOS programs only. 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.
pjmlp 8y ago
I use my package managers from within Eclipse and Visual Studio. 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.
mjlee 8y ago
AppleScript existed on System 7 - I used to use it like a very limited command line (scripting common activities and complex workflows.) 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.
rconti 8y ago
Wow, the fact that this is baffling to someone is, in turn, baffling to me! I don't mean this to be insulting, it's just one of those generational things. It hadn't occurred to me that someone (someone who cares about CLIs, at least) wouldn't know this. 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.
ken 8y ago
It didn't have a Unix shell, but you likely had some way to type commands and get the computer to run them. Depending on context, you might have had HyperTalk, or AppleScript, or the MPW Shell. 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?)

deleted 8y ago

[deleted]

FASTasdf 8y ago

pkill -v 1

lunchables 8y ago
In my version of pkill the short version is specifically disabled. -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

teddyh 8y ago

See also the canonical table of long GNU-style options: http://www.gnu.org/prep/standards/html_node/Option-Table.html#Option-Table http://www.gnu.org/prep/standards/html_node/Option-Table.htm...

vram22 8y ago

That whole book (not just the linked chapter about command-line options) - i.e. TAOUP - The Art Of Unix Programming - by ESR (Eric Steven Raymond, of Cathedral and Bazaar fame) - is good (although verbose and using many heavy words and verbal flourishes in his trademark style). I've read most of it. The Rules section stands out. 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-article.html 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.

amyjess 8y ago

-p is also very commonly "password". It may take an argument, or it may cause the program to interactively prompt you for a password when you run it. Similarly, -k is often "key". -a could also be "ask"; Gentoo, for example, uses it to ask you to confirm before proceeding with emerge. -h is very often "host".

znpy 8y ago

All I can think of, while noting all the numerous exceptions to the rule is https://www.xkcd.com/293/ https://www.xkcd.com/293/

dfox 8y ago

One interesting thing to note is that IEEE 1003 says: "The -W (capital-W) option shall be reserved for vendor options." 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.

cyphar 8y ago
I can imagine one of the reasons it might be useful is if you have a badly written argument parser that only accepts single-dash commands, but you need to pass a long argument (that gets shelled out). However, it's entirely opt-in so I imagine this is not practically useful for most programs. Notably, GCC's -W<foo> works the same way. You could do "gcc --all" if you wanted to.

nouseforaname 8y ago

Fun fact: -v typically stands for verbose except when using any "grep-like" utilities such as pgrep, pkill, etc. [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.

mehrdadn 8y ago
I'll get crucified for saying this but this is one of the differences between a CLI and a GUI. A button/menu item/etc. always tells you what it does (even if it's just a brief description) before you click it. A command line parameter, well, reduces the information redundancy to near zero... you have to go out of your way to figure out its meaning.
- amaccuish 8y ago
  That's why I prefer the more wordy -- alternatives, like --verbose
  - ken 8y ago
    I use one-letter flags when working interactively, to save time, but my shell scripts always use the --verbose form. It makes them much easier to read.
- ken 8y ago
  Unless you use a keyboard shortcut in your GUI, in which case all bets are off. I remember being constantly frustrated back in the Adobe Illustrator 10 / Photoshop 7 days that the standard shortcuts (like cmd-H and cmd-M) did something completely different than I expected. 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). :-)

twic 8y ago

What's the flag to specify a separator character? paths() { echo $PATH | tr : '\n'; } paths | cut -d / -f 3 paths | column -s / -t paths | sort -t / -k 1 Any more?

jdeca568 8y ago
paths | awk -F / '{ print $1 }' (edit: format)

pwaivers 8y ago

> -h Help. This is actually less common than one might expect offhand — for much of Unix's early history developers tended to think of on-line help as memory-footprint overhead they couldn't afford. This one does surprise me. It is almost always one of the first options I try. That or "--help".

smhenderson 8y ago
I find in most modern tools whether or not -h or --help is implemented using them often yields at least a usage statement. 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.
- mort96 8y ago
  I usually use `-h`, because it's shorter to type than `--help`. I find I encounter this kind of message way too frequently: wc: invalid option -- 'h' Try 'wc --help' for more information.
  - smhenderson 8y ago
    That is annoying, I actually prefer the behavior I described. If an argument is not recognized I just want a usage message so I can check my syntax quickly.
cyphar 8y ago
A friend of mine once had telnet'd into their (awful) ISP home router, and started playing with the various commands. Not thinking, they typed "init -h" and the router then promptly stopped routing packets. Turns out the (probably custom-written) "init" automatically sets the runlevel to single-user mode, and they handn't bothered to implement "-h". 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.

timerol 8y ago

For everyone who finds this (and similar work by ESR) valuable, consider supporting him on Patreon: https://www.patreon.com/esr https://www.patreon.com/esr