Unix/Linux command syntax

Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
When linux commands list their usage, this usually is how they do it (for eg wget):
wget [option]... [URL]...
From what I understand of this pattern of specifying command usage, this is not the usual regex way of specifying patterns and for the wget command says that it is not mandatory to specify any options and by that logic it is not mandatory to specify any URL as well.
I mean I can directly do
wget www.google.com
and this will work. So the options are not mandatory.
If the options are not mandatory because they are in square brackets, then following through with that logic specifying a URL should not be mandatory as well and just
wget
as a command should work as well.
My question is- Is there some document where this pattern of specifying command usage is elaborated on?
command-line
add a comment |
up vote
3
down vote
favorite
When linux commands list their usage, this usually is how they do it (for eg wget):
wget [option]... [URL]...
From what I understand of this pattern of specifying command usage, this is not the usual regex way of specifying patterns and for the wget command says that it is not mandatory to specify any options and by that logic it is not mandatory to specify any URL as well.
I mean I can directly do
wget www.google.com
and this will work. So the options are not mandatory.
If the options are not mandatory because they are in square brackets, then following through with that logic specifying a URL should not be mandatory as well and just
wget
as a command should work as well.
My question is- Is there some document where this pattern of specifying command usage is elaborated on?
command-line
there isn't any. normally programs usegetargs
– Lelouch Lamperouge
Mar 16 '12 at 2:40
@LelouchLamperouge-Do you mean getopt() by any chance? As far as I understand, isn't getopt() for parsing the command line arguments. Does it have anything to do with how command usage is specified at the top a man page.
– sandman
Mar 16 '12 at 14:12
add a comment |
up vote
3
down vote
favorite
up vote
3
down vote
favorite
When linux commands list their usage, this usually is how they do it (for eg wget):
wget [option]... [URL]...
From what I understand of this pattern of specifying command usage, this is not the usual regex way of specifying patterns and for the wget command says that it is not mandatory to specify any options and by that logic it is not mandatory to specify any URL as well.
I mean I can directly do
wget www.google.com
and this will work. So the options are not mandatory.
If the options are not mandatory because they are in square brackets, then following through with that logic specifying a URL should not be mandatory as well and just
wget
as a command should work as well.
My question is- Is there some document where this pattern of specifying command usage is elaborated on?
command-line
When linux commands list their usage, this usually is how they do it (for eg wget):
wget [option]... [URL]...
From what I understand of this pattern of specifying command usage, this is not the usual regex way of specifying patterns and for the wget command says that it is not mandatory to specify any options and by that logic it is not mandatory to specify any URL as well.
I mean I can directly do
wget www.google.com
and this will work. So the options are not mandatory.
If the options are not mandatory because they are in square brackets, then following through with that logic specifying a URL should not be mandatory as well and just
wget
as a command should work as well.
My question is- Is there some document where this pattern of specifying command usage is elaborated on?
command-line
command-line
edited Dec 7 at 23:40
Rui F Ribeiro
38.7k1479128
38.7k1479128
asked Mar 16 '12 at 1:41
sandman
182
182
there isn't any. normally programs usegetargs
– Lelouch Lamperouge
Mar 16 '12 at 2:40
@LelouchLamperouge-Do you mean getopt() by any chance? As far as I understand, isn't getopt() for parsing the command line arguments. Does it have anything to do with how command usage is specified at the top a man page.
– sandman
Mar 16 '12 at 14:12
add a comment |
there isn't any. normally programs usegetargs
– Lelouch Lamperouge
Mar 16 '12 at 2:40
@LelouchLamperouge-Do you mean getopt() by any chance? As far as I understand, isn't getopt() for parsing the command line arguments. Does it have anything to do with how command usage is specified at the top a man page.
– sandman
Mar 16 '12 at 14:12
there isn't any. normally programs use
getargs– Lelouch Lamperouge
Mar 16 '12 at 2:40
there isn't any. normally programs use
getargs– Lelouch Lamperouge
Mar 16 '12 at 2:40
@LelouchLamperouge-Do you mean getopt() by any chance? As far as I understand, isn't getopt() for parsing the command line arguments. Does it have anything to do with how command usage is specified at the top a man page.
– sandman
Mar 16 '12 at 14:12
@LelouchLamperouge-Do you mean getopt() by any chance? As far as I understand, isn't getopt() for parsing the command line arguments. Does it have anything to do with how command usage is specified at the top a man page.
– sandman
Mar 16 '12 at 14:12
add a comment |
6 Answers
6
active
oldest
votes
up vote
4
down vote
accepted
Typically a syntax where [...] is used to indicate optional args and '|' is used to indicate a logical OR is used in most man pages. It depends who writes the man page as there is no authority that dictates what a man page must read like. More specific to your question however, the man page reads true in this case. Either you can specify a url through the -i switch or you can supply a URL itself. So you can think of the options as "conditionally optional". Really it should probably read something like
([option (excluding -i)] (-i file | URL))
but you can see how this would get complicated very quickly. So you need to take the quick descriptions with a grain of salt. In my experience the command syntax is usually the least of your worries.
Also, I'm nit picking here but what you are seeing isn't a regex ;)
@fthinker- Thanks! That cleared up a lot of things in my head and should make my command exploring a lot less confusing. My bad for using regex. When I said regex, I meant something like a command pattern or something. I used regex rather loosely to mean something like that.
– sandman
Mar 16 '12 at 14:19
Yep, I know. :)
– fthinker
Mar 16 '12 at 15:01
add a comment |
up vote
0
down vote
I don't think there's a formal definition for that (I might be wrong), but it seems that there isn't much of a standard for this logic, judging from a random sampling of some manpages.
If there isn't, I think it is high time they standardized it. Judging from my own experience it will help navigating the plethora of commands and their specific idiosyncrasies a lot more easier.
– sandman
Mar 16 '12 at 2:11
@sandman. Once you get past the initial onslaught of all these new unknown options to unfamiliar programs, it settles down to being not so dramatic, other than having to deal with the plethora aspect... but that would be so in any case. BTW, the "they" you refer to is notionally you and I... and bear in mind that the history of many of the staple programs goes back many years when things grew somewhat more organically than might be preferred today. Significantly, that legacy needs to be backwardly compatible... There are moves afoot to improve it, but its not easy to contain flowing water.
– Peter.O
Mar 16 '12 at 8:23
@Peter.O- You do have a point. Backwards compatibility sure is a double-edged sword. However more often than not, I find myself tripping on it. That's probably why I have such a detached tone in my earlier comment when I used "they", but who like you pointed out are people like you and I. Thanks for you comment! :)
– sandman
Mar 16 '12 at 14:24
add a comment |
up vote
0
down vote
I would expect it to say
wget [options] URL...
wget [-i|--input-file] file [options] [URL...]
The single synopsis line is somewhat common for GNU man pages, where the authoritative documentation is the info documentation, and the man page is a very short summary, often describing only the most common options.
Compare this to BSD tools such as tar and the independent tool rsync.
On the other hand, POSIX Utility Conventions say that multiple synopsis lines should be used for mutually exclusive options, and the -i option is actually not mutually exclusive.
add a comment |
up vote
0
down vote
Isn't that all a specific implementation of http://en.wikipedia.org/wiki/Backus-Naur_form ?
add a comment |
up vote
0
down vote
man 7 man-pages (from the Linux man-pages package) explains some conventions that you should be aware of, even if there are some man pages that fail to follow the conventions.
add a comment |
up vote
0
down vote
In the POSIX specs, if you click on "Base Definitions" in the upper left pane, then "Utility Conventions" in the lower left pane, you'll find what you're looking for.
I wound up on this page looking for the POSIX specs for command help syntax, so I thought I'd help the next person.
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
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',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f34297%2funix-linux-command-syntax%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
Typically a syntax where [...] is used to indicate optional args and '|' is used to indicate a logical OR is used in most man pages. It depends who writes the man page as there is no authority that dictates what a man page must read like. More specific to your question however, the man page reads true in this case. Either you can specify a url through the -i switch or you can supply a URL itself. So you can think of the options as "conditionally optional". Really it should probably read something like
([option (excluding -i)] (-i file | URL))
but you can see how this would get complicated very quickly. So you need to take the quick descriptions with a grain of salt. In my experience the command syntax is usually the least of your worries.
Also, I'm nit picking here but what you are seeing isn't a regex ;)
@fthinker- Thanks! That cleared up a lot of things in my head and should make my command exploring a lot less confusing. My bad for using regex. When I said regex, I meant something like a command pattern or something. I used regex rather loosely to mean something like that.
– sandman
Mar 16 '12 at 14:19
Yep, I know. :)
– fthinker
Mar 16 '12 at 15:01
add a comment |
up vote
4
down vote
accepted
Typically a syntax where [...] is used to indicate optional args and '|' is used to indicate a logical OR is used in most man pages. It depends who writes the man page as there is no authority that dictates what a man page must read like. More specific to your question however, the man page reads true in this case. Either you can specify a url through the -i switch or you can supply a URL itself. So you can think of the options as "conditionally optional". Really it should probably read something like
([option (excluding -i)] (-i file | URL))
but you can see how this would get complicated very quickly. So you need to take the quick descriptions with a grain of salt. In my experience the command syntax is usually the least of your worries.
Also, I'm nit picking here but what you are seeing isn't a regex ;)
@fthinker- Thanks! That cleared up a lot of things in my head and should make my command exploring a lot less confusing. My bad for using regex. When I said regex, I meant something like a command pattern or something. I used regex rather loosely to mean something like that.
– sandman
Mar 16 '12 at 14:19
Yep, I know. :)
– fthinker
Mar 16 '12 at 15:01
add a comment |
up vote
4
down vote
accepted
up vote
4
down vote
accepted
Typically a syntax where [...] is used to indicate optional args and '|' is used to indicate a logical OR is used in most man pages. It depends who writes the man page as there is no authority that dictates what a man page must read like. More specific to your question however, the man page reads true in this case. Either you can specify a url through the -i switch or you can supply a URL itself. So you can think of the options as "conditionally optional". Really it should probably read something like
([option (excluding -i)] (-i file | URL))
but you can see how this would get complicated very quickly. So you need to take the quick descriptions with a grain of salt. In my experience the command syntax is usually the least of your worries.
Also, I'm nit picking here but what you are seeing isn't a regex ;)
Typically a syntax where [...] is used to indicate optional args and '|' is used to indicate a logical OR is used in most man pages. It depends who writes the man page as there is no authority that dictates what a man page must read like. More specific to your question however, the man page reads true in this case. Either you can specify a url through the -i switch or you can supply a URL itself. So you can think of the options as "conditionally optional". Really it should probably read something like
([option (excluding -i)] (-i file | URL))
but you can see how this would get complicated very quickly. So you need to take the quick descriptions with a grain of salt. In my experience the command syntax is usually the least of your worries.
Also, I'm nit picking here but what you are seeing isn't a regex ;)
answered Mar 16 '12 at 5:29
fthinker
3621312
3621312
@fthinker- Thanks! That cleared up a lot of things in my head and should make my command exploring a lot less confusing. My bad for using regex. When I said regex, I meant something like a command pattern or something. I used regex rather loosely to mean something like that.
– sandman
Mar 16 '12 at 14:19
Yep, I know. :)
– fthinker
Mar 16 '12 at 15:01
add a comment |
@fthinker- Thanks! That cleared up a lot of things in my head and should make my command exploring a lot less confusing. My bad for using regex. When I said regex, I meant something like a command pattern or something. I used regex rather loosely to mean something like that.
– sandman
Mar 16 '12 at 14:19
Yep, I know. :)
– fthinker
Mar 16 '12 at 15:01
@fthinker- Thanks! That cleared up a lot of things in my head and should make my command exploring a lot less confusing. My bad for using regex. When I said regex, I meant something like a command pattern or something. I used regex rather loosely to mean something like that.
– sandman
Mar 16 '12 at 14:19
@fthinker- Thanks! That cleared up a lot of things in my head and should make my command exploring a lot less confusing. My bad for using regex. When I said regex, I meant something like a command pattern or something. I used regex rather loosely to mean something like that.
– sandman
Mar 16 '12 at 14:19
Yep, I know. :)
– fthinker
Mar 16 '12 at 15:01
Yep, I know. :)
– fthinker
Mar 16 '12 at 15:01
add a comment |
up vote
0
down vote
I don't think there's a formal definition for that (I might be wrong), but it seems that there isn't much of a standard for this logic, judging from a random sampling of some manpages.
If there isn't, I think it is high time they standardized it. Judging from my own experience it will help navigating the plethora of commands and their specific idiosyncrasies a lot more easier.
– sandman
Mar 16 '12 at 2:11
@sandman. Once you get past the initial onslaught of all these new unknown options to unfamiliar programs, it settles down to being not so dramatic, other than having to deal with the plethora aspect... but that would be so in any case. BTW, the "they" you refer to is notionally you and I... and bear in mind that the history of many of the staple programs goes back many years when things grew somewhat more organically than might be preferred today. Significantly, that legacy needs to be backwardly compatible... There are moves afoot to improve it, but its not easy to contain flowing water.
– Peter.O
Mar 16 '12 at 8:23
@Peter.O- You do have a point. Backwards compatibility sure is a double-edged sword. However more often than not, I find myself tripping on it. That's probably why I have such a detached tone in my earlier comment when I used "they", but who like you pointed out are people like you and I. Thanks for you comment! :)
– sandman
Mar 16 '12 at 14:24
add a comment |
up vote
0
down vote
I don't think there's a formal definition for that (I might be wrong), but it seems that there isn't much of a standard for this logic, judging from a random sampling of some manpages.
If there isn't, I think it is high time they standardized it. Judging from my own experience it will help navigating the plethora of commands and their specific idiosyncrasies a lot more easier.
– sandman
Mar 16 '12 at 2:11
@sandman. Once you get past the initial onslaught of all these new unknown options to unfamiliar programs, it settles down to being not so dramatic, other than having to deal with the plethora aspect... but that would be so in any case. BTW, the "they" you refer to is notionally you and I... and bear in mind that the history of many of the staple programs goes back many years when things grew somewhat more organically than might be preferred today. Significantly, that legacy needs to be backwardly compatible... There are moves afoot to improve it, but its not easy to contain flowing water.
– Peter.O
Mar 16 '12 at 8:23
@Peter.O- You do have a point. Backwards compatibility sure is a double-edged sword. However more often than not, I find myself tripping on it. That's probably why I have such a detached tone in my earlier comment when I used "they", but who like you pointed out are people like you and I. Thanks for you comment! :)
– sandman
Mar 16 '12 at 14:24
add a comment |
up vote
0
down vote
up vote
0
down vote
I don't think there's a formal definition for that (I might be wrong), but it seems that there isn't much of a standard for this logic, judging from a random sampling of some manpages.
I don't think there's a formal definition for that (I might be wrong), but it seems that there isn't much of a standard for this logic, judging from a random sampling of some manpages.
answered Mar 16 '12 at 1:58
Renan
14.3k65376
14.3k65376
If there isn't, I think it is high time they standardized it. Judging from my own experience it will help navigating the plethora of commands and their specific idiosyncrasies a lot more easier.
– sandman
Mar 16 '12 at 2:11
@sandman. Once you get past the initial onslaught of all these new unknown options to unfamiliar programs, it settles down to being not so dramatic, other than having to deal with the plethora aspect... but that would be so in any case. BTW, the "they" you refer to is notionally you and I... and bear in mind that the history of many of the staple programs goes back many years when things grew somewhat more organically than might be preferred today. Significantly, that legacy needs to be backwardly compatible... There are moves afoot to improve it, but its not easy to contain flowing water.
– Peter.O
Mar 16 '12 at 8:23
@Peter.O- You do have a point. Backwards compatibility sure is a double-edged sword. However more often than not, I find myself tripping on it. That's probably why I have such a detached tone in my earlier comment when I used "they", but who like you pointed out are people like you and I. Thanks for you comment! :)
– sandman
Mar 16 '12 at 14:24
add a comment |
If there isn't, I think it is high time they standardized it. Judging from my own experience it will help navigating the plethora of commands and their specific idiosyncrasies a lot more easier.
– sandman
Mar 16 '12 at 2:11
@sandman. Once you get past the initial onslaught of all these new unknown options to unfamiliar programs, it settles down to being not so dramatic, other than having to deal with the plethora aspect... but that would be so in any case. BTW, the "they" you refer to is notionally you and I... and bear in mind that the history of many of the staple programs goes back many years when things grew somewhat more organically than might be preferred today. Significantly, that legacy needs to be backwardly compatible... There are moves afoot to improve it, but its not easy to contain flowing water.
– Peter.O
Mar 16 '12 at 8:23
@Peter.O- You do have a point. Backwards compatibility sure is a double-edged sword. However more often than not, I find myself tripping on it. That's probably why I have such a detached tone in my earlier comment when I used "they", but who like you pointed out are people like you and I. Thanks for you comment! :)
– sandman
Mar 16 '12 at 14:24
If there isn't, I think it is high time they standardized it. Judging from my own experience it will help navigating the plethora of commands and their specific idiosyncrasies a lot more easier.
– sandman
Mar 16 '12 at 2:11
If there isn't, I think it is high time they standardized it. Judging from my own experience it will help navigating the plethora of commands and their specific idiosyncrasies a lot more easier.
– sandman
Mar 16 '12 at 2:11
@sandman. Once you get past the initial onslaught of all these new unknown options to unfamiliar programs, it settles down to being not so dramatic, other than having to deal with the plethora aspect... but that would be so in any case. BTW, the "they" you refer to is notionally you and I... and bear in mind that the history of many of the staple programs goes back many years when things grew somewhat more organically than might be preferred today. Significantly, that legacy needs to be backwardly compatible... There are moves afoot to improve it, but its not easy to contain flowing water.
– Peter.O
Mar 16 '12 at 8:23
@sandman. Once you get past the initial onslaught of all these new unknown options to unfamiliar programs, it settles down to being not so dramatic, other than having to deal with the plethora aspect... but that would be so in any case. BTW, the "they" you refer to is notionally you and I... and bear in mind that the history of many of the staple programs goes back many years when things grew somewhat more organically than might be preferred today. Significantly, that legacy needs to be backwardly compatible... There are moves afoot to improve it, but its not easy to contain flowing water.
– Peter.O
Mar 16 '12 at 8:23
@Peter.O- You do have a point. Backwards compatibility sure is a double-edged sword. However more often than not, I find myself tripping on it. That's probably why I have such a detached tone in my earlier comment when I used "they", but who like you pointed out are people like you and I. Thanks for you comment! :)
– sandman
Mar 16 '12 at 14:24
@Peter.O- You do have a point. Backwards compatibility sure is a double-edged sword. However more often than not, I find myself tripping on it. That's probably why I have such a detached tone in my earlier comment when I used "they", but who like you pointed out are people like you and I. Thanks for you comment! :)
– sandman
Mar 16 '12 at 14:24
add a comment |
up vote
0
down vote
I would expect it to say
wget [options] URL...
wget [-i|--input-file] file [options] [URL...]
The single synopsis line is somewhat common for GNU man pages, where the authoritative documentation is the info documentation, and the man page is a very short summary, often describing only the most common options.
Compare this to BSD tools such as tar and the independent tool rsync.
On the other hand, POSIX Utility Conventions say that multiple synopsis lines should be used for mutually exclusive options, and the -i option is actually not mutually exclusive.
add a comment |
up vote
0
down vote
I would expect it to say
wget [options] URL...
wget [-i|--input-file] file [options] [URL...]
The single synopsis line is somewhat common for GNU man pages, where the authoritative documentation is the info documentation, and the man page is a very short summary, often describing only the most common options.
Compare this to BSD tools such as tar and the independent tool rsync.
On the other hand, POSIX Utility Conventions say that multiple synopsis lines should be used for mutually exclusive options, and the -i option is actually not mutually exclusive.
add a comment |
up vote
0
down vote
up vote
0
down vote
I would expect it to say
wget [options] URL...
wget [-i|--input-file] file [options] [URL...]
The single synopsis line is somewhat common for GNU man pages, where the authoritative documentation is the info documentation, and the man page is a very short summary, often describing only the most common options.
Compare this to BSD tools such as tar and the independent tool rsync.
On the other hand, POSIX Utility Conventions say that multiple synopsis lines should be used for mutually exclusive options, and the -i option is actually not mutually exclusive.
I would expect it to say
wget [options] URL...
wget [-i|--input-file] file [options] [URL...]
The single synopsis line is somewhat common for GNU man pages, where the authoritative documentation is the info documentation, and the man page is a very short summary, often describing only the most common options.
Compare this to BSD tools such as tar and the independent tool rsync.
On the other hand, POSIX Utility Conventions say that multiple synopsis lines should be used for mutually exclusive options, and the -i option is actually not mutually exclusive.
edited Sep 4 '12 at 13:53
answered Sep 4 '12 at 13:48
Mikel
38.8k1099125
38.8k1099125
add a comment |
add a comment |
up vote
0
down vote
Isn't that all a specific implementation of http://en.wikipedia.org/wiki/Backus-Naur_form ?
add a comment |
up vote
0
down vote
Isn't that all a specific implementation of http://en.wikipedia.org/wiki/Backus-Naur_form ?
add a comment |
up vote
0
down vote
up vote
0
down vote
Isn't that all a specific implementation of http://en.wikipedia.org/wiki/Backus-Naur_form ?
Isn't that all a specific implementation of http://en.wikipedia.org/wiki/Backus-Naur_form ?
answered Sep 4 '12 at 13:56
wolf
41626
41626
add a comment |
add a comment |
up vote
0
down vote
man 7 man-pages (from the Linux man-pages package) explains some conventions that you should be aware of, even if there are some man pages that fail to follow the conventions.
add a comment |
up vote
0
down vote
man 7 man-pages (from the Linux man-pages package) explains some conventions that you should be aware of, even if there are some man pages that fail to follow the conventions.
add a comment |
up vote
0
down vote
up vote
0
down vote
man 7 man-pages (from the Linux man-pages package) explains some conventions that you should be aware of, even if there are some man pages that fail to follow the conventions.
man 7 man-pages (from the Linux man-pages package) explains some conventions that you should be aware of, even if there are some man pages that fail to follow the conventions.
answered Sep 4 '12 at 21:56
Alan Curry
1,774109
1,774109
add a comment |
add a comment |
up vote
0
down vote
In the POSIX specs, if you click on "Base Definitions" in the upper left pane, then "Utility Conventions" in the lower left pane, you'll find what you're looking for.
I wound up on this page looking for the POSIX specs for command help syntax, so I thought I'd help the next person.
add a comment |
up vote
0
down vote
In the POSIX specs, if you click on "Base Definitions" in the upper left pane, then "Utility Conventions" in the lower left pane, you'll find what you're looking for.
I wound up on this page looking for the POSIX specs for command help syntax, so I thought I'd help the next person.
add a comment |
up vote
0
down vote
up vote
0
down vote
In the POSIX specs, if you click on "Base Definitions" in the upper left pane, then "Utility Conventions" in the lower left pane, you'll find what you're looking for.
I wound up on this page looking for the POSIX specs for command help syntax, so I thought I'd help the next person.
In the POSIX specs, if you click on "Base Definitions" in the upper left pane, then "Utility Conventions" in the lower left pane, you'll find what you're looking for.
I wound up on this page looking for the POSIX specs for command help syntax, so I thought I'd help the next person.
answered Mar 5 '16 at 1:57
Wildcard
22.6k961164
22.6k961164
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f34297%2funix-linux-command-syntax%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
there isn't any. normally programs use
getargs– Lelouch Lamperouge
Mar 16 '12 at 2:40
@LelouchLamperouge-Do you mean getopt() by any chance? As far as I understand, isn't getopt() for parsing the command line arguments. Does it have anything to do with how command usage is specified at the top a man page.
– sandman
Mar 16 '12 at 14:12