2

The key is about semantics.

curl -I, which means curl --head, puzzled me. I don't know what the semantic words the alphabet I stand for? Is it just a reference rather than an abbreviation of a semantic word? Likewise curl -b , which means curl --cookie, has the same confused question.

Can someone make it clear how the inventor do such design at first? Do the examples above mean the options don't have to be semantic?

closed as primarily opinion-based by muru, Scott, Stephen Rauch, Satō Katsura, Archemar Sep 8 '17 at 9:49

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Of course the options don't have to be semantic. They can be whatever the devs want them to be. At least for -I, there's a very plausible reason: ..FGHIJK.. and -H was already taken. (Possibly similar reasoning in opposite direction for -b). – muru Sep 8 '17 at 2:26
  • 2
    I stands for "there are no good semantic abbreviations left unused, so let's just pick some random free letter". :) – Satō Katsura Sep 8 '17 at 7:27
2

At first glance it seemed to me that this wasn't answerable except to say, no, options that seem meaningless can always be found. You can make your own program that deliberately has totally meaninglessly named options. (Of course, even then, you might say they are meaningful in their meaninglessness, if they were deliberately chosen to be meaningless.)

Upon further consideration, however, I realized that the ambiguity in what it means for an option to be semantic is actually an important and useful part of how command-line options are named, and curl -I is a particularly illustrative case of this.

As muru says, options don't have to be semantic. But curl's -I option is semantic. From curl(1):

-i/--include
        (HTTP) Include the HTTP-header in the output. The HTTP-header includes things like server-name, date of the document, HTTP-version and more...

-I/--head
       (HTTP/FTP/FILE) Fetch the HTTP-header only! HTTP-servers feature the command HEAD which this uses to get nothing but the header of a document. When used on a FTP or FILE file, curl displays the file size and last modification time only.

-i is the short form of --include, causing the HTTP header to be included. Although -I is the short form of --head, it is semantically the stronger form of -i, in that while -i gives you the HTTP header, -I gives you only the HTTP header.

This offers insight into your larger question: there are many different criteria with which one might judge if an option name is semantic. When an option is semantic it might be intentional or unintentional. If you're only interested in whether or not there exists some way to remember the option as though it is semantic, then yes, you can always make up a reason the name relates to its meaning.

Some options are semantic in more than one way. You can make GNU grep show lines adjacent to matching lines with -A for after, -B for before, and -C for context which gives you both. Thus the short forms of the three options -A/--after-context, -B/--before-context, and -C/--context, which are very close to one another in meaning, are also close to one another in the alphabet. Is that semantic?

To pursue this further and get a rigorous answer, you can search applicable standards like POSIX.1-2008. It seems extremely implausible that it prohibits meaninglessly named options, but I suppose you'd have to carefully read the whole thing to be sure. A cursory search does not reveal any requirement that options mean anything. In particular, these official guidelines--required only for commands whose documentation declares compliance with them--recommend various restrictions on how options may be named and the effect of passing them, but they don't mention anything that could be interpreted as a requirement or recommendation that option names make sense. Even if you did find something, many Unix-like systems don't aim for full POSIX compliance...

But that whole line of thinking--consulting official sources to determine if (vendors have to pretend that) every option's name means something--is sort of silly. The real useful thing to know about options is that their names can relate to each other in multiple ways. They can be named after words, after other options, or for alphabetical proximity to other options. Sometimes they're just a letter (or numeral) that happened to be available. Thinking about these ways can help you to remember options, to find options when searching manpages, and to make good decisions about what option names your own scripts or programs should take.

As a final note, it's good to keep in mind that it's not just short-form options that can be named in ways that don't allow you to infer their meaning. For example, the long-form options --regex and --regexp to mlocate are named semantically in the sense that they both have to do with regular expressions. But there is nothing in the way they are named to tell you that --regexp means the next argument is a BRE while --regex means all pattern arguments are EREs.

  • 1
    Just to add on semantics: Some times commands are trying to use common options of other well known commands, so the user can memorize it easier. This does not always mean that the long name is exactly the same. And sometimes you are suprised, e.g. grep does not follow the -v = `--verbose`` standard pattern but uses it to negate the result. – allo Sep 8 '17 at 14:27

Not the answer you're looking for? Browse other questions tagged or ask your own question.