1 |
|
2 |
# Weird case from bash-help mailing list. |
3 |
# |
4 |
# "Evaluations of backticks in if statements". It doesn't relate to if |
5 |
# statements but to $?, since && and || behave the same way. |
6 |
|
7 |
# POSIX has a special rule for this. In OSH strict_argv is preferred so it |
8 |
# becomes a moot point. I think this is an artifact of the |
9 |
# "stateful"/imperative nature of $? -- it can be "left over" from a prior |
10 |
# command, and sometimes the prior argv is []. OSH has a more "functional" |
11 |
# implementation so it doesn't have this weirdness. |
12 |
|
13 |
#### If empty command |
14 |
if ''; then echo TRUE; else echo FALSE; fi |
15 |
## stdout: FALSE |
16 |
## status: 0 |
17 |
|
18 |
#### If subshell true |
19 |
if `true`; then echo TRUE; else echo FALSE; fi |
20 |
## stdout: TRUE |
21 |
## status: 0 |
22 |
|
23 |
#### If subshell true WITH OUTPUT is different |
24 |
if `sh -c 'echo X; true'`; then echo TRUE; else echo FALSE; fi |
25 |
## stdout: FALSE |
26 |
## status: 0 |
27 |
|
28 |
#### If subshell true WITH ARGUMENT |
29 |
if `true` X; then echo TRUE; else echo FALSE; fi |
30 |
## stdout: FALSE |
31 |
## status: 0 |
32 |
|
33 |
#### If subshell false -- exit code is propagated in a weird way (strict_argv prevents) |
34 |
if `false`; then echo TRUE; else echo FALSE; fi |
35 |
## stdout: FALSE |
36 |
## status: 0 |