Exit statuses of comparisons in test constructs
I was writing some "if then" statements and found what seemed to me an odd behavior. Upon investigation I realized that it boiled down to the exit code of the comparison I was making. I illustrate my findings in the following code snippet.
As you can see
rc=1
[ $rc -eq 0 ]
es_num=$?
[ $rc=0 ]
es_str=$?
echo "es_num is $es_num"
echo "es_str is $es_str"
Outputs
es_num is 1
es_str is 0
Is there any documentation, preferably from the POSIX standards, that talks about the difference in the exit statuses of -eq and = in a test construct?
What should I be aware of when writing conditional statements? What are some best practices regarding this?
Portable code is preferable to Bash code (which I'm using).
test control-flow
asked 12 hours ago
EleganceElegance
183
New contributor
Elegance is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
I was writing some "if then" statements and found what seemed to me an odd behavior. Upon investigation I realized that it boiled down to the exit code of the comparison I was making. I illustrate my findings in the following code snippet.
As you can see
rc=1
[ $rc -eq 0 ]
es_num=$?
[ $rc=0 ]
es_str=$?
echo "es_num is $es_num"
echo "es_str is $es_str"
Outputs
es_num is 1
es_str is 0
Is there any documentation, preferably from the POSIX standards, that talks about the difference in the exit statuses of -eq and = in a test construct?
What should I be aware of when writing conditional statements? What are some best practices regarding this?
Portable code is preferable to Bash code (which I'm using).
test control-flow
asked 12 hours ago
EleganceElegance
183
New contributor
Elegance is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I didn't know about the space being necessary. What I meant with "odd" is "weird if you read as pseudo code, ignoring the quirks of the language". Thanks. @ilkkachu
– Elegance
11 hours ago
1
The only way I can get[ $rc=0 ]to fail withrc=1is to setIFSto 1 as well. That would cause both tests to error out and set$?to 2 (inbash).
– Kusalananda
11 hours ago
@ilkkachu There was a typo. Of course I can't ignore them, but if I knew them, I wouldn't have to ask. That's exactly the point of the question.
– Elegance
9 hours ago
@Elegance, ok, good, thanks. And yes, you're right, you wouldn't have to ask if you knew. It's just that even a typo like that can send the readers off in the wrong direction, looking for some really weird edge case that could explain the result. (The shell can be a bit quirky sometimes so there might have been a remote possibility of an edge case where both would return1...)
– ilkkachu
9 hours ago
@ilkkachu Thank you for the helpful feedback.
– Elegance
9 hours ago
add a comment |
I was writing some "if then" statements and found what seemed to me an odd behavior. Upon investigation I realized that it boiled down to the exit code of the comparison I was making. I illustrate my findings in the following code snippet.
As you can see
rc=1
[ $rc -eq 0 ]
es_num=$?
[ $rc=0 ]
es_str=$?
echo "es_num is $es_num"
echo "es_str is $es_str"
Outputs
es_num is 1
es_str is 0
Is there any documentation, preferably from the POSIX standards, that talks about the difference in the exit statuses of -eq and = in a test construct?
What should I be aware of when writing conditional statements? What are some best practices regarding this?
Portable code is preferable to Bash code (which I'm using).
test control-flow
asked 12 hours ago
EleganceElegance
183
New contributor
Elegance is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I was writing some "if then" statements and found what seemed to me an odd behavior. Upon investigation I realized that it boiled down to the exit code of the comparison I was making. I illustrate my findings in the following code snippet.
As you can see
rc=1
[ $rc -eq 0 ]
es_num=$?
[ $rc=0 ]
es_str=$?
echo "es_num is $es_num"
echo "es_str is $es_str"
Outputs
es_num is 1
es_str is 0
Is there any documentation, preferably from the POSIX standards, that talks about the difference in the exit statuses of -eq and = in a test construct?
What should I be aware of when writing conditional statements? What are some best practices regarding this?
Portable code is preferable to Bash code (which I'm using).
test control-flow
test control-flow
asked 12 hours ago
EleganceElegance
183
New contributor
Elegance is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 12 hours ago
EleganceElegance
183
New contributor
Elegance is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 9 hours ago
Elegance
asked 12 hours ago
EleganceElegance
183
New contributor
Elegance is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 12 hours ago
EleganceElegance
183
asked 12 hours ago
EleganceElegance
183
183
New contributor
Elegance is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Elegance is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Elegance is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I didn't know about the space being necessary. What I meant with "odd" is "weird if you read as pseudo code, ignoring the quirks of the language". Thanks. @ilkkachu
– Elegance
11 hours ago
1
The only way I can get[ $rc=0 ]to fail withrc=1is to setIFSto 1 as well. That would cause both tests to error out and set$?to 2 (inbash).
– Kusalananda
11 hours ago
@ilkkachu There was a typo. Of course I can't ignore them, but if I knew them, I wouldn't have to ask. That's exactly the point of the question.
– Elegance
9 hours ago
@Elegance, ok, good, thanks. And yes, you're right, you wouldn't have to ask if you knew. It's just that even a typo like that can send the readers off in the wrong direction, looking for some really weird edge case that could explain the result. (The shell can be a bit quirky sometimes so there might have been a remote possibility of an edge case where both would return1...)
– ilkkachu
9 hours ago
@ilkkachu Thank you for the helpful feedback.
– Elegance
9 hours ago
add a comment |
I didn't know about the space being necessary. What I meant with "odd" is "weird if you read as pseudo code, ignoring the quirks of the language". Thanks. @ilkkachu
– Elegance
11 hours ago
1
The only way I can get[ $rc=0 ]to fail withrc=1is to setIFSto 1 as well. That would cause both tests to error out and set$?to 2 (inbash).
– Kusalananda
11 hours ago
@ilkkachu There was a typo. Of course I can't ignore them, but if I knew them, I wouldn't have to ask. That's exactly the point of the question.
– Elegance
9 hours ago
@Elegance, ok, good, thanks. And yes, you're right, you wouldn't have to ask if you knew. It's just that even a typo like that can send the readers off in the wrong direction, looking for some really weird edge case that could explain the result. (The shell can be a bit quirky sometimes so there might have been a remote possibility of an edge case where both would return1...)
– ilkkachu
9 hours ago
@ilkkachu Thank you for the helpful feedback.
– Elegance
9 hours ago
I didn't know about the space being necessary. What I meant with "odd" is "weird if you read as pseudo code, ignoring the quirks of the language". Thanks. @ilkkachu
– Elegance
11 hours ago
I didn't know about the space being necessary. What I meant with "odd" is "weird if you read as pseudo code, ignoring the quirks of the language". Thanks. @ilkkachu
– Elegance
11 hours ago
1
1
The only way I can get
[ $rc=0 ] to fail with rc=1 is to set IFS to 1 as well. That would cause both tests to error out and set $? to 2 (in bash).– Kusalananda
11 hours ago
The only way I can get
[ $rc=0 ] to fail with rc=1 is to set IFS to 1 as well. That would cause both tests to error out and set $? to 2 (in bash).– Kusalananda
11 hours ago
@ilkkachu There was a typo. Of course I can't ignore them, but if I knew them, I wouldn't have to ask. That's exactly the point of the question.
– Elegance
9 hours ago
@ilkkachu There was a typo. Of course I can't ignore them, but if I knew them, I wouldn't have to ask. That's exactly the point of the question.
– Elegance
9 hours ago
@Elegance, ok, good, thanks. And yes, you're right, you wouldn't have to ask if you knew. It's just that even a typo like that can send the readers off in the wrong direction, looking for some really weird edge case that could explain the result. (The shell can be a bit quirky sometimes so there might have been a remote possibility of an edge case where both would return
1...)– ilkkachu
9 hours ago
@Elegance, ok, good, thanks. And yes, you're right, you wouldn't have to ask if you knew. It's just that even a typo like that can send the readers off in the wrong direction, looking for some really weird edge case that could explain the result. (The shell can be a bit quirky sometimes so there might have been a remote possibility of an edge case where both would return
1...)– ilkkachu
9 hours ago
@ilkkachu Thank you for the helpful feedback.
– Elegance
9 hours ago
@ilkkachu Thank you for the helpful feedback.
– Elegance
9 hours ago
add a comment |
2 Answers
2
active
oldest
votes
-eq
True if the integers n1 and n2 are algebraically equal; otherwise, false.
test
=
True if the strings s1 and s2 are identical; otherwise, false.
test
So -eq compares integers and = compares strings (which will also work with some limited integer cases).
You do have a syntax issue though, it should be:
[ "$rc" = 0 ]
And not
[ $rc=0 ]
[ "$rc" = 0 ] should exit with 1 because rc does not equal 0
[ $rc=0 ] should actually exit with 0 because it's likely going to be treated as a string and the presence of a string within the [ test construct will evaluate to true
With the sh [ test there are a few differences:
# leading 0
$ [ 01 -eq 1 ]; echo $?
0
# adjacent whitespace
$ [ ' 1' -eq 1 ]; echo $?
0
# negative 0 vs positive 0
$ [ 0 -eq -0 ]; echo $?
0
However with the bash [[ test there are a large number of differences (Including the ones mentioned above):
# base 8
$ [[ 032 -eq 26 ]]; echo $?
0
# Arithmetic expressions
$ [[ 1*6+32/15*2-1 -eq 9 ]]; echo $?
0
# Base 64
$ [[ 64#Hello_world -eq -5506400892957379251 ]]; echo $?
0
answered 12 hours ago
Jesse_bJesse_b
13.2k23369
I'm just a bit confused about what is meant by numeric and string comparisons. Let's say I use=to compare numbers. When is it not going to not yield the same result as a numeric comparison?
– Elegance
11 hours ago
Any examples with strings that have nothing but digits, and don't have leading zeros?
– Elegance
11 hours ago
1
@Elegance The point is that with-eq, the left and right hand side are compared as integers, not as strings. The test would evaluate the strings as integers (probably by passing them throughstrtol()or some such C function) before carrying out the comparison.
– Kusalananda
11 hours ago
1
@Elegance In abashtest with[[ ... -eq ... ]]you could even have arithmetic calculations on either side, as in[[ 1+1 -eq 2 ]]. Obviously,[[ 1+1 == 2 ]]would not be true.
– Kusalananda
11 hours ago
@Jesse_b You shared the same link twice. I take it the first one is incorrect.
– Elegance
9 hours ago
|
show 1 more comment
For numeric comparisons you have to use -eq whereas = is for string comparisons (as from your variable naming you already seem to know).
One of the best introductions on the test aka [ command I know is The Unix Shell's Humble If
answered 12 hours ago
freiheitsnetzfreiheitsnetz
112
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
});
}
});
Elegance is a new contributor. Be nice, and check out our Code of Conduct.
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%2f504979%2fexit-statuses-of-comparisons-in-test-constructs%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
-eq
True if the integers n1 and n2 are algebraically equal; otherwise, false.
test
=
True if the strings s1 and s2 are identical; otherwise, false.
test
So -eq compares integers and = compares strings (which will also work with some limited integer cases).
You do have a syntax issue though, it should be:
[ "$rc" = 0 ]
And not
[ $rc=0 ]
[ "$rc" = 0 ] should exit with 1 because rc does not equal 0
[ $rc=0 ] should actually exit with 0 because it's likely going to be treated as a string and the presence of a string within the [ test construct will evaluate to true
With the sh [ test there are a few differences:
# leading 0
$ [ 01 -eq 1 ]; echo $?
0
# adjacent whitespace
$ [ ' 1' -eq 1 ]; echo $?
0
# negative 0 vs positive 0
$ [ 0 -eq -0 ]; echo $?
0
However with the bash [[ test there are a large number of differences (Including the ones mentioned above):
# base 8
$ [[ 032 -eq 26 ]]; echo $?
0
# Arithmetic expressions
$ [[ 1*6+32/15*2-1 -eq 9 ]]; echo $?
0
# Base 64
$ [[ 64#Hello_world -eq -5506400892957379251 ]]; echo $?
0
answered 12 hours ago
Jesse_bJesse_b
13.2k23369
I'm just a bit confused about what is meant by numeric and string comparisons. Let's say I use=to compare numbers. When is it not going to not yield the same result as a numeric comparison?
– Elegance
11 hours ago
Any examples with strings that have nothing but digits, and don't have leading zeros?
– Elegance
11 hours ago
1
@Elegance The point is that with-eq, the left and right hand side are compared as integers, not as strings. The test would evaluate the strings as integers (probably by passing them throughstrtol()or some such C function) before carrying out the comparison.
– Kusalananda
11 hours ago
1
@Elegance In abashtest with[[ ... -eq ... ]]you could even have arithmetic calculations on either side, as in[[ 1+1 -eq 2 ]]. Obviously,[[ 1+1 == 2 ]]would not be true.
– Kusalananda
11 hours ago
@Jesse_b You shared the same link twice. I take it the first one is incorrect.
– Elegance
9 hours ago
|
show 1 more comment
-eq
True if the integers n1 and n2 are algebraically equal; otherwise, false.
test
=
True if the strings s1 and s2 are identical; otherwise, false.
test
So -eq compares integers and = compares strings (which will also work with some limited integer cases).
You do have a syntax issue though, it should be:
[ "$rc" = 0 ]
And not
[ $rc=0 ]
[ "$rc" = 0 ] should exit with 1 because rc does not equal 0
[ $rc=0 ] should actually exit with 0 because it's likely going to be treated as a string and the presence of a string within the [ test construct will evaluate to true
With the sh [ test there are a few differences:
# leading 0
$ [ 01 -eq 1 ]; echo $?
0
# adjacent whitespace
$ [ ' 1' -eq 1 ]; echo $?
0
# negative 0 vs positive 0
$ [ 0 -eq -0 ]; echo $?
0
However with the bash [[ test there are a large number of differences (Including the ones mentioned above):
# base 8
$ [[ 032 -eq 26 ]]; echo $?
0
# Arithmetic expressions
$ [[ 1*6+32/15*2-1 -eq 9 ]]; echo $?
0
# Base 64
$ [[ 64#Hello_world -eq -5506400892957379251 ]]; echo $?
0
answered 12 hours ago
Jesse_bJesse_b
13.2k23369
I'm just a bit confused about what is meant by numeric and string comparisons. Let's say I use=to compare numbers. When is it not going to not yield the same result as a numeric comparison?
– Elegance
11 hours ago
Any examples with strings that have nothing but digits, and don't have leading zeros?
– Elegance
11 hours ago
1
@Elegance The point is that with-eq, the left and right hand side are compared as integers, not as strings. The test would evaluate the strings as integers (probably by passing them throughstrtol()or some such C function) before carrying out the comparison.
– Kusalananda
11 hours ago
1
@Elegance In abashtest with[[ ... -eq ... ]]you could even have arithmetic calculations on either side, as in[[ 1+1 -eq 2 ]]. Obviously,[[ 1+1 == 2 ]]would not be true.
– Kusalananda
11 hours ago
@Jesse_b You shared the same link twice. I take it the first one is incorrect.
– Elegance
9 hours ago
|
show 1 more comment
-eq
True if the integers n1 and n2 are algebraically equal; otherwise, false.
test
=
True if the strings s1 and s2 are identical; otherwise, false.
test
So -eq compares integers and = compares strings (which will also work with some limited integer cases).
You do have a syntax issue though, it should be:
[ "$rc" = 0 ]
And not
[ $rc=0 ]
[ "$rc" = 0 ] should exit with 1 because rc does not equal 0
[ $rc=0 ] should actually exit with 0 because it's likely going to be treated as a string and the presence of a string within the [ test construct will evaluate to true
With the sh [ test there are a few differences:
# leading 0
$ [ 01 -eq 1 ]; echo $?
0
# adjacent whitespace
$ [ ' 1' -eq 1 ]; echo $?
0
# negative 0 vs positive 0
$ [ 0 -eq -0 ]; echo $?
0
However with the bash [[ test there are a large number of differences (Including the ones mentioned above):
# base 8
$ [[ 032 -eq 26 ]]; echo $?
0
# Arithmetic expressions
$ [[ 1*6+32/15*2-1 -eq 9 ]]; echo $?
0
# Base 64
$ [[ 64#Hello_world -eq -5506400892957379251 ]]; echo $?
0
answered 12 hours ago
Jesse_bJesse_b
13.2k23369
-eq
True if the integers n1 and n2 are algebraically equal; otherwise, false.
test
=
True if the strings s1 and s2 are identical; otherwise, false.
test
So -eq compares integers and = compares strings (which will also work with some limited integer cases).
You do have a syntax issue though, it should be:
[ "$rc" = 0 ]
And not
[ $rc=0 ]
[ "$rc" = 0 ] should exit with 1 because rc does not equal 0
[ $rc=0 ] should actually exit with 0 because it's likely going to be treated as a string and the presence of a string within the [ test construct will evaluate to true
With the sh [ test there are a few differences:
# leading 0
$ [ 01 -eq 1 ]; echo $?
0
# adjacent whitespace
$ [ ' 1' -eq 1 ]; echo $?
0
# negative 0 vs positive 0
$ [ 0 -eq -0 ]; echo $?
0
However with the bash [[ test there are a large number of differences (Including the ones mentioned above):
# base 8
$ [[ 032 -eq 26 ]]; echo $?
0
# Arithmetic expressions
$ [[ 1*6+32/15*2-1 -eq 9 ]]; echo $?
0
# Base 64
$ [[ 64#Hello_world -eq -5506400892957379251 ]]; echo $?
0
answered 12 hours ago
Jesse_bJesse_b
13.2k23369
edited 10 hours ago
answered 12 hours ago
Jesse_bJesse_b
13.2k23369
answered 12 hours ago
Jesse_bJesse_b
13.2k23369
answered 12 hours ago
Jesse_bJesse_b
13.2k23369
13.2k23369
I'm just a bit confused about what is meant by numeric and string comparisons. Let's say I use=to compare numbers. When is it not going to not yield the same result as a numeric comparison?
– Elegance
11 hours ago
Any examples with strings that have nothing but digits, and don't have leading zeros?
– Elegance
11 hours ago
1
@Elegance The point is that with-eq, the left and right hand side are compared as integers, not as strings. The test would evaluate the strings as integers (probably by passing them throughstrtol()or some such C function) before carrying out the comparison.
– Kusalananda
11 hours ago
1
@Elegance In abashtest with[[ ... -eq ... ]]you could even have arithmetic calculations on either side, as in[[ 1+1 -eq 2 ]]. Obviously,[[ 1+1 == 2 ]]would not be true.
– Kusalananda
11 hours ago
@Jesse_b You shared the same link twice. I take it the first one is incorrect.
– Elegance
9 hours ago
|
show 1 more comment
I'm just a bit confused about what is meant by numeric and string comparisons. Let's say I use=to compare numbers. When is it not going to not yield the same result as a numeric comparison?
– Elegance
11 hours ago
Any examples with strings that have nothing but digits, and don't have leading zeros?
– Elegance
11 hours ago
1
@Elegance The point is that with-eq, the left and right hand side are compared as integers, not as strings. The test would evaluate the strings as integers (probably by passing them throughstrtol()or some such C function) before carrying out the comparison.
– Kusalananda
11 hours ago
1
@Elegance In abashtest with[[ ... -eq ... ]]you could even have arithmetic calculations on either side, as in[[ 1+1 -eq 2 ]]. Obviously,[[ 1+1 == 2 ]]would not be true.
– Kusalananda
11 hours ago
@Jesse_b You shared the same link twice. I take it the first one is incorrect.
– Elegance
9 hours ago
I'm just a bit confused about what is meant by numeric and string comparisons. Let's say I use
= to compare numbers. When is it not going to not yield the same result as a numeric comparison?– Elegance
11 hours ago
I'm just a bit confused about what is meant by numeric and string comparisons. Let's say I use
= to compare numbers. When is it not going to not yield the same result as a numeric comparison?– Elegance
11 hours ago
Any examples with strings that have nothing but digits, and don't have leading zeros?
– Elegance
11 hours ago
Any examples with strings that have nothing but digits, and don't have leading zeros?
– Elegance
11 hours ago
1
1
@Elegance The point is that with
-eq, the left and right hand side are compared as integers, not as strings. The test would evaluate the strings as integers (probably by passing them through strtol() or some such C function) before carrying out the comparison.– Kusalananda
11 hours ago
@Elegance The point is that with
-eq, the left and right hand side are compared as integers, not as strings. The test would evaluate the strings as integers (probably by passing them through strtol() or some such C function) before carrying out the comparison.– Kusalananda
11 hours ago
1
1
@Elegance In a
bash test with [[ ... -eq ... ]] you could even have arithmetic calculations on either side, as in [[ 1+1 -eq 2 ]]. Obviously, [[ 1+1 == 2 ]] would not be true.– Kusalananda
11 hours ago
@Elegance In a
bash test with [[ ... -eq ... ]] you could even have arithmetic calculations on either side, as in [[ 1+1 -eq 2 ]]. Obviously, [[ 1+1 == 2 ]] would not be true.– Kusalananda
11 hours ago
@Jesse_b You shared the same link twice. I take it the first one is incorrect.
– Elegance
9 hours ago
@Jesse_b You shared the same link twice. I take it the first one is incorrect.
– Elegance
9 hours ago
|
show 1 more comment
For numeric comparisons you have to use -eq whereas = is for string comparisons (as from your variable naming you already seem to know).
One of the best introductions on the test aka [ command I know is The Unix Shell's Humble If
answered 12 hours ago
freiheitsnetzfreiheitsnetz
112
add a comment |
For numeric comparisons you have to use -eq whereas = is for string comparisons (as from your variable naming you already seem to know).
One of the best introductions on the test aka [ command I know is The Unix Shell's Humble If
answered 12 hours ago
freiheitsnetzfreiheitsnetz
112
add a comment |
For numeric comparisons you have to use -eq whereas = is for string comparisons (as from your variable naming you already seem to know).
One of the best introductions on the test aka [ command I know is The Unix Shell's Humble If
answered 12 hours ago
freiheitsnetzfreiheitsnetz
112
For numeric comparisons you have to use -eq whereas = is for string comparisons (as from your variable naming you already seem to know).
One of the best introductions on the test aka [ command I know is The Unix Shell's Humble If
answered 12 hours ago
freiheitsnetzfreiheitsnetz
112
answered 12 hours ago
freiheitsnetzfreiheitsnetz
112
answered 12 hours ago
freiheitsnetzfreiheitsnetz
112
answered 12 hours ago
freiheitsnetzfreiheitsnetz
112
112
add a comment |
add a comment |
Elegance is a new contributor. Be nice, and check out our Code of Conduct.
Elegance is a new contributor. Be nice, and check out our Code of Conduct.
Elegance is a new contributor. Be nice, and check out our Code of Conduct.
Elegance is a new contributor. Be nice, and check out our Code of Conduct.
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%2f504979%2fexit-statuses-of-comparisons-in-test-constructs%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
I didn't know about the space being necessary. What I meant with "odd" is "weird if you read as pseudo code, ignoring the quirks of the language". Thanks. @ilkkachu
– Elegance
11 hours ago
1
The only way I can get
[ $rc=0 ]to fail withrc=1is to setIFSto 1 as well. That would cause both tests to error out and set$?to 2 (inbash).– Kusalananda
11 hours ago
@ilkkachu There was a typo. Of course I can't ignore them, but if I knew them, I wouldn't have to ask. That's exactly the point of the question.
– Elegance
9 hours ago
@Elegance, ok, good, thanks. And yes, you're right, you wouldn't have to ask if you knew. It's just that even a typo like that can send the readers off in the wrong direction, looking for some really weird edge case that could explain the result. (The shell can be a bit quirky sometimes so there might have been a remote possibility of an edge case where both would return
1...)– ilkkachu
9 hours ago
@ilkkachu Thank you for the helpful feedback.
– Elegance
9 hours ago