What's the difference between one-dash and two-dashes for command prompt parameters?












61















I was wondering why is it that some programs requires their command prompt parameters to have two dashes in front whereas some (most) only require one dash in front?



For example most programs look like this: relaxer -dtd toc.xml toc_gr.xml toc_jp.xml



Whereas some programs look like this: xmllint --valid toc.xml --noout



What's the reason that some requires two dashes instead of one? Doesn't it make sense for everyone to stick to one standard (i.e. a single dash will do).










share|improve this question




















  • 10





    > Doesn't it make sense for everyone to stick to one standard – yes. Do all programmers stick to standards and keep consistency? No. Many programmers can't even maintain consistency within their programs :) That being said, the consensus would be to use one dash only for one-letter options, and two dashes for all that are actually words, e.g. -i vs. --input or -n --dry-run.

    – slhck
    Dec 28 '11 at 7:44






  • 1





    @slhck Heys thanks for the help =) By that convention then, does it mean that the -dtd should really have been --dtd ? Effectively what I was wondering about is what does the dash (and double-dash) trying to signify ?

    – Pacerier
    Dec 28 '11 at 7:50








  • 6





    For bonus points: programs conforming to the Gnu standards for --long-options will accept any unique abbreviation as well. So, for a program with options --file-in and --file-out, you could use --file-o=foo or --file-i=foo, which can save some typing for --very-long-optional-parameters.

    – BRPocock
    Dec 28 '11 at 14:41











  • GNU came along with their convention of using two dashes for "long" options, which I happen to prefer, but many older utilities, such as those bundled with the X Window System, as well as ImageMagick (e.g., convert, mogrify) have "long" options using only a single dash. For example: xterm -fn 6x10 -geometry 80x24+30+200. Abbreviations are supported, provided they're distinct (e.g., -g or -geom for -geometry). See X(7) for other examples.

    – TheDudeAbides
    Jan 23 at 0:09


















61















I was wondering why is it that some programs requires their command prompt parameters to have two dashes in front whereas some (most) only require one dash in front?



For example most programs look like this: relaxer -dtd toc.xml toc_gr.xml toc_jp.xml



Whereas some programs look like this: xmllint --valid toc.xml --noout



What's the reason that some requires two dashes instead of one? Doesn't it make sense for everyone to stick to one standard (i.e. a single dash will do).










share|improve this question




















  • 10





    > Doesn't it make sense for everyone to stick to one standard – yes. Do all programmers stick to standards and keep consistency? No. Many programmers can't even maintain consistency within their programs :) That being said, the consensus would be to use one dash only for one-letter options, and two dashes for all that are actually words, e.g. -i vs. --input or -n --dry-run.

    – slhck
    Dec 28 '11 at 7:44






  • 1





    @slhck Heys thanks for the help =) By that convention then, does it mean that the -dtd should really have been --dtd ? Effectively what I was wondering about is what does the dash (and double-dash) trying to signify ?

    – Pacerier
    Dec 28 '11 at 7:50








  • 6





    For bonus points: programs conforming to the Gnu standards for --long-options will accept any unique abbreviation as well. So, for a program with options --file-in and --file-out, you could use --file-o=foo or --file-i=foo, which can save some typing for --very-long-optional-parameters.

    – BRPocock
    Dec 28 '11 at 14:41











  • GNU came along with their convention of using two dashes for "long" options, which I happen to prefer, but many older utilities, such as those bundled with the X Window System, as well as ImageMagick (e.g., convert, mogrify) have "long" options using only a single dash. For example: xterm -fn 6x10 -geometry 80x24+30+200. Abbreviations are supported, provided they're distinct (e.g., -g or -geom for -geometry). See X(7) for other examples.

    – TheDudeAbides
    Jan 23 at 0:09
















61












61








61


18






I was wondering why is it that some programs requires their command prompt parameters to have two dashes in front whereas some (most) only require one dash in front?



For example most programs look like this: relaxer -dtd toc.xml toc_gr.xml toc_jp.xml



Whereas some programs look like this: xmllint --valid toc.xml --noout



What's the reason that some requires two dashes instead of one? Doesn't it make sense for everyone to stick to one standard (i.e. a single dash will do).










share|improve this question
















I was wondering why is it that some programs requires their command prompt parameters to have two dashes in front whereas some (most) only require one dash in front?



For example most programs look like this: relaxer -dtd toc.xml toc_gr.xml toc_jp.xml



Whereas some programs look like this: xmllint --valid toc.xml --noout



What's the reason that some requires two dashes instead of one? Doesn't it make sense for everyone to stick to one standard (i.e. a single dash will do).







linux windows command-line unix






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 23 at 1:33









TheDudeAbides

36349




36349










asked Dec 28 '11 at 7:02









PacerierPacerier

11.2k62153242




11.2k62153242








  • 10





    > Doesn't it make sense for everyone to stick to one standard – yes. Do all programmers stick to standards and keep consistency? No. Many programmers can't even maintain consistency within their programs :) That being said, the consensus would be to use one dash only for one-letter options, and two dashes for all that are actually words, e.g. -i vs. --input or -n --dry-run.

    – slhck
    Dec 28 '11 at 7:44






  • 1





    @slhck Heys thanks for the help =) By that convention then, does it mean that the -dtd should really have been --dtd ? Effectively what I was wondering about is what does the dash (and double-dash) trying to signify ?

    – Pacerier
    Dec 28 '11 at 7:50








  • 6





    For bonus points: programs conforming to the Gnu standards for --long-options will accept any unique abbreviation as well. So, for a program with options --file-in and --file-out, you could use --file-o=foo or --file-i=foo, which can save some typing for --very-long-optional-parameters.

    – BRPocock
    Dec 28 '11 at 14:41











  • GNU came along with their convention of using two dashes for "long" options, which I happen to prefer, but many older utilities, such as those bundled with the X Window System, as well as ImageMagick (e.g., convert, mogrify) have "long" options using only a single dash. For example: xterm -fn 6x10 -geometry 80x24+30+200. Abbreviations are supported, provided they're distinct (e.g., -g or -geom for -geometry). See X(7) for other examples.

    – TheDudeAbides
    Jan 23 at 0:09
















  • 10





    > Doesn't it make sense for everyone to stick to one standard – yes. Do all programmers stick to standards and keep consistency? No. Many programmers can't even maintain consistency within their programs :) That being said, the consensus would be to use one dash only for one-letter options, and two dashes for all that are actually words, e.g. -i vs. --input or -n --dry-run.

    – slhck
    Dec 28 '11 at 7:44






  • 1





    @slhck Heys thanks for the help =) By that convention then, does it mean that the -dtd should really have been --dtd ? Effectively what I was wondering about is what does the dash (and double-dash) trying to signify ?

    – Pacerier
    Dec 28 '11 at 7:50








  • 6





    For bonus points: programs conforming to the Gnu standards for --long-options will accept any unique abbreviation as well. So, for a program with options --file-in and --file-out, you could use --file-o=foo or --file-i=foo, which can save some typing for --very-long-optional-parameters.

    – BRPocock
    Dec 28 '11 at 14:41











  • GNU came along with their convention of using two dashes for "long" options, which I happen to prefer, but many older utilities, such as those bundled with the X Window System, as well as ImageMagick (e.g., convert, mogrify) have "long" options using only a single dash. For example: xterm -fn 6x10 -geometry 80x24+30+200. Abbreviations are supported, provided they're distinct (e.g., -g or -geom for -geometry). See X(7) for other examples.

    – TheDudeAbides
    Jan 23 at 0:09










10




10





> Doesn't it make sense for everyone to stick to one standard – yes. Do all programmers stick to standards and keep consistency? No. Many programmers can't even maintain consistency within their programs :) That being said, the consensus would be to use one dash only for one-letter options, and two dashes for all that are actually words, e.g. -i vs. --input or -n --dry-run.

