Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm curious - is there a difference between ls -l and ls -lllllllllllllllllllllllllllll?

The output appears to be the same and I'm confused on why ls allows duplicate switches. Is this a standard practice among most commands?

share|improve this question

4 Answers 4

up vote 16 down vote accepted

Short answer:

Because it's programmed to ignore multiple uses of a flag.

Long answer:

As you can see in the source code of ls, there is a part with the function getopt_long() and a huge switch case:

1648       int c = getopt_long (argc, argv,
1649                            "abcdfghiklmnopqrstuvw:xABCDFGHI:LNQRST:UXZ1",
1650                            long_options, &oi);
      ....
1654       switch (c)
1655         {
      ....
1707         case 'l':
1708           format = long_format;
1709           break;
      ....
1964     }

The function getopt_long() reads all paramters given to the program. In case if -l the variable format is set. So when you type multiple -lllllllll that variable is set multiple times, but that does not change anything.

Well, it changes one thing. This huge switch case statement must run through multiple times, because of multiple -l flags. ls needs longer to complete with multiple -l flags. But this time is not worth mentioning. =)

share|improve this answer
11  
Or to put it another way, rejecting them would be more work for the programmer than ignoring them. –  Mark Aug 8 at 19:39
1  
+0.5 for saying what I was going to say, +0.5 for going to the source. –  Michael Kjörling Aug 9 at 22:01

Because it's the right thing to do. Suppose you had a script doing something like:

ls $LS_OPTIONS -l "$dir"

where it's possible that $LS_OPTIONS already contains -l. It would be counter-intuitive and annoying for this command to produce an error and would require extra logic in the script to avoid it.

-l may not be the best example for this, but hopefully you can see how the concept applies in general. A much better example is compiler options in $CFLAGS that might duplicate explicit options in a particular invocation of the compiler.

share|improve this answer
3  
The same thing could also happen if you had defined an alias which call ls with some set of options. –  kasperd Aug 9 at 6:35
    
@kasperd: Yes. Although putting -l in your ls alias seems like a bad idea, the same issue is likely to arise with options that are nice in an interactive ls alias like -p or --color=auto. –  R.. Aug 9 at 14:57
    
The alias doesn't have to be called ls. ll might be an alias for ls -l, and on a system with that alias, I might type ll -lart. –  kasperd Aug 9 at 15:10

ls is not a bash command, but a separate executable that you happen to launch from bash. That said, -l is just a type of Boolean flag, which if present causes ls to use a long-style format for the output. Most programs will simply ignore multiple uses (ls -ll is the same as ls -l -l) of such flags, although there are some exceptions (as an example, if -v means 'verbose', then a program may interpret multiple uses to mean "be even more verbose").

share|improve this answer
2  
An example of -vvv is ssh. –  Bernhard Aug 8 at 18:49
    
Or even aptitude moo –  Ruslan Aug 9 at 14:01

Shell aliases would be pretty annoying if commands like ls did not allow repeated options.

Suppose you had

alias ls='ls --color=auto'
alias rm='rm -i'

Then, if conflicting flags were not allowed, it would be an error to issue commands like ls --color=never or ls --color=auto or rm -i.

Therefore, these commands are designed to let later flags override earlier ones.

share|improve this answer
    
Conflicting switches are sometimes disallowed. (Try rsync with both --inplace and --delay-updates, for example.) Some tools just take whatever comes last; rm -if is probably a good example there. But there is no conflict in ls's -l option, hence ls -l and ls -ll is not a problem, and it does not affect execution in any significant manner. Computers are good at mind-numbing repetition. –  Michael Kjörling Aug 9 at 22:03

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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