3

Commands like git, hg, and apt-get all have sub-commands (is there a better name?), and they are all case-sensitive:

hg log                    # not hg Log
git status                # not git Status
sudo apt-get install nano # not sudo apt-get Install nano

Obviously a lot of things in Unix need to be case-sensitive, because that's kind of how Unix is.

But in this case, there's no potential ambiguity. Those arguments can only be command names and can't be anything else (can they?). git's error message suggests that this is the case:

> git Status
git: 'Status' is not a git command. See 'git --help'.

Did you mean this?
        status

Besides adding just a little more frustration for beginners and conforming to Unix culture, is there any reason to be case-sensitive?

Community
  • 1
jtpereyda
  • 421
  • 1
  • 7
  • 18
  • 2
    I guess I don't understand how being explicit with the case is more confusing to the end user. If a tutorial shows you git status then it's pretty obvious that you should type that. The lack of specifying things explicitly has more to do with laziness IMO. The mindset of "case doesn't matter" has more to do with growing up in a Windows culture. – slm Mar 26 '14 at 01:39

3 Answers3

8

Case sensitive is part of the POSIX way of handling command and argument it has nothing to do with the meaning.

It's a very good thing that Status and status are not the same because the file system which kind of a base in the system is case sensitive (because of POSIX rules). It's usually a good pratice to keep the same behavior in your whole system.

So for example, if your second argument can be either a filename or a keyword could you consider that keyword is acceptable case sensitive or not ? it would be such a mess to have commands that accept case sensitive argument sometime and sometime not.

The last important thing about key sensitivity in my opinion is the fact that if type ls -L you might have define this yourself and really wants to type it with a capital L and the system should never try to guess and always execute what you type.

Kiwy
  • 9,534
  • Do any of git, hg, or apt-get accept filenames or keywords for their first argument? Do any commonly used applications behave like that? – jtpereyda Mar 26 '14 at 00:20
  • @dafrazzman I'm speaking in a general way, the goal of the system is to be consistent, not having easier thing set for specific part, also see the last edit – Kiwy Mar 26 '14 at 00:22
  • 1
    @Kiwy congrats for 2k! –  Mar 26 '14 at 00:48
  • @Kiwy So Unix apps have an expectation of case-sensitivity. Therefore you're inviting people to make false assumptions if you make your app case-insensitive. – jtpereyda Mar 26 '14 at 17:27
  • @dafrazzman well yes you get it. Making a case insensitive program could lead you to certain problem with the whole case sensitivity of the sytem, plus there's some command that uses letter in small and uppercase i.e: grep – Kiwy Mar 26 '14 at 17:47
  • @Kiwy The question is about sub-commands specifically, not commands in general or filenames. – jtpereyda Mar 26 '14 at 17:49
  • @dafrazzman but all is about consistency, if argument are case ensitive, why should you change this for some argument that have a special meaning. – Kiwy Mar 26 '14 at 17:51
8

is there any reason to be case-sensitive?

It leaves a much bigger namespace available. For example, a later version of git could implement uppercase variations on command names, or allow the user to define macros/aliases, as with the shell, where you can define your own MV, CP, etc. without having to redefine mv, cp, etc.

goldilocks
  • 87,661
  • 30
  • 204
  • 262
5

Look at it from another perspective. The computer has no knowledge of language or letters, what it sees are numbers that are then mapped to characters. While I (the letter I) and | (the pipe) may look very similar to you, they are completely different to the computer.

To illustrate, have a look at the table below. You will see that there is no correspondence between the code for an upper case letter and the corresponding lower case one. They are not consecutive, they are represented by completely different codes (table source):

                                     enter image description here

In other words, while a and A may seem like the same thing to you, they do not to a computer.

terdon
  • 242,166
  • That's also indeed a nice way to explain this. – Kiwy Mar 26 '14 at 08:14
  • There is a clear correspondence: A vs a, B vs. b, etc. each share 7 out of 8 bits. A single bit—2⁵—tells you uppercase or lowercase. The table is even arranged show the clear correspondence.... – derobert Mar 26 '14 at 18:05
  • @derobert dammit, I knew some hardcore coder would come and spoil my beautiful logic :). Anyway, yes of course there is a "correspondence" that's how case insensitive file systems work, the point I'm making is that the computer does not see characters but numbers, so the correspondence needs to be worked out, it is not quite a simple as you or I knowing that A and a are the same letter. – terdon Mar 26 '14 at 18:08
  • Sure. And historically, maybe this is why Unix was case-sensitive. But now it's just calling a different library function. The performance difference for comparing option strings is irrelevant. The only reason now is tradition. – derobert Mar 26 '14 at 18:17