See the following testing:
$ ( if [ 1 -eq 2 ]; then echo ok; fi ); echo $? 0
$ [ 1 -eq 2 ]; echo $? 1
$ help if [...] Exit Status: Returns the status of the last command
executed.
So, I think in the first test, the exit status should be the "[ 1 -eq
2 ]", but as you can see, this is not the case. Where is my
understanding wrong?
Regards, HZ
On 21.01.2022 13:13, hongy...@gmail.com wrote:
See the following testing:
$ ( if [ 1 -eq 2 ]; then echo ok; fi ); echo $? 0
$ [ 1 -eq 2 ]; echo $? 1
$ help if [...] Exit Status: Returns the status of the last command executed.
So, I think in the first test, the exit status should be the "[ 1 -eqYou missed that no command has been executed. The 'if' compound
2 ]", but as you can see, this is not the case. Where is my
understanding wrong?
command would have executed the else case, but there isn't one.
Thus 0 is returned.
On Friday, January 21, 2022 at 8:25:26 PM UTC+8, Janis Papanagnou wrote:
On 21.01.2022 13:13, hongy...@gmail.com wrote:
See the following testing:You missed that no command has been executed. The 'if' compound
$ ( if [ 1 -eq 2 ]; then echo ok; fi ); echo $? 0
$ [ 1 -eq 2 ]; echo $? 1
$ help if [...] Exit Status: Returns the status of the last command
executed.
So, I think in the first test, the exit status should be the "[ 1 -eq
2 ]", but as you can see, this is not the case. Where is my
understanding wrong?
command would have executed the else case, but there isn't one.
Thus 0 is returned.
Based on your above comments, I further noted the following description in help:
The exit status of the entire construct is the exit status of the last
command executed, or zero if no condition tested true.
So, I obtained the following explanation: Given that the only
condition "[ 1 -eq 2 ]" is false, we can say "no condition tested true"
and therefore return zero.
On 21.01.2022 13:59, hongy...@gmail.com wrote:
On Friday, January 21, 2022 at 8:25:26 PM UTC+8, Janis Papanagnou wrote:
On 21.01.2022 13:13, hongy...@gmail.com wrote:
See the following testing:You missed that no command has been executed. The 'if' compound
$ ( if [ 1 -eq 2 ]; then echo ok; fi ); echo $? 0
$ [ 1 -eq 2 ]; echo $? 1
$ help if [...] Exit Status: Returns the status of the last command
executed.
So, I think in the first test, the exit status should be the "[ 1 -eq
2 ]", but as you can see, this is not the case. Where is my
understanding wrong?
command would have executed the else case, but there isn't one.
Thus 0 is returned.
Based on your above comments, I further noted the following description in help:
The exit status of the entire construct is the exit status of the last command executed, or zero if no condition tested true.
So, I obtained the following explanation: Given that the onlyI'm not sure why you formulate it that way. In case of
condition "[ 1 -eq 2 ]" is false, we can say "no condition tested true"
and therefore return zero.
$ if [ 1 -eq 2 ]; then echo ok; else false ; fi ); echo $?
1
there's also "no condition tested true" and you don't get exit code 0.
The point is another one. It's probably the best to simply look up the
POSIX specs where it's clearly described:
"Exit Status
The exit status of the if command shall be the exit status of the then
or else compound-list that was executed, or zero, if none was executed."
It's clear, simple, and leaves no doubts, I hope.
Janis
BTW, what's the URL where you find the following explanation?
"Exit Status
The exit status of the if command shall be the exit status of the then
or else compound-list that was executed, or zero, if none was executed."
In article <8834cc9c-bdca-4cf0-96cd-68818323b9bcn@googlegroups.com>, hongy...@gmail.com <hongyi.zhao@gmail.com> wrote:
...
BTW, what's the URL where you find the following explanation?
"Exit Status
The exit status of the if command shall be the exit status of the then
or else compound-list that was executed, or zero, if none was executed."
Do "man bash", then search for: if
(that's literally 5 spaces then i then f)
And you'll get the 411.
BTW, the above text does not appear literally in my "man bash" as written; I'm guessing that Janis got it from some other source.
But the general content is the same.
On Friday, January 21, 2022 at 9:13:15 PM UTC+8, Janis Papanagnou wrote:
there's also "no condition tested true" and you don't get exit code 0.
The point is another one. It's probably the best to simply look up the
POSIX specs where it's clearly described:
BTW, what's the URL where you find the following explanation?
"Exit Status
The exit status of the if command shall be the exit status of the then
or else compound-list that was executed, or zero, if none was executed."
For basic standard stuff the POSIX specs are often better. The man
pages may differ (even for basic standard stuff) between shells.
In article <ssejua$jno$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
...
For basic standard stuff the POSIX specs are often better. The man
pages may differ (even for basic standard stuff) between shells.
I would argue that the man page for one's specific shell is a better reference than the abstract POSIX specs. [...]
On 21.01.2022 15:15, hongy...@gmail.com wrote:
BTW, what's the URL [...]
On 21.01.2022 15:15, hongy...@gmail.com wrote:
BTW, what's the URL [...]
Here are a couple links that you may want to inspect to get your
first qualified answers before you post.
For shell you may want to inspect
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html
where you also find a link to the shell language, accessible though
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18
And the entries to the standard Unix tools you find here
https://pubs.opengroup.org/onlinepubs/9699919799/idx/utilities.html
and for the often used and referenced standard awk see this page
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html
In article <8834cc9c-bdca-4cf0...@googlegroups.com>,
hongy...@gmail.com <hongy...@gmail.com> wrote:
...
BTW, what's the URL where you find the following explanation?
(that's literally 5 spaces then i then f)"Exit Status
The exit status of the if command shall be the exit status of the then
or else compound-list that was executed, or zero, if none was executed." Do "man bash", then search for: if
And you'll get the 411.
BTW, the above text does not appear literally in my "man bash" as written; I'm guessing that Janis got it from some other source. But the general content is the same.
On Friday, January 21, 2022 at 9:13:15 PM UTC+8, Janis Papanagnou
wrote:
On 21.01.2022 13:59, hongy...@gmail.com wrote:
On Friday, January 21, 2022 at 8:25:26 PM UTC+8, Janis
Papanagnou wrote:
I'm not sure why you formulate it that way. In case ofYou missed that no command has been executed. The 'if' compound
command would have executed the else case, but there isn't one.
Thus 0 is returned.
Based on your above comments, I further noted the following
description in help:
The exit status of the entire construct is the exit status of
the last command executed, or zero if no condition tested true.
So, I obtained the following explanation: Given that the only
condition "[ 1 -eq 2 ]" is false, we can say "no condition
tested true" and therefore return zero.
$ if [ 1 -eq 2 ]; then echo ok; else false ; fi ); echo $?
1
This is equivalent to:
$ ( if [ 1 -eq 2 ]; then echo ok; else exit 1 ; fi ); echo $?
1
there's also "no condition tested true" and you don't get exit
code 0. The point is another one. It's probably the best to
simply look up the POSIX specs where it's clearly described:
"Exit Status
The exit status of the if command shall be the exit status of the
then or else compound-list that was executed, or zero, if none
was executed."
So, if I want to obtain a valid exit status, it must be explicitly
set by the then or else compound-list.
"hongy...@gmail.com" <hongy...@gmail.com>:
$ if [ 1 -eq 2 ]; then echo ok; else false ; fi ); echo $?
1
This is equivalent to:
By coincidence, yes.
$ ( if [ 1 -eq 2 ]; then echo ok; else exit 1 ; fi ); echo $?If, for example, you remove the parentheses, you'll get different
1
semantics.
there's also "no condition tested true" and you don't get exit
code 0. The point is another one. It's probably the best to
simply look up the POSIX specs where it's clearly described:
"Exit Status
The exit status of the if command shall be the exit status of the
then or else compound-list that was executed, or zero, if none
was executed."
So, if I want to obtain a valid exit status, it must be explicitlyNot exactly. It suffices to have the exit status implicitly be set
set by the then or else compound-list.
by the then or else compound‐list: Every shell command (other than
the comment (#)) has got an exit status. So there is no way not to
set an exit status. It's the programmer's responsibility to have
the shell execute the right commands, though.
In article <ssejua$jno$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
...
For basic standard stuff the POSIX specs are often better. The man
pages may differ (even for basic standard stuff) between shells.
I would argue that the man page for one's specific shell is a better reference than the abstract POSIX specs. The POSIX specs tell you what *should* happen, while the man page will tell what *WILL* happen. The
later is, in the real world, of much greater importance.
Particularly for someone as literal-minded and "I just want it to work" focused as this OP.
P.S. Incidentally, the text you supplied (from the POSIX specs) does appear in "man bash" word-for-word (or very close to it). It is just formatted differently. I mention this only for the benefit of OP, because, as I've said
this OP is very literal-minded.
But the Bash manual page is rather difficult to navigate, partly
because so much is dedicated to all the various extension features,
and partly because there's no singular section that concisely details
the most basic semantics of the shell.
The POSIX specification is much more clear, IMHO, particularly with
regard to basic shell semantics. POSIX 1003.1-2017 volume 3, chapter
2, "Shell Command Language", is the most concise *and* comprehensive description I've yet seen of the Unix shell.
Attentively spending 20-30 minutes reading sections 1-13, top to
bottom, can provide more substance and context than the vast majority
of people ever learn through experience and poking around vendor
manual pages. And after doing it once, whenever you're unsure about a behavior, you'll know *exactly* where to navigate, as opposed to
grep'ing through the manual page, never being sure about unknown
caveats and relationships described in sections far removed.
people already familiar with the "documentation" still spend an
inordinate amount of time Google'ing for answers rather than first
going straight to the [supposedly] primary source.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 293 |
Nodes: | 16 (2 / 14) |
Uptime: | 231:46:52 |
Calls: | 6,624 |
Files: | 12,171 |
Messages: | 5,319,444 |