– slhck
Dec 28 '11 at 7:44





> Doesn't it make sense for everyone to stick to one standard – yes. Do all programmers stick to standards and keep consistency? No. Many programmers can't even maintain consistency within their programs :) That being said, the consensus would be to use one dash only for one-letter options, and two dashes for all that are actually words, e.g. -i vs. --input or -n --dry-run.

– slhck
Dec 28 '11 at 7:44




1




1





@slhck Heys thanks for the help =) By that convention then, does it mean that the -dtd should really have been --dtd ? Effectively what I was wondering about is what does the dash (and double-dash) trying to signify ?

– Pacerier
Dec 28 '11 at 7:50







@slhck Heys thanks for the help =) By that convention then, does it mean that the -dtd should really have been --dtd ? Effectively what I was wondering about is what does the dash (and double-dash) trying to signify ?

– Pacerier
Dec 28 '11 at 7:50






6




6





For bonus points: programs conforming to the Gnu standards for --long-options will accept any unique abbreviation as well. So, for a program with options --file-in and --file-out, you could use --file-o=foo or --file-i=foo, which can save some typing for --very-long-optional-parameters.

– BRPocock
Dec 28 '11 at 14:41





For bonus points: programs conforming to the Gnu standards for --long-options will accept any unique abbreviation as well. So, for a program with options --file-in and --file-out, you could use --file-o=foo or --file-i=foo, which can save some typing for --very-long-optional-parameters.

– BRPocock
Dec 28 '11 at 14:41













GNU came along with their convention of using two dashes for "long" options, which I happen to prefer, but many older utilities, such as those bundled with the X Window System, as well as ImageMagick (e.g., convert, mogrify) have "long" options using only a single dash. For example: xterm -fn 6x10 -geometry 80x24+30+200. Abbreviations are supported, provided they're distinct (e.g., -g or -geom for -geometry). See X(7) for other examples.

– TheDudeAbides
Jan 23 at 0:09







GNU came along with their convention of using two dashes for "long" options, which I happen to prefer, but many older utilities, such as those bundled with the X Window System, as well as ImageMagick (e.g., convert, mogrify) have "long" options using only a single dash. For example: xterm -fn 6x10 -geometry 80x24+30+200. Abbreviations are supported, provided they're distinct (e.g., -g or -geom for -geometry). See X(7) for other examples.

– TheDudeAbides
Jan 23 at 0:09












5 Answers
5






active

oldest

votes


















16














Just do ls --help
and look at the options; it should be obvious to you.



It has nothing to do with parameters at all.
Many options have a short form and a long form, and many have one and not the other.



And also, regarding parameters, it's simply that in the long form when they take a parameter it looks like it's always with an equals. But obviously short ones can take parameters just as much; just they don't use an equals.



Here is an extract from ls --help (man ls gives equivalent information). Notice how some have a long form without a short form (--author, --block-size), some have a short form without a long form (-c, -f, -g), and some have both a long form and a short form (-A/--almost-all, -b/--escape).



 -a, --all                  do not ignore entries starting with .
-A, --almost-all do not list implied . and ..
--author with -l, print the author of each file
-b, --escape print octal escapes for nongraphic characters
--block-size=SIZE use SIZE-byte blocks
-B, --ignore-backups do not list implied entries ending with ~
-c with -lt: sort by, and show, ctime (time of last
modification of file status information)
with -l: show ctime and sort by name
otherwise: sort by ctime
-C list entries by columns
--color[=WHEN] control whether color is used to distinguish file
types. WHEN may be `never', `always', or `auto'





share|improve this answer





















  • 4





    How do we do a ls --help on windows?

    – Pacerier
    Dec 29 '11 at 4:34








  • 1





    @Pacerier There is no ls on Windows. The equivalent command would be dir /?. You are using cross-platform software that violates the usual Windows conventions, see my answer.

    – Daniel Beck
    Dec 29 '11 at 10:58













  • @Pacerier It's not built in, but download it 3rd party, Gnuwin32 you download it(google gnuwin32). there are a bunch of packages within gnuwin32 each with commands, download the coreutils package, that has many common commands.

    – barlop
    Dec 29 '11 at 20:00













  • There are long options without short options in your ls --help excerpt. See --author and --block-size.

    – Dan
    Oct 11 '13 at 17:34











  • @Dan thanks, i've just added that.

    – barlop
    Oct 11 '13 at 18:04



















33














There is no widespread standard. There's some consistency e.g. in GNU programs, but you need to check each program's documentation.



Quoting Wikipedia, emphasis mine:




In Unix-like systems, the ASCII hyphen–minus is commonly used to specify options. The character is usually followed by one or more letters. An argument that is a single hyphen–minus by itself without any letters usually specifies that a program should handle data coming from the standard input or send data to the standard output. Two hyphen–minus characters ( -- ) are used on some programs to specify "long options" where more descriptive option names are used. This is a common feature of GNU software.




Usually, hyphens indicate a predefined argument. I think it's used to differentiate them from e.g. file names or other labels you might use as arguments. That's not always the case, though (see below).





You'll often find the same argument available both as short and long option, as e.g. in ls.



Some programs use a single hyphen for one-character options, and two hyphens for multi-character options, but not all (GNU find comes to mind). Some programs have optional hyphens or skip them altogether (tar or BSD ps come to mind).



Sometimes long options (--foo) require arguments, while short options (-f) don't (or at least imply a specific default argument).



Short options (e.g. cut -d ' ') can have arguments , while long options (e.g. ls --all) don't necessarily have them.



To set a particular behavior of a program, you sometimes need to use a short option, for others you need to use a long option, and for some you have a choice.



On a related note, some programs can handle no whitespace between an option and its argument, while others can't.



As I wrote at the beginning, there just is no common behavior or standard. Often you can trace similar behavior to the same library used for argument parsing, but you probably don't want to read the sources to find this out.



You really cannot infer one program's argument syntax from another's.





If you also consider Windows, it gets even worse: While the Windows command line calls traditionally use /f (at least most of the time, single characters) for options, with : as the separator between options and their value (see e.g. here); cross-platform utilities are widespread (such as those you mention) and bring along the more common hyphen syntax for arguments, with all the inconsistencies mentioned above.






share|improve this answer





















  • 2





    It should be noted that the GNU standard libraries provide the functionality of mapping the one-minus-one-letter, two-minus-multi-letter options, so all new GNU programs and most new free software in general uses this notation (e.g. -f, -f foo, --file, --file foo, --file=foo, --fil=foo, --fi=foo); throwbacks such as tar, ps, find and such had their command-line syntax set by POSIX before this standard had completely gelled. On a Gnu/Linux system, it's a reasonably safe bet that at least --help will (almost) always be supported, as well as man <command> or info <command>

    – BRPocock
    Dec 28 '11 at 14:39











  • does the GNU standard say that you shouldn't have a short form without a long form and shouldn't have a long without a short form?

    – barlop
    Nov 4 '13 at 11:52











  • +1 for being the most complete answer, including mention of GNU find which does not follow the "GNU convention" for long options (probably for reasons of POSIX compliance, as @BRPocock pointed out). I would +1 again if I could, for mentioning DOS/Windows command line "switches," since the OP's question somehow got tagged "windows," and that convention should be mentioned for completeness.

    – TheDudeAbides
    Jan 23 at 0:24





















7














This is a convention coming from *nix. Double hyphen precedes options when they are written in full, , while single hyphen precedes options when they are written in short form. For example ls --all --l, can be shortened to ls -al. As it is seen, not all options have their single letter equivalents, although more used ones usually do.



Whether the option takes an argument doesn't really make a difference - it can either take them, or not take them, regardless of the way you enter the option.



When writing them for one time usage, it doesn't really matter, but when writing commands for example in .alias files, it is customary to use the full-form. Purely for the ease of reading for the next person.






