UNIX-, BSD-, GNU-options in Linux's ps command. Where are they from? The 2019 Stack Overflow...
Shouldn't "much" here be used instead of "more"?
Are children permitted to help build the Beis Hamikdash?
Scaling a graph of a circle and the standard parabola in TikZ
Right tool to dig six foot holes?
FPGA - DIY Programming
How to obtain Confidence Intervals for a LASSO regression?
What to do when moving next to a bird sanctuary with a loosely-domesticated cat?
Return to UK after being refused entry years previously
Does a dangling wire really electrocute me if I'm standing in water?
Can a flute soloist sit?
Output the Arecibo Message
How to notate time signature switching consistently every measure
How technical should a Scrum Master be to effectively remove impediments?
Can a rogue use sneak attack with weapons that have the thrown property even if they are not thrown?
Loose spokes after only a few rides
Is a "Democratic" Oligarchy-Style System Possible?
Why do UK politicians seemingly ignore opinion polls on Brexit?
What is the meaning of the verb "bear" in this context?
How to answer pointed "are you quitting" questioning when I don't want them to suspect
What does "fetching by region is not available for SAM files" means?
What are the motivations for publishing new editions of an existing textbook, beyond new discoveries in a field?
Multiply Two Integer Polynomials
Can you compress metal and what would be the consequences?
What is the motivation for a law requiring 2 parties to consent for recording a conversation
UNIX-, BSD-, GNU-options in Linux's ps command. Where are they from?
The 2019 Stack Overflow Developer Survey Results Are InCommand options with hyphen or notTop-like command configurable from command lineWhich to choose - BSD or Unix-style commands where available?Who are these BSD Unix contributors?What is the difference between Unix, Linux, BSD and GNU?When and how was the double-dash (--) introduced as an end of options delimiter in Unix/Linux?Using options of different kinds in ps commandsLinux Vs UNIX - kernel - How to understand the difference?Using sed command arguments to be compatible with both GNU & BSD Unix (in-place editing)Reliably determine free memoryWhich flags of the “ps” command are for the Unix flags format and which flags are for the BSD flags format?Are there multiple flavors of the GNU tools?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
In the manual for the ps command on Ubuntu there is this text:
This version of ps accepts several kinds of options:
1 UNIX options, which may be grouped and must be preceded by a
dash.
2 BSD options, which may be grouped and must not be used with
a dash.
3 GNU long options, which are preceded by two dashes.
Why is it possible that a command built in Ubuntu uses options from different operating systems? I know that the origin of Linux, UNIX and BSD are the same but they are different branches.
linux ps bsd arguments
add a comment |
In the manual for the ps command on Ubuntu there is this text:
This version of ps accepts several kinds of options:
1 UNIX options, which may be grouped and must be preceded by a
dash.
2 BSD options, which may be grouped and must not be used with
a dash.
3 GNU long options, which are preceded by two dashes.
Why is it possible that a command built in Ubuntu uses options from different operating systems? I know that the origin of Linux, UNIX and BSD are the same but they are different branches.
linux ps bsd arguments
4
I don't understand what you're asking, really. It's just different argument "styles". There's nothing "interesting" happening here except for the impressively huge set of possible arguments that ps takes.
– Mat
Jun 8 '13 at 11:09
I have nominated this for reopening because the closure reason is false. Speaking as someone who has done the research: It is possible to answer this with facts. The current answer is guesswork, is wrong guesswork; yet a correct answer cannot be added.
– JdeBP
Mar 23 at 8:38
add a comment |
In the manual for the ps command on Ubuntu there is this text:
This version of ps accepts several kinds of options:
1 UNIX options, which may be grouped and must be preceded by a
dash.
2 BSD options, which may be grouped and must not be used with
a dash.
3 GNU long options, which are preceded by two dashes.
Why is it possible that a command built in Ubuntu uses options from different operating systems? I know that the origin of Linux, UNIX and BSD are the same but they are different branches.
linux ps bsd arguments
In the manual for the ps command on Ubuntu there is this text:
This version of ps accepts several kinds of options:
1 UNIX options, which may be grouped and must be preceded by a
dash.
2 BSD options, which may be grouped and must not be used with
a dash.
3 GNU long options, which are preceded by two dashes.
Why is it possible that a command built in Ubuntu uses options from different operating systems? I know that the origin of Linux, UNIX and BSD are the same but they are different branches.
linux ps bsd arguments
linux ps bsd arguments
edited Jun 14 '13 at 23:04
Gilles
547k13011131628
547k13011131628
asked Jun 8 '13 at 10:37
YarLinuxYarLinux
5001410
5001410
4
I don't understand what you're asking, really. It's just different argument "styles". There's nothing "interesting" happening here except for the impressively huge set of possible arguments that ps takes.
– Mat
Jun 8 '13 at 11:09
I have nominated this for reopening because the closure reason is false. Speaking as someone who has done the research: It is possible to answer this with facts. The current answer is guesswork, is wrong guesswork; yet a correct answer cannot be added.
– JdeBP
Mar 23 at 8:38
add a comment |
4
I don't understand what you're asking, really. It's just different argument "styles". There's nothing "interesting" happening here except for the impressively huge set of possible arguments that ps takes.
– Mat
Jun 8 '13 at 11:09
I have nominated this for reopening because the closure reason is false. Speaking as someone who has done the research: It is possible to answer this with facts. The current answer is guesswork, is wrong guesswork; yet a correct answer cannot be added.
– JdeBP
Mar 23 at 8:38
4
4
I don't understand what you're asking, really. It's just different argument "styles". There's nothing "interesting" happening here except for the impressively huge set of possible arguments that ps takes.
– Mat
Jun 8 '13 at 11:09
I don't understand what you're asking, really. It's just different argument "styles". There's nothing "interesting" happening here except for the impressively huge set of possible arguments that ps takes.
– Mat
Jun 8 '13 at 11:09
I have nominated this for reopening because the closure reason is false. Speaking as someone who has done the research: It is possible to answer this with facts. The current answer is guesswork, is wrong guesswork; yet a correct answer cannot be added.
– JdeBP
Mar 23 at 8:38
I have nominated this for reopening because the closure reason is false. Speaking as someone who has done the research: It is possible to answer this with facts. The current answer is guesswork, is wrong guesswork; yet a correct answer cannot be added.
– JdeBP
Mar 23 at 8:38
add a comment |
2 Answers
2
active
oldest
votes
I just can give you an overall answer:
Command line options are often parsed using the library function getopt. Originally it only accepted arguments consisting of a - followed by a symbol. This effectively limits the amount of options you have, more or less -A to -Z, -a to -z and -0 to -9. You can imagine that you will not use an option without at least a hint to the real use, like -h for help or -v for version information or verbose output.
In Linux, and the often associated standard C library glibc, there is the extension to getopt to also handle -- - like options. Coming with this is that many commands developed under GNU (like glibc) used this extension. Now for many commands you also have the GNU-like style option. -v and --verbose, -h and --help and so on. I guess the same happened in BSD (though I am no BSD guy, please correct me).
Your ps command comes from a software collection called procps and I guess that they want to mimic the option style specific for a certain platform. So for the UNIX guys it has - options. For BSD it also accepts something like ps aux and so on.
ps is not the only program behaving like this. Many of the standard programs understand the "old" UNIX style (POSIX) and some modern extensions.
1
Welcome to the Unix & Linux stackexchange! You're off to an excellent start.
– user26112
Jun 8 '13 at 11:51
add a comment |
It's all because of a person by the name of Albert D. Cahalan. Xe did not know BSD.
The original ps command for Linux was written and first published in March 1992 by Branko Lankester. It was later to become known as "kmem-ps" to distinguish it from "proc-ps" that was published in December 1992 by Michael K. Johnson. M. Lankester's ps used the kmem device to read the process table from kernel memory. M. Johnson's ps used the proc filesystem to read the process table, and there were several releases of it made over the next few years (e.g. January 1993, January 1994).
These ps commands provided a fairly old, even then, syntax for the command whose style dated from the pre-getopt() days of the 1980s. Here it is from a November 1993 release of kmem-ps:
usage: ps 0acefhHjlmnprsStuUvwxXy [t tty] [pid[,pid]...]
j -- job control format, l -- long format, m -- memory format,
s -- signal format, u -- user format, v -- virtual memory format,
X -- register format, y -- syscall format, default -- short format
0 -- include task zero, a -- include processes for all users
c -- print only command name, e -- show env vars, f -- print forest of procs
h -- suppress the header, n -- print the user and wchan fields numerically
p -- print counts in pages, r -- restrict listing to runnable processes
S -- summarize usage for children in CPU time and page fault fields
t tty -- show all proccesses with TTY as their controlling terminal
w -- wide: 132, ww -- 264, www -- unlimited, default -- screen width or 80
x -- include processes without a controlling terminal
U [SYSTEM-PATH [SWAP-PATH]] -- update ps database
As you can see, there was one personality, a single meaning for the letters, and no leading minus sign characters.
The idea of a U flag (not -U, notice) comes from a 1986 patch to BSD ps by that was posted to the Usenet mod.sources newsgroup (as Volume 6 Issue 83) by Michael A. Callahan.
Along came Albert D. Cahalan a few years later, who rewrote proc-ps. Xe made a lot of claims about it. Unfortunately, the debunking of a lot of those claims has been forgotten, and what stands all of these years later is the ps manual claiming that this ps provides Unix, BSD, and GNU option syntax.
It does not.
BSD ps has used getopt() option processing since Marc Teitelbaum changed it to do so in April 1990, years before even M. Lankester's version of Linux ps, let alone M. Cahalan's.
M. Cahalan's ps provided the old Linux kmem-ps/proc-ps syntax. It later added some syntax that M. Cahalan claimed to be from the AIX ps command. M. Cahalan, who adamantly propounded the view on Usenet that "BSD sucks and SysV doesn't" that FreeBSD "sucks" and that xyr rewrite of proc-ps was a "standards-compliant /bin/ps" that supported "your obsolete BSD syntax", ironically was not aware that this had not in fact been the BSD syntax for almost a decade by that point. ps itself had only just been standardized that year, moreover. The analysis in the standard's rationale of BSD versus AT&T Unix command-line options is a lot more thoughtful than any of M. Cahalan's ever were.
This ps famously introduced the I_WANT_A_BROKEN_PS environment variable, which confusingly M. Cahalan blamed on M. Johnson whilst simultaneously claiming xyrself to be responsible for the option parsing. In fact, the twain were maintaining two ps implementations in parallel.
Bizarrely, if one used getopt()-style options preceded by minus signs, as was the case for BSD ps at the time and as the (then) new standard for ps documented, Cahalan/Johnson ps would state:
warning: `-' deprecated; use `ps e', not `ps -e'
Actually, it was not using - that was deprecated. Indeed, the very claim made by M. Cahalan was that xyr ps was going to work in the standard way using - — like BSD ps already had been. This caused numerous questions from perplexed users in the late 1990s and early 2000s, and generally confused the hell out of system administrators and users when books started saying things like:
You might be wondering why we don't use dashes before the flags withps. You can use them, but withpsthat's the old fashioned way and you get a warning about sticking with the program.
—Deborah S. Ray and Eric J. Ray (1998). UNIX. Peachpit Press. ISBN 9780201353952. p. 174.
You can still see this discussed in the oldps manual which talks of being "derived from the BSD version of ps" although it really was not, it being fairly obviously derived from the Linux one; and which states that "command-line arguments should not be preceeded by a `-' character, because in the future, a `-' will be used to indicate Unix98-standard command-line arguments, while no `-' will indicate the current ``extended BSD'' style of command line arguments".
Some of this was toned down in procps-ng, a third rewrite that was done just after the turn of the century (when "-ng" in project names was à la mode), which is when Cahalan/Johnson ps became oldps. As you can see, the ps manual no longer says "extended". But the new version of ps (which still involved M. Cahalan) did take the whole multiple-personality idea to extremes. Unfortunately, moreover, it still perpetuated the canard about BSD command-line options, and does so to this day.
In the meantime, the happily single-personality BSD ps has provided getopt() command-line option parsing for the past 29 years and 7 days at the time of writing this answer; FreeBSD has gained a procstat command; the NetBSD and OpenBSD ps has tracked the new compromise -A option; and the Single Unix Specification has reserved (but not included) the new BSD -O option to ps.
Further reading
- Robert N. M. Watson (2017-01-14).
procstat. FreeBSD General Commands Manual.
ps. FreeBSD General Commands Manual. 2018-03-13.
ps. NetBSD General Commands Manual. 2016-12-02.
ps. OpenBSD General Commands Manual. 2016-10-26.
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',
autoActivateHeartbeat: false,
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%2f78691%2funix-bsd-gnu-options-in-linuxs-ps-command-where-are-they-from%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
I just can give you an overall answer:
Command line options are often parsed using the library function getopt. Originally it only accepted arguments consisting of a - followed by a symbol. This effectively limits the amount of options you have, more or less -A to -Z, -a to -z and -0 to -9. You can imagine that you will not use an option without at least a hint to the real use, like -h for help or -v for version information or verbose output.
In Linux, and the often associated standard C library glibc, there is the extension to getopt to also handle -- - like options. Coming with this is that many commands developed under GNU (like glibc) used this extension. Now for many commands you also have the GNU-like style option. -v and --verbose, -h and --help and so on. I guess the same happened in BSD (though I am no BSD guy, please correct me).
Your ps command comes from a software collection called procps and I guess that they want to mimic the option style specific for a certain platform. So for the UNIX guys it has - options. For BSD it also accepts something like ps aux and so on.
ps is not the only program behaving like this. Many of the standard programs understand the "old" UNIX style (POSIX) and some modern extensions.
1
Welcome to the Unix & Linux stackexchange! You're off to an excellent start.
– user26112
Jun 8 '13 at 11:51
add a comment |
I just can give you an overall answer:
Command line options are often parsed using the library function getopt. Originally it only accepted arguments consisting of a - followed by a symbol. This effectively limits the amount of options you have, more or less -A to -Z, -a to -z and -0 to -9. You can imagine that you will not use an option without at least a hint to the real use, like -h for help or -v for version information or verbose output.
In Linux, and the often associated standard C library glibc, there is the extension to getopt to also handle -- - like options. Coming with this is that many commands developed under GNU (like glibc) used this extension. Now for many commands you also have the GNU-like style option. -v and --verbose, -h and --help and so on. I guess the same happened in BSD (though I am no BSD guy, please correct me).
Your ps command comes from a software collection called procps and I guess that they want to mimic the option style specific for a certain platform. So for the UNIX guys it has - options. For BSD it also accepts something like ps aux and so on.
ps is not the only program behaving like this. Many of the standard programs understand the "old" UNIX style (POSIX) and some modern extensions.
1
Welcome to the Unix & Linux stackexchange! You're off to an excellent start.
– user26112
Jun 8 '13 at 11:51
add a comment |
I just can give you an overall answer:
Command line options are often parsed using the library function getopt. Originally it only accepted arguments consisting of a - followed by a symbol. This effectively limits the amount of options you have, more or less -A to -Z, -a to -z and -0 to -9. You can imagine that you will not use an option without at least a hint to the real use, like -h for help or -v for version information or verbose output.
In Linux, and the often associated standard C library glibc, there is the extension to getopt to also handle -- - like options. Coming with this is that many commands developed under GNU (like glibc) used this extension. Now for many commands you also have the GNU-like style option. -v and --verbose, -h and --help and so on. I guess the same happened in BSD (though I am no BSD guy, please correct me).
Your ps command comes from a software collection called procps and I guess that they want to mimic the option style specific for a certain platform. So for the UNIX guys it has - options. For BSD it also accepts something like ps aux and so on.
ps is not the only program behaving like this. Many of the standard programs understand the "old" UNIX style (POSIX) and some modern extensions.
I just can give you an overall answer:
Command line options are often parsed using the library function getopt. Originally it only accepted arguments consisting of a - followed by a symbol. This effectively limits the amount of options you have, more or less -A to -Z, -a to -z and -0 to -9. You can imagine that you will not use an option without at least a hint to the real use, like -h for help or -v for version information or verbose output.
In Linux, and the often associated standard C library glibc, there is the extension to getopt to also handle -- - like options. Coming with this is that many commands developed under GNU (like glibc) used this extension. Now for many commands you also have the GNU-like style option. -v and --verbose, -h and --help and so on. I guess the same happened in BSD (though I am no BSD guy, please correct me).
Your ps command comes from a software collection called procps and I guess that they want to mimic the option style specific for a certain platform. So for the UNIX guys it has - options. For BSD it also accepts something like ps aux and so on.
ps is not the only program behaving like this. Many of the standard programs understand the "old" UNIX style (POSIX) and some modern extensions.
edited Feb 18 '18 at 0:37
Jeff Schaller♦
44.9k1164147
44.9k1164147
answered Jun 8 '13 at 11:34
AlphaOneAlphaOne
1113
1113
1
Welcome to the Unix & Linux stackexchange! You're off to an excellent start.
– user26112
Jun 8 '13 at 11:51
add a comment |
1
Welcome to the Unix & Linux stackexchange! You're off to an excellent start.
– user26112
Jun 8 '13 at 11:51
1
1
Welcome to the Unix & Linux stackexchange! You're off to an excellent start.
– user26112
Jun 8 '13 at 11:51
Welcome to the Unix & Linux stackexchange! You're off to an excellent start.
– user26112
Jun 8 '13 at 11:51
add a comment |
It's all because of a person by the name of Albert D. Cahalan. Xe did not know BSD.
The original ps command for Linux was written and first published in March 1992 by Branko Lankester. It was later to become known as "kmem-ps" to distinguish it from "proc-ps" that was published in December 1992 by Michael K. Johnson. M. Lankester's ps used the kmem device to read the process table from kernel memory. M. Johnson's ps used the proc filesystem to read the process table, and there were several releases of it made over the next few years (e.g. January 1993, January 1994).
These ps commands provided a fairly old, even then, syntax for the command whose style dated from the pre-getopt() days of the 1980s. Here it is from a November 1993 release of kmem-ps:
usage: ps 0acefhHjlmnprsStuUvwxXy [t tty] [pid[,pid]...]
j -- job control format, l -- long format, m -- memory format,
s -- signal format, u -- user format, v -- virtual memory format,
X -- register format, y -- syscall format, default -- short format
0 -- include task zero, a -- include processes for all users
c -- print only command name, e -- show env vars, f -- print forest of procs
h -- suppress the header, n -- print the user and wchan fields numerically
p -- print counts in pages, r -- restrict listing to runnable processes
S -- summarize usage for children in CPU time and page fault fields
t tty -- show all proccesses with TTY as their controlling terminal
w -- wide: 132, ww -- 264, www -- unlimited, default -- screen width or 80
x -- include processes without a controlling terminal
U [SYSTEM-PATH [SWAP-PATH]] -- update ps database
As you can see, there was one personality, a single meaning for the letters, and no leading minus sign characters.
The idea of a U flag (not -U, notice) comes from a 1986 patch to BSD ps by that was posted to the Usenet mod.sources newsgroup (as Volume 6 Issue 83) by Michael A. Callahan.
Along came Albert D. Cahalan a few years later, who rewrote proc-ps. Xe made a lot of claims about it. Unfortunately, the debunking of a lot of those claims has been forgotten, and what stands all of these years later is the ps manual claiming that this ps provides Unix, BSD, and GNU option syntax.
It does not.
BSD ps has used getopt() option processing since Marc Teitelbaum changed it to do so in April 1990, years before even M. Lankester's version of Linux ps, let alone M. Cahalan's.
M. Cahalan's ps provided the old Linux kmem-ps/proc-ps syntax. It later added some syntax that M. Cahalan claimed to be from the AIX ps command. M. Cahalan, who adamantly propounded the view on Usenet that "BSD sucks and SysV doesn't" that FreeBSD "sucks" and that xyr rewrite of proc-ps was a "standards-compliant /bin/ps" that supported "your obsolete BSD syntax", ironically was not aware that this had not in fact been the BSD syntax for almost a decade by that point. ps itself had only just been standardized that year, moreover. The analysis in the standard's rationale of BSD versus AT&T Unix command-line options is a lot more thoughtful than any of M. Cahalan's ever were.
This ps famously introduced the I_WANT_A_BROKEN_PS environment variable, which confusingly M. Cahalan blamed on M. Johnson whilst simultaneously claiming xyrself to be responsible for the option parsing. In fact, the twain were maintaining two ps implementations in parallel.
Bizarrely, if one used getopt()-style options preceded by minus signs, as was the case for BSD ps at the time and as the (then) new standard for ps documented, Cahalan/Johnson ps would state:
warning: `-' deprecated; use `ps e', not `ps -e'
Actually, it was not using - that was deprecated. Indeed, the very claim made by M. Cahalan was that xyr ps was going to work in the standard way using - — like BSD ps already had been. This caused numerous questions from perplexed users in the late 1990s and early 2000s, and generally confused the hell out of system administrators and users when books started saying things like:
You might be wondering why we don't use dashes before the flags withps. You can use them, but withpsthat's the old fashioned way and you get a warning about sticking with the program.
—Deborah S. Ray and Eric J. Ray (1998). UNIX. Peachpit Press. ISBN 9780201353952. p. 174.
You can still see this discussed in the oldps manual which talks of being "derived from the BSD version of ps" although it really was not, it being fairly obviously derived from the Linux one; and which states that "command-line arguments should not be preceeded by a `-' character, because in the future, a `-' will be used to indicate Unix98-standard command-line arguments, while no `-' will indicate the current ``extended BSD'' style of command line arguments".
Some of this was toned down in procps-ng, a third rewrite that was done just after the turn of the century (when "-ng" in project names was à la mode), which is when Cahalan/Johnson ps became oldps. As you can see, the ps manual no longer says "extended". But the new version of ps (which still involved M. Cahalan) did take the whole multiple-personality idea to extremes. Unfortunately, moreover, it still perpetuated the canard about BSD command-line options, and does so to this day.
In the meantime, the happily single-personality BSD ps has provided getopt() command-line option parsing for the past 29 years and 7 days at the time of writing this answer; FreeBSD has gained a procstat command; the NetBSD and OpenBSD ps has tracked the new compromise -A option; and the Single Unix Specification has reserved (but not included) the new BSD -O option to ps.
Further reading
- Robert N. M. Watson (2017-01-14).
procstat. FreeBSD General Commands Manual.
ps. FreeBSD General Commands Manual. 2018-03-13.
ps. NetBSD General Commands Manual. 2016-12-02.
ps. OpenBSD General Commands Manual. 2016-10-26.
add a comment |
It's all because of a person by the name of Albert D. Cahalan. Xe did not know BSD.
The original ps command for Linux was written and first published in March 1992 by Branko Lankester. It was later to become known as "kmem-ps" to distinguish it from "proc-ps" that was published in December 1992 by Michael K. Johnson. M. Lankester's ps used the kmem device to read the process table from kernel memory. M. Johnson's ps used the proc filesystem to read the process table, and there were several releases of it made over the next few years (e.g. January 1993, January 1994).
These ps commands provided a fairly old, even then, syntax for the command whose style dated from the pre-getopt() days of the 1980s. Here it is from a November 1993 release of kmem-ps:
usage: ps 0acefhHjlmnprsStuUvwxXy [t tty] [pid[,pid]...]
j -- job control format, l -- long format, m -- memory format,
s -- signal format, u -- user format, v -- virtual memory format,
X -- register format, y -- syscall format, default -- short format
0 -- include task zero, a -- include processes for all users
c -- print only command name, e -- show env vars, f -- print forest of procs
h -- suppress the header, n -- print the user and wchan fields numerically
p -- print counts in pages, r -- restrict listing to runnable processes
S -- summarize usage for children in CPU time and page fault fields
t tty -- show all proccesses with TTY as their controlling terminal
w -- wide: 132, ww -- 264, www -- unlimited, default -- screen width or 80
x -- include processes without a controlling terminal
U [SYSTEM-PATH [SWAP-PATH]] -- update ps database
As you can see, there was one personality, a single meaning for the letters, and no leading minus sign characters.
The idea of a U flag (not -U, notice) comes from a 1986 patch to BSD ps by that was posted to the Usenet mod.sources newsgroup (as Volume 6 Issue 83) by Michael A. Callahan.
Along came Albert D. Cahalan a few years later, who rewrote proc-ps. Xe made a lot of claims about it. Unfortunately, the debunking of a lot of those claims has been forgotten, and what stands all of these years later is the ps manual claiming that this ps provides Unix, BSD, and GNU option syntax.
It does not.
BSD ps has used getopt() option processing since Marc Teitelbaum changed it to do so in April 1990, years before even M. Lankester's version of Linux ps, let alone M. Cahalan's.
M. Cahalan's ps provided the old Linux kmem-ps/proc-ps syntax. It later added some syntax that M. Cahalan claimed to be from the AIX ps command. M. Cahalan, who adamantly propounded the view on Usenet that "BSD sucks and SysV doesn't" that FreeBSD "sucks" and that xyr rewrite of proc-ps was a "standards-compliant /bin/ps" that supported "your obsolete BSD syntax", ironically was not aware that this had not in fact been the BSD syntax for almost a decade by that point. ps itself had only just been standardized that year, moreover. The analysis in the standard's rationale of BSD versus AT&T Unix command-line options is a lot more thoughtful than any of M. Cahalan's ever were.
This ps famously introduced the I_WANT_A_BROKEN_PS environment variable, which confusingly M. Cahalan blamed on M. Johnson whilst simultaneously claiming xyrself to be responsible for the option parsing. In fact, the twain were maintaining two ps implementations in parallel.
Bizarrely, if one used getopt()-style options preceded by minus signs, as was the case for BSD ps at the time and as the (then) new standard for ps documented, Cahalan/Johnson ps would state:
warning: `-' deprecated; use `ps e', not `ps -e'
Actually, it was not using - that was deprecated. Indeed, the very claim made by M. Cahalan was that xyr ps was going to work in the standard way using - — like BSD ps already had been. This caused numerous questions from perplexed users in the late 1990s and early 2000s, and generally confused the hell out of system administrators and users when books started saying things like:
You might be wondering why we don't use dashes before the flags withps. You can use them, but withpsthat's the old fashioned way and you get a warning about sticking with the program.
—Deborah S. Ray and Eric J. Ray (1998). UNIX. Peachpit Press. ISBN 9780201353952. p. 174.
You can still see this discussed in the oldps manual which talks of being "derived from the BSD version of ps" although it really was not, it being fairly obviously derived from the Linux one; and which states that "command-line arguments should not be preceeded by a `-' character, because in the future, a `-' will be used to indicate Unix98-standard command-line arguments, while no `-' will indicate the current ``extended BSD'' style of command line arguments".
Some of this was toned down in procps-ng, a third rewrite that was done just after the turn of the century (when "-ng" in project names was à la mode), which is when Cahalan/Johnson ps became oldps. As you can see, the ps manual no longer says "extended". But the new version of ps (which still involved M. Cahalan) did take the whole multiple-personality idea to extremes. Unfortunately, moreover, it still perpetuated the canard about BSD command-line options, and does so to this day.
In the meantime, the happily single-personality BSD ps has provided getopt() command-line option parsing for the past 29 years and 7 days at the time of writing this answer; FreeBSD has gained a procstat command; the NetBSD and OpenBSD ps has tracked the new compromise -A option; and the Single Unix Specification has reserved (but not included) the new BSD -O option to ps.
Further reading
- Robert N. M. Watson (2017-01-14).
procstat. FreeBSD General Commands Manual.
ps. FreeBSD General Commands Manual. 2018-03-13.
ps. NetBSD General Commands Manual. 2016-12-02.
ps. OpenBSD General Commands Manual. 2016-10-26.
add a comment |
It's all because of a person by the name of Albert D. Cahalan. Xe did not know BSD.
The original ps command for Linux was written and first published in March 1992 by Branko Lankester. It was later to become known as "kmem-ps" to distinguish it from "proc-ps" that was published in December 1992 by Michael K. Johnson. M. Lankester's ps used the kmem device to read the process table from kernel memory. M. Johnson's ps used the proc filesystem to read the process table, and there were several releases of it made over the next few years (e.g. January 1993, January 1994).
These ps commands provided a fairly old, even then, syntax for the command whose style dated from the pre-getopt() days of the 1980s. Here it is from a November 1993 release of kmem-ps:
usage: ps 0acefhHjlmnprsStuUvwxXy [t tty] [pid[,pid]...]
j -- job control format, l -- long format, m -- memory format,
s -- signal format, u -- user format, v -- virtual memory format,
X -- register format, y -- syscall format, default -- short format
0 -- include task zero, a -- include processes for all users
c -- print only command name, e -- show env vars, f -- print forest of procs
h -- suppress the header, n -- print the user and wchan fields numerically
p -- print counts in pages, r -- restrict listing to runnable processes
S -- summarize usage for children in CPU time and page fault fields
t tty -- show all proccesses with TTY as their controlling terminal
w -- wide: 132, ww -- 264, www -- unlimited, default -- screen width or 80
x -- include processes without a controlling terminal
U [SYSTEM-PATH [SWAP-PATH]] -- update ps database
As you can see, there was one personality, a single meaning for the letters, and no leading minus sign characters.
The idea of a U flag (not -U, notice) comes from a 1986 patch to BSD ps by that was posted to the Usenet mod.sources newsgroup (as Volume 6 Issue 83) by Michael A. Callahan.
Along came Albert D. Cahalan a few years later, who rewrote proc-ps. Xe made a lot of claims about it. Unfortunately, the debunking of a lot of those claims has been forgotten, and what stands all of these years later is the ps manual claiming that this ps provides Unix, BSD, and GNU option syntax.
It does not.
BSD ps has used getopt() option processing since Marc Teitelbaum changed it to do so in April 1990, years before even M. Lankester's version of Linux ps, let alone M. Cahalan's.
M. Cahalan's ps provided the old Linux kmem-ps/proc-ps syntax. It later added some syntax that M. Cahalan claimed to be from the AIX ps command. M. Cahalan, who adamantly propounded the view on Usenet that "BSD sucks and SysV doesn't" that FreeBSD "sucks" and that xyr rewrite of proc-ps was a "standards-compliant /bin/ps" that supported "your obsolete BSD syntax", ironically was not aware that this had not in fact been the BSD syntax for almost a decade by that point. ps itself had only just been standardized that year, moreover. The analysis in the standard's rationale of BSD versus AT&T Unix command-line options is a lot more thoughtful than any of M. Cahalan's ever were.
This ps famously introduced the I_WANT_A_BROKEN_PS environment variable, which confusingly M. Cahalan blamed on M. Johnson whilst simultaneously claiming xyrself to be responsible for the option parsing. In fact, the twain were maintaining two ps implementations in parallel.
Bizarrely, if one used getopt()-style options preceded by minus signs, as was the case for BSD ps at the time and as the (then) new standard for ps documented, Cahalan/Johnson ps would state:
warning: `-' deprecated; use `ps e', not `ps -e'
Actually, it was not using - that was deprecated. Indeed, the very claim made by M. Cahalan was that xyr ps was going to work in the standard way using - — like BSD ps already had been. This caused numerous questions from perplexed users in the late 1990s and early 2000s, and generally confused the hell out of system administrators and users when books started saying things like:
You might be wondering why we don't use dashes before the flags withps. You can use them, but withpsthat's the old fashioned way and you get a warning about sticking with the program.
—Deborah S. Ray and Eric J. Ray (1998). UNIX. Peachpit Press. ISBN 9780201353952. p. 174.
You can still see this discussed in the oldps manual which talks of being "derived from the BSD version of ps" although it really was not, it being fairly obviously derived from the Linux one; and which states that "command-line arguments should not be preceeded by a `-' character, because in the future, a `-' will be used to indicate Unix98-standard command-line arguments, while no `-' will indicate the current ``extended BSD'' style of command line arguments".
Some of this was toned down in procps-ng, a third rewrite that was done just after the turn of the century (when "-ng" in project names was à la mode), which is when Cahalan/Johnson ps became oldps. As you can see, the ps manual no longer says "extended". But the new version of ps (which still involved M. Cahalan) did take the whole multiple-personality idea to extremes. Unfortunately, moreover, it still perpetuated the canard about BSD command-line options, and does so to this day.
In the meantime, the happily single-personality BSD ps has provided getopt() command-line option parsing for the past 29 years and 7 days at the time of writing this answer; FreeBSD has gained a procstat command; the NetBSD and OpenBSD ps has tracked the new compromise -A option; and the Single Unix Specification has reserved (but not included) the new BSD -O option to ps.
Further reading
- Robert N. M. Watson (2017-01-14).
procstat. FreeBSD General Commands Manual.
ps. FreeBSD General Commands Manual. 2018-03-13.
ps. NetBSD General Commands Manual. 2016-12-02.
ps. OpenBSD General Commands Manual. 2016-10-26.
It's all because of a person by the name of Albert D. Cahalan. Xe did not know BSD.
The original ps command for Linux was written and first published in March 1992 by Branko Lankester. It was later to become known as "kmem-ps" to distinguish it from "proc-ps" that was published in December 1992 by Michael K. Johnson. M. Lankester's ps used the kmem device to read the process table from kernel memory. M. Johnson's ps used the proc filesystem to read the process table, and there were several releases of it made over the next few years (e.g. January 1993, January 1994).
These ps commands provided a fairly old, even then, syntax for the command whose style dated from the pre-getopt() days of the 1980s. Here it is from a November 1993 release of kmem-ps:
usage: ps 0acefhHjlmnprsStuUvwxXy [t tty] [pid[,pid]...]
j -- job control format, l -- long format, m -- memory format,
s -- signal format, u -- user format, v -- virtual memory format,
X -- register format, y -- syscall format, default -- short format
0 -- include task zero, a -- include processes for all users
c -- print only command name, e -- show env vars, f -- print forest of procs
h -- suppress the header, n -- print the user and wchan fields numerically
p -- print counts in pages, r -- restrict listing to runnable processes
S -- summarize usage for children in CPU time and page fault fields
t tty -- show all proccesses with TTY as their controlling terminal
w -- wide: 132, ww -- 264, www -- unlimited, default -- screen width or 80
x -- include processes without a controlling terminal
U [SYSTEM-PATH [SWAP-PATH]] -- update ps database
As you can see, there was one personality, a single meaning for the letters, and no leading minus sign characters.
The idea of a U flag (not -U, notice) comes from a 1986 patch to BSD ps by that was posted to the Usenet mod.sources newsgroup (as Volume 6 Issue 83) by Michael A. Callahan.
Along came Albert D. Cahalan a few years later, who rewrote proc-ps. Xe made a lot of claims about it. Unfortunately, the debunking of a lot of those claims has been forgotten, and what stands all of these years later is the ps manual claiming that this ps provides Unix, BSD, and GNU option syntax.
It does not.
BSD ps has used getopt() option processing since Marc Teitelbaum changed it to do so in April 1990, years before even M. Lankester's version of Linux ps, let alone M. Cahalan's.
M. Cahalan's ps provided the old Linux kmem-ps/proc-ps syntax. It later added some syntax that M. Cahalan claimed to be from the AIX ps command. M. Cahalan, who adamantly propounded the view on Usenet that "BSD sucks and SysV doesn't" that FreeBSD "sucks" and that xyr rewrite of proc-ps was a "standards-compliant /bin/ps" that supported "your obsolete BSD syntax", ironically was not aware that this had not in fact been the BSD syntax for almost a decade by that point. ps itself had only just been standardized that year, moreover. The analysis in the standard's rationale of BSD versus AT&T Unix command-line options is a lot more thoughtful than any of M. Cahalan's ever were.
This ps famously introduced the I_WANT_A_BROKEN_PS environment variable, which confusingly M. Cahalan blamed on M. Johnson whilst simultaneously claiming xyrself to be responsible for the option parsing. In fact, the twain were maintaining two ps implementations in parallel.
Bizarrely, if one used getopt()-style options preceded by minus signs, as was the case for BSD ps at the time and as the (then) new standard for ps documented, Cahalan/Johnson ps would state:
warning: `-' deprecated; use `ps e', not `ps -e'
Actually, it was not using - that was deprecated. Indeed, the very claim made by M. Cahalan was that xyr ps was going to work in the standard way using - — like BSD ps already had been. This caused numerous questions from perplexed users in the late 1990s and early 2000s, and generally confused the hell out of system administrators and users when books started saying things like:
You might be wondering why we don't use dashes before the flags withps. You can use them, but withpsthat's the old fashioned way and you get a warning about sticking with the program.
—Deborah S. Ray and Eric J. Ray (1998). UNIX. Peachpit Press. ISBN 9780201353952. p. 174.
You can still see this discussed in the oldps manual which talks of being "derived from the BSD version of ps" although it really was not, it being fairly obviously derived from the Linux one; and which states that "command-line arguments should not be preceeded by a `-' character, because in the future, a `-' will be used to indicate Unix98-standard command-line arguments, while no `-' will indicate the current ``extended BSD'' style of command line arguments".
Some of this was toned down in procps-ng, a third rewrite that was done just after the turn of the century (when "-ng" in project names was à la mode), which is when Cahalan/Johnson ps became oldps. As you can see, the ps manual no longer says "extended". But the new version of ps (which still involved M. Cahalan) did take the whole multiple-personality idea to extremes. Unfortunately, moreover, it still perpetuated the canard about BSD command-line options, and does so to this day.
In the meantime, the happily single-personality BSD ps has provided getopt() command-line option parsing for the past 29 years and 7 days at the time of writing this answer; FreeBSD has gained a procstat command; the NetBSD and OpenBSD ps has tracked the new compromise -A option; and the Single Unix Specification has reserved (but not included) the new BSD -O option to ps.
Further reading
- Robert N. M. Watson (2017-01-14).
procstat. FreeBSD General Commands Manual.
ps. FreeBSD General Commands Manual. 2018-03-13.
ps. NetBSD General Commands Manual. 2016-12-02.
ps. OpenBSD General Commands Manual. 2016-10-26.
answered yesterday
JdeBPJdeBP
37.9k478183
37.9k478183
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.
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%2f78691%2funix-bsd-gnu-options-in-linuxs-ps-command-where-are-they-from%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
4
I don't understand what you're asking, really. It's just different argument "styles". There's nothing "interesting" happening here except for the impressively huge set of possible arguments that ps takes.
– Mat
Jun 8 '13 at 11:09
I have nominated this for reopening because the closure reason is false. Speaking as someone who has done the research: It is possible to answer this with facts. The current answer is guesswork, is wrong guesswork; yet a correct answer cannot be added.
– JdeBP
Mar 23 at 8:38