share|improve this answer
























  • Heys thanks for the help, Btw is there a reason you type unix as *nix ?

    – Pacerier
    Dec 28 '11 at 13:29








  • 2





    @Pacerier - Unix is a trade name. By typing *nix I actually refer to all unix and similar systems, which for all practical purposes, are the same. But mostly, it's a force of habit ...

    – Rook
    Dec 28 '11 at 13:51






  • 2





    @Pacerier *nix can refer to Linux, or Unix. I'm not totally sure on this 'cos was a while back that I looked into it, but Technically, if I recall, BSD is from the Unix family. Linux technically isn't.. and neither is FreeBSD. But saying *nix would include unix/bsd, and anything like it, e.g. linux and freebsd.

    – barlop
    Dec 29 '11 at 20:08






  • 2





    +1 for mentioning shorthand command combining. that's the real reason why there's two styles.

    – Ryan_S
    Sep 23 '15 at 17:22



















3














these are conventional UNIX syntaxes,



a program argument takes one hyphen ("-") followed with a single letter when it's a simple option (e.g: -v) and two hyphen ("--") when the option takes arguments (e.g: --file toc.xml or --file=toc.xml )



no impact on the program's functionality.






share|improve this answer



















  • 3





    Also, in many cases with single letter options following a single dash, you can group the letters together. For example, "ls -al" is the same as "ls -a -l". Double-dash options cannot be combined in this way. Single-letter options are an older standard, but these days many commands will take both types. E.g. "ls --all" is the same as "ls -a".

    – Randy Orrison
    Dec 28 '11 at 9:20








  • 2





    Actually, another correction. Single-dash single-letter options can take a parameter, but it's usually not linked with an equals sign. For example, "tail -n 50" shows the last 50 lines of a file, equivalent to "tail --lines=50".

    – Randy Orrison
    Dec 28 '11 at 9:22













  • By this convention, does it mean that --noout (in the question above) should really have been written as -noout since it doesn't have arguments ?

    – Pacerier
    Dec 28 '11 at 10:27








  • 1





    what is said in this answer about parameters is totally wrong. The first sentence is obvious. The last sentence is obvious. And the paragraph in the middle that should answer the question, is totally wrong.

    – barlop
    Dec 28 '11 at 17:03













  • @RandyOrrison when a single letter i've never seen an equals sign.. and to elaborate on your point, they often take parameters.. wget -w 10 head -n 3 cut -b 2 And look at Ping -? !! Loads take parameters. This answer is terrible

    – barlop
    Dec 28 '11 at 17:06





















3














single dash is implemented by the getopt and is posix standard function, double dash in getopt_long and is a gnu standard.



Traditionally, a single dash supplies a single character option like this:



-A or -V etc but need not be limited to that. e.g. -Wall for gcc turns on all compiler warnings for the gcc compiler command.



double dash arguments tend to be more verbose and often take a supplied parameter like
--max-count=NUM. However, --version takes no equals.



Generally speaking, there are no rules or defined standards around how program arguments should be specified, just a bunch of traditions. However, if the getopt and getopt_long command line parsing functions are used then the parameters should generally follow the standard as the library functions enforce a certain way of doing it.






share|improve this answer























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "3"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f372203%2fwhats-the-difference-between-one-dash-and-two-dashes-for-command-prompt-paramet%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    5 Answers
    5






    active

    oldest

    votes








    5 Answers
    5






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    16














    Just do ls --help
    and look at the options; it should be obvious to you.



    It has nothing to do with parameters at all.
    Many options have a short form and a long form, and many have one and not the other.



    And also, regarding parameters, it's simply that in the long form when they take a parameter it looks like it's always with an equals. But obviously short ones can take parameters just as much; just they don't use an equals.



    Here is an extract from ls --help (man ls gives equivalent information). Notice how some have a long form without a short form (--author, --block-size), some have a short form without a long form (-c, -f, -g), and some have both a long form and a short form (-A/--almost-all, -b/--escape).



     -a, --all                  do not ignore entries starting with .
    -A, --almost-all do not list implied . and ..
    --author with -l, print the author of each file
    -b, --escape print octal escapes for nongraphic characters
    --block-size=SIZE use SIZE-byte blocks
    -B, --ignore-backups do not list implied entries ending with ~
    -c with -lt: sort by, and show, ctime (time of last
    modification of file status information)
    with -l: show ctime and sort by name
    otherwise: sort by ctime
    -C list entries by columns
    --color[=WHEN] control whether color is used to distinguish file
    types. WHEN may be `never', `always', or `auto'





    share|improve this answer





















    • 4





      How do we do a ls --help on windows?

      – Pacerier
      Dec 29 '11 at 4:34








    • 1





      @Pacerier There is no ls on Windows. The equivalent command would be dir /?. You are using cross-platform software that violates the usual Windows conventions, see my answer.

      – Daniel Beck
      Dec 29 '11 at 10:58













    • @Pacerier It's not built in, but download it 3rd party, Gnuwin32 you download it(google gnuwin32). there are a bunch of packages within gnuwin32 each with commands, download the coreutils package, that has many common commands.

      – barlop
      Dec 29 '11 at 20:00













    • There are long options without short options in your ls --help excerpt. See --author and --block-size.

      – Dan
      Oct 11 '13 at 17:34











    • @Dan thanks, i've just added that.

      – barlop
      Oct 11 '13 at 18:04
















    16














    Just do ls --help
    and look at the options; it should be obvious to you.



    It has nothing to do with parameters at all.
    Many options have a short form and a long form, and many have one and not the other.



    And also, regarding parameters, it's simply that in the long form when they take a parameter it looks like it's always with an equals. But obviously short ones can take parameters just as much; just they don't use an equals.



    Here is an extract from ls --help (man ls gives equivalent information). Notice how some have a long form without a short form (--author, --block-size), some have a short form without a long form (-c, -f, -g), and some have both a long form and a short form (-A/--almost-all, -b/--escape).



     -a, --all                  do not ignore entries starting with .
    -A, --almost-all do not list implied . and ..
    --author with -l, print the author of each file
    -b, --escape print octal escapes for nongraphic characters
    --block-size=SIZE use SIZE-byte blocks
    -B, --ignore-backups do not list implied entries ending with ~
    -c with -lt: sort by, and show, ctime (time of last
    modification of file status information)
    with -l: show ctime and sort by name
    otherwise: sort by ctime
    -C list entries by columns
    --color[=WHEN] control whether color is used to distinguish file
    types. WHEN may be `never', `always', or `auto'





    share|improve this answer





















    • 4





      How do we do a ls --help on windows?

      – Pacerier
      Dec 29 '11 at 4:34








    • 1





      @Pacerier There is no ls on Windows. The equivalent command would be dir /?. You are using cross-platform software that violates the usual Windows conventions, see my answer.

      – Daniel Beck
      Dec 29 '11 at 10:58













    • @Pacerier It's not built in, but download it 3rd party, Gnuwin32 you download it(google gnuwin32). there are a bunch of packages within gnuwin32 each with commands, download the coreutils package, that has many common commands.

      – barlop
      Dec 29 '11 at 20:00













    • There are long options without short options in your ls --help excerpt. See --author and --block-size.

      – Dan
      Oct 11 '13 at 17:34











    • @Dan thanks, i've just added that.

      – barlop
      Oct 11 '13 at 18:04














    16












    16








    16







    Just do ls --help
    and look at the options; it should be obvious to you.



    It has nothing to do with parameters at all.
    Many options have a short form and a long form, and many have one and not the other.



    And also, regarding parameters, it's simply that in the long form when they take a parameter it looks like it's always with an equals. But obviously short ones can take parameters just as much; just they don't use an equals.



    Here is an extract from ls --help (man ls gives equivalent information). Notice how some have a long form without a short form (--author, --block-size), some have a short form without a long form (-c, -f, -g), and some have both a long form and a short form (-A/--almost-all, -b/--escape).



     -a, --all                  do not ignore entries starting with .
    -A, --almost-all do not list implied . and ..
    --author with -l, print the author of each file
    -b, --escape print octal escapes for nongraphic characters
    --block-size=SIZE use SIZE-byte blocks
    -B, --ignore-backups do not list implied entries ending with ~
    -c with -lt: sort by, and show, ctime (time of last
    modification of file status information)
    with -l: show ctime and sort by name
    otherwise: sort by ctime
    -C list entries by columns
    --color[=WHEN] control whether color is used to distinguish file
    types. WHEN may be `never', `always', or `auto'





    share|improve this answer















    Just do ls --help
    and look at the options; it should be obvious to you.



    It has nothing to do with parameters at all.
    Many options have a short form and a long form, and many have one and not the other.



    And also, regarding parameters, it's simply that in the long form when they take a parameter it looks like it's always with an equals. But obviously short ones can take parameters just as much; just they don't use an equals.



    Here is an extract from ls --help (man ls gives equivalent information). Notice how some have a long form without a short form (--author, --block-size), some have a short form without a long form (-c, -f, -g), and some have both a long form and a short form (-A/--almost-all, -b/--escape).



     -a, --all                  do not ignore entries starting with .
    -A, --almost-all do not list implied . and ..
    --author with -l, print the author of each file
    -b, --escape print octal escapes for nongraphic characters
    --block-size=SIZE use SIZE-byte blocks
    -B, --ignore-backups do not list implied entries ending with ~
    -c with -lt: sort by, and show, ctime (time of last
    modification of file status information)
    with -l: show ctime and sort by name
    otherwise: sort by ctime
    -C list entries by columns
    --color[=WHEN] control whether color is used to distinguish file
    types. WHEN may be `never', `always', or `auto'






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jan 23 at 6:41









    Scott

    15.8k113990




    15.8k113990










    answered Dec 28 '11 at 17:01









    barlopbarlop

    15.5k2589149




    15.5k2589149








    • 4





      How do we do a ls --help on windows?

      – Pacerier
      Dec 29 '11 at 4:34








    • 1





      @Pacerier There is no ls on Windows. The equivalent command would be dir /?. You are using cross-platform software that violates the usual Windows conventions, see my answer.

      – Daniel Beck
      Dec 29 '11 at 10:58













    • @Pacerier It's not built in, but download it 3rd party, Gnuwin32 you download it(google gnuwin32). there are a bunch of packages within gnuwin32 each with commands, download the coreutils package, that has many common commands.

      – barlop
      Dec 29 '11 at 20:00













    • There are long options without short options in your ls --help excerpt. See --author and --block-size.

      – Dan
      Oct 11 '13 at 17:34











    • @Dan thanks, i've just added that.

      – barlop
      Oct 11 '13 at 18:04














    • 4





      How do we do a ls --help on windows?

      – Pacerier
      Dec 29 '11 at 4:34








    • 1





      @Pacerier There is no ls on Windows. The equivalent command would be dir /?. You are using cross-platform software that violates the usual Windows conventions, see my answer.

      – Daniel Beck
      Dec 29 '11 at 10:58













    • @Pacerier It's not built in, but download it 3rd party, Gnuwin32 you download it(google gnuwin32). there are a bunch of packages within gnuwin32 each with commands, download the coreutils package, that has many common commands.

      – barlop
      Dec 29 '11 at 20:00













    • There are long options without short options in your ls --help excerpt. See --author and --block-size.

      – Dan
      Oct 11 '13 at 17:34











    • @Dan thanks, i've just added that.

      – barlop
      Oct 11 '13 at 18:04








    4




    4





    How do we do a ls --help on windows?

    – Pacerier
    Dec 29 '11 at 4:34







    How do we do a ls --help on windows?

    – Pacerier
    Dec 29 '11 at 4:34






    1




    1





    @Pacerier There is no ls on Windows. The equivalent command would be dir /?. You are using cross-platform software that violates the usual Windows conventions, see my answer.

    – Daniel Beck
    Dec 29 '11 at 10:58







    @Pacerier There is no ls on Windows. The equivalent command would be dir /?. You are using cross-platform software that violates the usual Windows conventions, see my answer.

    – Daniel Beck
    Dec 29 '11 at 10:58















    @Pacerier It's not built in, but download it 3rd party, Gnuwin32 you download it(google gnuwin32). there are a bunch of packages within gnuwin32 each with commands, download the coreutils package, that has many common commands.

    – barlop
    Dec 29 '11 at 20:00







    @Pacerier It's not built in, but download it 3rd party, Gnuwin32 you download it(google gnuwin32). there are a bunch of packages within gnuwin32 each with commands, download the coreutils package, that has many common commands.

    – barlop
    Dec 29 '11 at 20:00















    There are long options without short options in your ls --help excerpt. See --author and --block-size.

    – Dan
    Oct 11 '13 at 17:34





    There are long options without short options in your ls --help excerpt. See --author and --block-size.

    – Dan
    Oct 11 '13 at 17:34













    @Dan thanks, i've just added that.

    – barlop
    Oct 11 '13 at 18:04





    @Dan thanks, i've just added that.

    – barlop
    Oct 11 '13 at 18:04













    33














    There is no widespread standard. There's some consistency e.g. in GNU programs, but you need to check each program's documentation.



    Quoting Wikipedia, emphasis mine:




    In Unix-like systems, the ASCII hyphen–minus is commonly used to specify options. The character is usually followed by one or more letters. An argument that is a single hyphen–minus by itself without any letters usually specifies that a program should handle data coming from the standard input or send data to the standard output. Two hyphen–minus characters ( -- ) are used on some programs to specify "long options" where more descriptive option names are used. This is a common feature of GNU software.




    Usually, hyphens indicate a predefined argument. I think it's used to differentiate them from e.g. file names or other labels you might use as arguments. That's not always the case, though (see below).





    You'll often find the same argument available both as short and long option, as e.g. in ls.



    Some programs use a single hyphen for one-character options, and two hyphens for multi-character options, but not all (GNU find comes to mind). Some programs have optional hyphens or skip them altogether (tar or BSD ps come to mind).



    Sometimes long options (--foo) require arguments, while short options (-f) don't (or at least imply a specific default argument).



    Short options (e.g. cut -d ' ') can have arguments , while long options (e.g. ls --all) don't necessarily have them.



    To set a particular behavior of a program, you sometimes need to use a short option, for others you need to use a long option, and for some you have a choice.



    On a related note, some programs can handle no whitespace between an option and its argument, while others can't.



    As I wrote at the beginning, there just is no common behavior or standard. Often you can trace similar behavior to the same library used for argument parsing, but you probably don't want to read the sources to find this out.



    You really cannot infer one program's argument syntax from another's.





    If you also consider Windows, it gets even worse: While the Windows command line calls traditionally use /f (at least most of the time, single characters) for options, with : as the separator between options and their value (see e.g. here); cross-platform utilities are widespread (such as those you mention) and bring along the more common hyphen syntax for arguments, with all the inconsistencies mentioned above.






    share|improve this answer





















    • 2





      It should be noted that the GNU standard libraries provide the functionality of mapping the one-minus-one-letter, two-minus-multi-letter options, so all new GNU programs and most new free software in general uses this notation (e.g. -f, -f foo, --file, --file foo, --file=foo, --fil=foo, --fi=foo); throwbacks such as tar, ps, find and such had their command-line syntax set by POSIX before this standard had completely gelled. On a Gnu/Linux system, it's a reasonably safe bet that at least --help will (almost) always be supported, as well as man <command> or info <command>

      – BRPocock
      Dec 28 '11 at 14:39











    • does the GNU standard say that you shouldn't have a short form without a long form and shouldn't have a long without a short form?

      – barlop
      Nov 4 '13 at 11:52











    • +1 for being the most complete answer, including mention of GNU find which does not follow the "GNU convention" for long options (probably for reasons of POSIX compliance, as @BRPocock pointed out). I would +1 again if I could, for mentioning DOS/Windows command line "switches," since the OP's question somehow got tagged "windows," and that convention should be mentioned for completeness.

      – TheDudeAbides
      Jan 23 at 0:24


















    33














    There is no widespread standard. There's some consistency e.g. in GNU programs, but you need to check each program's documentation.



    Quoting Wikipedia, emphasis mine:




    In Unix-like systems, the ASCII hyphen–minus is commonly used to specify options. The character is usually followed by one or more letters. An argument that is a single hyphen–minus by itself without any letters usually specifies that a program should handle data coming from the standard input or send data to the standard output. Two hyphen–minus characters ( -- ) are used on some programs to specify "long options" where more descriptive option names are used. This is a common feature of GNU software.




    Usually, hyphens indicate a predefined argument. I think it's used to differentiate them from e.g. file names or other labels you might use as arguments. That's not always the case, though (see below).





    You'll often find the same argument available both as short and long option, as e.g. in ls.



    Some programs use a single hyphen for one-character options, and two hyphens for multi-character options, but not all (GNU find comes to mind). Some programs have optional hyphens or skip them altogether (tar or BSD ps come to mind).



    Sometimes long options (--foo) require arguments, while short options (-f) don't (or at least imply a specific default argument).



    Short options (e.g. cut -d ' ') can have arguments , while long options (e.g. ls --all) don't necessarily have them.



    To set a particular behavior of a program, you sometimes need to use a short option, for others you need to use a long option, and for some you have a choice.



    On a related note, some programs can handle no whitespace between an option and its argument, while others can't.



    As I wrote at the beginning, there just is no common behavior or standard. Often you can trace similar behavior to the same library used for argument parsing, but you probably don't want to read the sources to find this out.



    You really cannot infer one program's argument syntax from another's.





    If you also consider Windows, it gets even worse: While the Windows command line calls traditionally use /f (at least most of the time, single characters) for options, with : as the separator between options and their value (see e.g. here); cross-platform utilities are widespread (such as those you mention) and bring along the more common hyphen syntax for arguments, with all the inconsistencies mentioned above.






    share|improve this answer





















    • 2





      It should be noted that the GNU standard libraries provide the functionality of mapping the one-minus-one-letter, two-minus-multi-letter options, so all new GNU programs and most new free software in general uses this notation (e.g. -f, -f foo, --file, --file foo, --file=foo, --fil=foo, --fi=foo); throwbacks such as tar, ps, find and such had their command-line syntax set by POSIX before this standard had completely gelled. On a Gnu/Linux system, it's a reasonably safe bet that at least --help will (almost) always be supported, as well as man <command> or info <command>

      – BRPocock
      Dec 28 '11 at 14:39











    • does the GNU standard say that you shouldn't have a short form without a long form and shouldn't have a long without a short form?

      – barlop
      Nov 4 '13 at 11:52











    • +1 for being the most complete answer, including mention of GNU find which does not follow the "GNU convention" for long options (probably for reasons of POSIX compliance, as @BRPocock pointed out). I would +1 again if I could, for mentioning DOS/Windows command line "switches," since the OP's question somehow got tagged "windows," and that convention should be mentioned for completeness.

      – TheDudeAbides
      Jan 23 at 0:24
















    33












    33








    33







    There is no widespread standard. There's some consistency e.g. in GNU programs, but you need to check each program's documentation.



    Quoting Wikipedia, emphasis mine:




    In Unix-like systems, the ASCII hyphen–minus is commonly used to specify options. The character is usually followed by one or more letters. An argument that is a single hyphen–minus by itself without any letters usually specifies that a program should handle data coming from the standard input or send data to the standard output. Two hyphen–minus characters ( -- ) are used on some programs to specify "long options" where more descriptive option names are used. This is a common feature of GNU software.




    Usually, hyphens indicate a predefined argument. I think it's used to differentiate them from e.g. file names or other labels you might use as arguments. That's not always the case, though (see below).





    You'll often find the same argument available both as short and long option, as e.g. in ls.



    Some programs use a single hyphen for one-character options, and two hyphens for multi-character options, but not all (GNU find comes to mind). Some programs have optional hyphens or skip them altogether (tar or BSD ps come to mind).



    Sometimes long options (--foo) require arguments, while short options (-f) don't (or at least imply a specific default argument).



    Short options (e.g. cut -d ' ') can have arguments , while long options (e.g. ls --all) don't necessarily have them.



    To set a particular behavior of a program, you sometimes need to use a short option, for others you need to use a long option, and for some you have a choice.



    On a related note, some programs can handle no whitespace between an option and its argument, while others can't.



    As I wrote at the beginning, there just is no common behavior or standard. Often you can trace similar behavior to the same library used for argument parsing, but you probably don't want to read the sources to find this out.



    You really cannot infer one program's argument syntax from another's.





    If you also consider Windows, it gets even worse: While the Windows command line calls traditionally use /f (at least most of the time, single characters) for options, with : as the separator between options and their value (see e.g. here); cross-platform utilities are widespread (such as those you mention) and bring along the more common hyphen syntax for arguments, with all the inconsistencies mentioned above.






    share|improve this answer















    There is no widespread standard. There's some consistency e.g. in GNU programs, but you need to check each program's documentation.



    Quoting Wikipedia, emphasis mine:




    In Unix-like systems, the ASCII hyphen–minus is commonly used to specify options. The character is usually followed by one or more letters. An argument that is a single hyphen–minus by itself without any letters usually specifies that a program should handle data coming from the standard input or send data to the standard output. Two hyphen–minus characters ( -- ) are used on some programs to specify "long options" where more descriptive option names are used. This is a common feature of GNU software.




    Usually, hyphens indicate a predefined argument. I think it's used to differentiate them from e.g. file names or other labels you might use as arguments. That's not always the case, though (see below).





    You'll often find the same argument available both as short and long option, as e.g. in ls.



    Some programs use a single hyphen for one-character options, and two hyphens for multi-character options, but not all (GNU find comes to mind). Some programs have optional hyphens or skip them altogether (tar or BSD ps come to mind).



    Sometimes long options (--foo) require arguments, while short options (-f) don't (or at least imply a specific default argument).



    Short options (e.g. cut -d ' ') can have arguments , while long options (e.g. ls --all) don't necessarily have them.



    To set a particular behavior of a program, you sometimes need to use a short option, for others you need to use a long option, and for some you have a choice.



    On a related note, some programs can handle no whitespace between an option and its argument, while others can't.



    As I wrote at the beginning, there just is no common behavior or standard. Often you can trace similar behavior to the same library used for argument parsing, but you probably don't want to read the sources to find this out.



    You really cannot infer one program's argument syntax from another's.





    If you also consider Windows, it gets even worse: While the Windows command line calls traditionally use /f (at least most of the time, single characters) for options, with : as the separator between options and their value (see e.g. here); cross-platform utilities are widespread (such as those you mention) and bring along the more common hyphen syntax for arguments, with all the inconsistencies mentioned above.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jan 23 at 6:39

























    answered Dec 28 '11 at 11:30









    Daniel BeckDaniel Beck

    92.8k12233286




    92.8k12233286








    • 2





      It should be noted that the GNU standard libraries provide the functionality of mapping the one-minus-one-letter, two-minus-multi-letter options, so all new GNU programs and most new free software in general uses this notation (e.g. -f, -f foo, --file, --file foo, --file=foo, --fil=foo, --fi=foo); throwbacks such as tar, ps, find and such had their command-line syntax set by POSIX before this standard had completely gelled. On a Gnu/Linux system, it's a reasonably safe bet that at least --help will (almost) always be supported, as well as man <command> or info <command>

      – BRPocock
      Dec 28 '11 at 14:39











    • does the GNU standard say that you shouldn't have a short form without a long form and shouldn't have a long without a short form?

      – barlop
      Nov 4 '13 at 11:52











    • +1 for being the most complete answer, including mention of GNU find which does not follow the "GNU convention" for long options (probably for reasons of POSIX compliance, as @BRPocock pointed out). I would +1 again if I could, for mentioning DOS/Windows command line "switches," since the OP's question somehow got tagged "windows," and that convention should be mentioned for completeness.

      – TheDudeAbides
      Jan 23 at 0:24
















    • 2





      It should be noted that the GNU standard libraries provide the functionality of mapping the one-minus-one-letter, two-minus-multi-letter options, so all new GNU programs and most new free software in general uses this notation (e.g. -f, -f foo, --file, --file foo, --file=foo, --fil=foo, --fi=foo); throwbacks such as tar, ps, find and such had their command-line syntax set by POSIX before this standard had completely gelled. On a Gnu/Linux system, it's a reasonably safe bet that at least --help will (almost) always be supported, as well as man <command> or info <command>

      – BRPocock
      Dec 28 '11 at 14:39











    • does the GNU standard say that you shouldn't have a short form without a long form and shouldn't have a long without a short form?

      – barlop
      Nov 4 '13 at 11:52











    • +1 for being the most complete answer, including mention of GNU find which does not follow the "GNU convention" for long options (probably for reasons of POSIX compliance, as @BRPocock pointed out). I would +1 again if I could, for mentioning DOS/Windows command line "switches," since the OP's question somehow got tagged "windows," and that convention should be mentioned for completeness.

      – TheDudeAbides
      Jan 23 at 0:24










    2




    2





    It should be noted that the GNU standard libraries provide the functionality of mapping the one-minus-one-letter, two-minus-multi-letter options, so all new GNU programs and most new free software in general uses this notation (e.g. -f, -f foo, --file, --file foo, --file=foo, --fil=foo, --fi=foo); throwbacks such as tar, ps, find and such had their command-line syntax set by POSIX before this standard had completely gelled. On a Gnu/Linux system, it's a reasonably safe bet that at least --help will (almost) always be supported, as well as man <command> or info <command>

    – BRPocock
    Dec 28 '11 at 14:39





    It should be noted that the GNU standard libraries provide the functionality of mapping the one-minus-one-letter, two-minus-multi-letter options, so all new GNU programs and most new free software in general uses this notation (e.g. -f, -f foo, --file, --file foo, --file=foo, --fil=foo, --fi=foo); throwbacks such as tar, ps, find and such had their command-line syntax set by POSIX before this standard had completely gelled. On a Gnu/Linux system, it's a reasonably safe bet that at least --help will (almost) always be supported, as well as man <command> or info <command>

    – BRPocock
    Dec 28 '11 at 14:39













    does the GNU standard say that you shouldn't have a short form without a long form and shouldn't have a long without a short form?

    – barlop
    Nov 4 '13 at 11:52





    does the GNU standard say that you shouldn't have a short form without a long form and shouldn't have a long without a short form?

    – barlop
    Nov 4 '13 at 11:52













    +1 for being the most complete answer, including mention of GNU find which does not follow the "GNU convention" for long options (probably for reasons of POSIX compliance, as @BRPocock pointed out). I would +1 again if I could, for mentioning DOS/Windows command line "switches," since the OP's question somehow got tagged "windows," and that convention should be mentioned for completeness.

    – TheDudeAbides
    Jan 23 at 0:24







    +1 for being the most complete answer, including mention of GNU find which does not follow the "GNU convention" for long options (probably for reasons of POSIX compliance, as @BRPocock pointed out). I would +1 again if I could, for mentioning DOS/Windows command line "switches," since the OP's question somehow got tagged "windows," and that convention should be mentioned for completeness.

    – TheDudeAbides
    Jan 23 at 0:24













    7














    This is a convention coming from *nix. Double hyphen precedes options when they are written in full, , while single hyphen precedes options when they are written in short form. For example ls --all --l, can be shortened to ls -al. As it is seen, not all options have their single letter equivalents, although more used ones usually do.



    Whether the option takes an argument doesn't really make a difference - it can either take them, or not take them, regardless of the way you enter the option.



    When writing them for one time usage, it doesn't really matter, but when writing commands for example in .alias files, it is customary to use the full-form. Purely for the ease of reading for the next person.






    share|improve this answer
























    • Heys thanks for the help, Btw is there a reason you type unix as *nix ?

      – Pacerier
      Dec 28 '11 at 13:29








    • 2





      @Pacerier - Unix is a trade name. By typing *nix I actually refer to all unix and similar systems, which for all practical purposes, are the same. But mostly, it's a force of habit ...

      – Rook
      Dec 28 '11 at 13:51






    • 2





      @Pacerier *nix can refer to Linux, or Unix. I'm not totally sure on this 'cos was a while back that I looked into it, but Technically, if I recall, BSD is from the Unix family. Linux technically isn't.. and neither is FreeBSD. But saying *nix would include unix/bsd, and anything like it, e.g. linux and freebsd.

      – barlop
      Dec 29 '11 at 20:08






    • 2





      +1 for mentioning shorthand command combining. that's the real reason why there's two styles.

      – Ryan_S
      Sep 23 '15 at 17:22
















    7














    This is a convention coming from *nix. Double hyphen precedes options when they are written in full, , while single hyphen precedes options when they are written in short form. For example ls --all --l, can be shortened to ls -al. As it is seen, not all options have their single letter equivalents, although more used ones usually do.



    Whether the option takes an argument doesn't really make a difference - it can either take them, or not take them, regardless of the way you enter the option.



    When writing them for one time usage, it doesn't really matter, but when writing commands for example in .alias files, it is customary to use the full-form. Purely for the ease of reading for the next person.






    share|improve this answer
























    • Heys thanks for the help, Btw is there a reason you type unix as *nix ?

      – Pacerier
      Dec 28 '11 at 13:29








    • 2





      @Pacerier - Unix is a trade name. By typing *nix I actually refer to all unix and similar systems, which for all practical purposes, are the same. But mostly, it's a force of habit ...

      – Rook
      Dec 28 '11 at 13:51






    • 2





      @Pacerier *nix can refer to Linux, or Unix. I'm not totally sure on this 'cos was a while back that I looked into it, but Technically, if I recall, BSD is from the Unix family. Linux technically isn't.. and neither is FreeBSD. But saying *nix would include unix/bsd, and anything like it, e.g. linux and freebsd.

      – barlop
      Dec 29 '11 at 20:08






    • 2





      +1 for mentioning shorthand command combining. that's the real reason why there's two styles.

      – Ryan_S
      Sep 23 '15 at 17:22














    7












    7








    7







    This is a convention coming from *nix. Double hyphen precedes options when they are written in full, , while single hyphen precedes options when they are written in short form. For example ls --all --l, can be shortened to ls -al. As it is seen, not all options have their single letter equivalents, although more used ones usually do.



    Whether the option takes an argument doesn't really make a difference - it can either take them, or not take them, regardless of the way you enter the option.



    When writing them for one time usage, it doesn't really matter, but when writing commands for example in .alias files, it is customary to use the full-form. Purely for the ease of reading for the next person.






    share|improve this answer













    This is a convention coming from *nix. Double hyphen precedes options when they are written in full, , while single hyphen precedes options when they are written in short form. For example ls --all --l, can be shortened to ls -al. As it is seen, not all options have their single letter equivalents, although more used ones usually do.



    Whether the option takes an argument doesn't really make a difference - it can either take them, or not take them, regardless of the way you enter the option.



    When writing them for one time usage, it doesn't really matter, but when writing commands for example in .alias files, it is customary to use the full-form. Purely for the ease of reading for the next person.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Dec 28 '11 at 11:19









    RookRook

    16.8k28108178




    16.8k28108178













    • Heys thanks for the help, Btw is there a reason you type unix as *nix ?

      – Pacerier
      Dec 28 '11 at 13:29








    • 2





      @Pacerier - Unix is a trade name. By typing *nix I actually refer to all unix and similar systems, which for all practical purposes, are the same. But mostly, it's a force of habit ...

      – Rook
      Dec 28 '11 at 13:51






    • 2





      @Pacerier *nix can refer to Linux, or Unix. I'm not totally sure on this 'cos was a while back that I looked into it, but Technically, if I recall, BSD is from the Unix family. Linux technically isn't.. and neither is FreeBSD. But saying *nix would include unix/bsd, and anything like it, e.g. linux and freebsd.

      – barlop
      Dec 29 '11 at 20:08






    • 2





      +1 for mentioning shorthand command combining. that's the real reason why there's two styles.

      – Ryan_S
      Sep 23 '15 at 17:22



















    • Heys thanks for the help, Btw is there a reason you type unix as *nix ?

      – Pacerier
      Dec 28 '11 at 13:29








    • 2





      @Pacerier - Unix is a trade name. By typing *nix I actually refer to all unix and similar systems, which for all practical purposes, are the same. But mostly, it's a force of habit ...

      – Rook
      Dec 28 '11 at 13:51






    • 2





      @Pacerier *nix can refer to Linux, or Unix. I'm not totally sure on this 'cos was a while back that I looked into it, but Technically, if I recall, BSD is from the Unix family. Linux technically isn't.. and neither is FreeBSD. But saying *nix would include unix/bsd, and anything like it, e.g. linux and freebsd.

      – barlop
      Dec 29 '11 at 20:08






    • 2





      +1 for mentioning shorthand command combining. that's the real reason why there's two styles.

      – Ryan_S
      Sep 23 '15 at 17:22

















    Heys thanks for the help, Btw is there a reason you type unix as *nix ?

    – Pacerier
    Dec 28 '11 at 13:29







    Heys thanks for the help, Btw is there a reason you type unix as *nix ?

    – Pacerier
    Dec 28 '11 at 13:29






    2




    2





    @Pacerier - Unix is a trade name. By typing *nix I actually refer to all unix and similar systems, which for all practical purposes, are the same. But mostly, it's a force of habit ...

    – Rook
    Dec 28 '11 at 13:51





    @Pacerier - Unix is a trade name. By typing *nix I actually refer to all unix and similar systems, which for all practical purposes, are the same. But mostly, it's a force of habit ...

    – Rook
    Dec 28 '11 at 13:51




    2




    2





    @Pacerier *nix can refer to Linux, or Unix. I'm not totally sure on this 'cos was a while back that I looked into it, but Technically, if I recall, BSD is from the Unix family. Linux technically isn't.. and neither is FreeBSD. But saying *nix would include unix/bsd, and anything like it, e.g. linux and freebsd.

    – barlop
    Dec 29 '11 at 20:08





    @Pacerier *nix can refer to Linux, or Unix. I'm not totally sure on this 'cos was a while back that I looked into it, but Technically, if I recall, BSD is from the Unix family. Linux technically isn't.. and neither is FreeBSD. But saying *nix would include unix/bsd, and anything like it, e.g. linux and freebsd.

    – barlop
    Dec 29 '11 at 20:08




    2




    2





    +1 for mentioning shorthand command combining. that's the real reason why there's two styles.

    – Ryan_S
    Sep 23 '15 at 17:22





    +1 for mentioning shorthand command combining. that's the real reason why there's two styles.

    – Ryan_S
    Sep 23 '15 at 17:22











    3














    these are conventional UNIX syntaxes,



    a program argument takes one hyphen ("-") followed with a single letter when it's a simple option (e.g: -v) and two hyphen ("--") when the option takes arguments (e.g: --file toc.xml or --file=toc.xml )



    no impact on the program's functionality.






    share|improve this answer



















    • 3





      Also, in many cases with single letter options following a single dash, you can group the letters together. For example, "ls -al" is the same as "ls -a -l". Double-dash options cannot be combined in this way. Single-letter options are an older standard, but these days many commands will take both types. E.g. "ls --all" is the same as "ls -a".

      – Randy Orrison
      Dec 28 '11 at 9:20








    • 2





      Actually, another correction. Single-dash single-letter options can take a parameter, but it's usually not linked with an equals sign. For example, "tail -n 50" shows the last 50 lines of a file, equivalent to "tail --lines=50".

      – Randy Orrison
      Dec 28 '11 at 9:22













    • By this convention, does it mean that --noout (in the question above) should really have been written as -noout since it doesn't have arguments ?

      – Pacerier
      Dec 28 '11 at 10:27








    • 1





      what is said in this answer about parameters is totally wrong. The first sentence is obvious. The last sentence is obvious. And the paragraph in the middle that should answer the question, is totally wrong.

      – barlop
      Dec 28 '11 at 17:03













    • @RandyOrrison when a single letter i've never seen an equals sign.. and to elaborate on your point, they often take parameters.. wget -w 10 head -n 3 cut -b 2 And look at Ping -? !! Loads take parameters. This answer is terrible

      – barlop
      Dec 28 '11 at 17:06


















    3














    these are conventional UNIX syntaxes,



    a program argument takes one hyphen ("-") followed with a single letter when it's a simple option (e.g: -v) and two hyphen ("--") when the option takes arguments (e.g: --file toc.xml or --file=toc.xml )



    no impact on the program's functionality.






    share|improve this answer



















    • 3





      Also, in many cases with single letter options following a single dash, you can group the letters together. For example, "ls -al" is the same as "ls -a -l". Double-dash options cannot be combined in this way. Single-letter options are an older standard, but these days many commands will take both types. E.g. "ls --all" is the same as "ls -a".

      – Randy Orrison
      Dec 28 '11 at 9:20








    • 2





      Actually, another correction. Single-dash single-letter options can take a parameter, but it's usually not linked with an equals sign. For example, "tail -n 50" shows the last 50 lines of a file, equivalent to "tail --lines=50".

      – Randy Orrison
      Dec 28 '11 at 9:22













    • By this convention, does it mean that --noout (in the question above) should really have been written as -noout since it doesn't have arguments ?

      – Pacerier
      Dec 28 '11 at 10:27








    • 1





      what is said in this answer about parameters is totally wrong. The first sentence is obvious. The last sentence is obvious. And the paragraph in the middle that should answer the question, is totally wrong.

      – barlop
      Dec 28 '11 at 17:03













    • @RandyOrrison when a single letter i've never seen an equals sign.. and to elaborate on your point, they often take parameters.. wget -w 10 head -n 3 cut -b 2 And look at Ping -? !! Loads take parameters. This answer is terrible

      – barlop
      Dec 28 '11 at 17:06
















    3












    3








    3







    these are conventional UNIX syntaxes,



    a program argument takes one hyphen ("-") followed with a single letter when it's a simple option (e.g: -v) and two hyphen ("--") when the option takes arguments (e.g: --file toc.xml or --file=toc.xml )



    no impact on the program's functionality.






    share|improve this answer













    these are conventional UNIX syntaxes,



    a program argument takes one hyphen ("-") followed with a single letter when it's a simple option (e.g: -v) and two hyphen ("--") when the option takes arguments (e.g: --file toc.xml or --file=toc.xml )



    no impact on the program's functionality.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Dec 28 '11 at 9:12







    user8228















    • 3





      Also, in many cases with single letter options following a single dash, you can group the letters together. For example, "ls -al" is the same as "ls -a -l". Double-dash options cannot be combined in this way. Single-letter options are an older standard, but these days many commands will take both types. E.g. "ls --all" is the same as "ls -a".

      – Randy Orrison
      Dec 28 '11 at 9:20








    • 2





      Actually, another correction. Single-dash single-letter options can take a parameter, but it's usually not linked with an equals sign. For example, "tail -n 50" shows the last 50 lines of a file, equivalent to "tail --lines=50".

      – Randy Orrison
      Dec 28 '11 at 9:22













    • By this convention, does it mean that --noout (in the question above) should really have been written as -noout since it doesn't have arguments ?

      – Pacerier
      Dec 28 '11 at 10:27








    • 1





      what is said in this answer about parameters is totally wrong. The first sentence is obvious. The last sentence is obvious. And the paragraph in the middle that should answer the question, is totally wrong.

      – barlop
      Dec 28 '11 at 17:03













    • @RandyOrrison when a single letter i've never seen an equals sign.. and to elaborate on your point, they often take parameters.. wget -w 10 head -n 3 cut -b 2 And look at Ping -? !! Loads take parameters. This answer is terrible

      – barlop
      Dec 28 '11 at 17:06
















    • 3





      Also, in many cases with single letter options following a single dash, you can group the letters together. For example, "ls -al" is the same as "ls -a -l". Double-dash options cannot be combined in this way. Single-letter options are an older standard, but these days many commands will take both types. E.g. "ls --all" is the same as "ls -a".

      – Randy Orrison
      Dec 28 '11 at 9:20








    • 2





      Actually, another correction. Single-dash single-letter options can take a parameter, but it's usually not linked with an equals sign. For example, "tail -n 50" shows the last 50 lines of a file, equivalent to "tail --lines=50".

      – Randy Orrison
      Dec 28 '11 at 9:22













    • By this convention, does it mean that --noout (in the question above) should really have been written as -noout since it doesn't have arguments ?

      – Pacerier
      Dec 28 '11 at 10:27








    • 1





      what is said in this answer about parameters is totally wrong. The first sentence is obvious. The last sentence is obvious. And the paragraph in the middle that should answer the question, is totally wrong.

      – barlop
      Dec 28 '11 at 17:03













    • @RandyOrrison when a single letter i've never seen an equals sign.. and to elaborate on your point, they often take parameters.. wget -w 10 head -n 3 cut -b 2 And look at Ping -? !! Loads take parameters. This answer is terrible

      – barlop
      Dec 28 '11 at 17:06










    3




    3





    Also, in many cases with single letter options following a single dash, you can group the letters together. For example, "ls -al" is the same as "ls -a -l". Double-dash options cannot be combined in this way. Single-letter options are an older standard, but these days many commands will take both types. E.g. "ls --all" is the same as "ls -a".

    – Randy Orrison
    Dec 28 '11 at 9:20







    Also, in many cases with single letter options following a single dash, you can group the letters together. For example, "ls -al" is the same as "ls -a -l". Double-dash options cannot be combined in this way. Single-letter options are an older standard, but these days many commands will take both types. E.g. "ls --all" is the same as "ls -a".

    – Randy Orrison
    Dec 28 '11 at 9:20






    2




    2





    Actually, another correction. Single-dash single-letter options can take a parameter, but it's usually not linked with an equals sign. For example, "tail -n 50" shows the last 50 lines of a file, equivalent to "tail --lines=50".

    – Randy Orrison
    Dec 28 '11 at 9:22







    Actually, another correction. Single-dash single-letter options can take a parameter, but it's usually not linked with an equals sign. For example, "tail -n 50" shows the last 50 lines of a file, equivalent to "tail --lines=50".

    – Randy Orrison
    Dec 28 '11 at 9:22















    By this convention, does it mean that --noout (in the question above) should really have been written as -noout since it doesn't have arguments ?

    – Pacerier
    Dec 28 '11 at 10:27







    By this convention, does it mean that --noout (in the question above) should really have been written as -noout since it doesn't have arguments ?

    – Pacerier
    Dec 28 '11 at 10:27






    1




    1





    what is said in this answer about parameters is totally wrong. The first sentence is obvious. The last sentence is obvious. And the paragraph in the middle that should answer the question, is totally wrong.

    – barlop
    Dec 28 '11 at 17:03







    what is said in this answer about parameters is totally wrong. The first sentence is obvious. The last sentence is obvious. And the paragraph in the middle that should answer the question, is totally wrong.

    – barlop
    Dec 28 '11 at 17:03















    @RandyOrrison when a single letter i've never seen an equals sign.. and to elaborate on your point, they often take parameters.. wget -w 10 head -n 3 cut -b 2 And look at Ping -? !! Loads take parameters. This answer is terrible

    – barlop
    Dec 28 '11 at 17:06







    @RandyOrrison when a single letter i've never seen an equals sign.. and to elaborate on your point, they often take parameters.. wget -w 10 head -n 3 cut -b 2 And look at Ping -? !! Loads take parameters. This answer is terrible

    – barlop
    Dec 28 '11 at 17:06













    3














    single dash is implemented by the getopt and is posix standard function, double dash in getopt_long and is a gnu standard.



    Traditionally, a single dash supplies a single character option like this:



    -A or -V etc but need not be limited to that. e.g. -Wall for gcc turns on all compiler warnings for the gcc compiler command.



    double dash arguments tend to be more verbose and often take a supplied parameter like
    --max-count=NUM. However, --version takes no equals.



    Generally speaking, there are no rules or defined standards around how program arguments should be specified, just a bunch of traditions. However, if the getopt and getopt_long command line parsing functions are used then the parameters should generally follow the standard as the library functions enforce a certain way of doing it.






    share|improve this answer




























      3














      single dash is implemented by the getopt and is posix standard function, double dash in getopt_long and is a gnu standard.



      Traditionally, a single dash supplies a single character option like this:



      -A or -V etc but need not be limited to that. e.g. -Wall for gcc turns on all compiler warnings for the gcc compiler command.



      double dash arguments tend to be more verbose and often take a supplied parameter like
      --max-count=NUM. However, --version takes no equals.



      Generally speaking, there are no rules or defined standards around how program arguments should be specified, just a bunch of traditions. However, if the getopt and getopt_long command line parsing functions are used then the parameters should generally follow the standard as the library functions enforce a certain way of doing it.






      share|improve this answer


























        3












        3








        3







        single dash is implemented by the getopt and is posix standard function, double dash in getopt_long and is a gnu standard.



        Traditionally, a single dash supplies a single character option like this:



        -A or -V etc but need not be limited to that. e.g. -Wall for gcc turns on all compiler warnings for the gcc compiler command.



        double dash arguments tend to be more verbose and often take a supplied parameter like
        --max-count=NUM. However, --version takes no equals.



        Generally speaking, there are no rules or defined standards around how program arguments should be specified, just a bunch of traditions. However, if the getopt and getopt_long command line parsing functions are used then the parameters should generally follow the standard as the library functions enforce a certain way of doing it.






        share|improve this answer













        single dash is implemented by the getopt and is posix standard function, double dash in getopt_long and is a gnu standard.



        Traditionally, a single dash supplies a single character option like this:



        -A or -V etc but need not be limited to that. e.g. -Wall for gcc turns on all compiler warnings for the gcc compiler command.



        double dash arguments tend to be more verbose and often take a supplied parameter like
        --max-count=NUM. However, --version takes no equals.



        Generally speaking, there are no rules or defined standards around how program arguments should be specified, just a bunch of traditions. However, if the getopt and getopt_long command line parsing functions are used then the parameters should generally follow the standard as the library functions enforce a certain way of doing it.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Dec 28 '11 at 22:41









        Matt HMatt H

        3,41822543




        3,41822543






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Super User!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f372203%2fwhats-the-difference-between-one-dash-and-two-dashes-for-command-prompt-paramet%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

            Mangá

            Eduardo VII do Reino Unido