1 # Test numbers bigger than 255 (2^8 - 1) and bigger than 2^31 - 1
2 # Shells differ in their behavior here. bash silently converts.
3
4 # I think we should implement the "unstrict" but deterministic bash behavior
5 # for compatibility, and then add shopt -s strict_status if we need it.
6
7 #### Truncating 'exit' status
8
9 $SH -c 'exit 255'
10 echo status=$?
11
12 $SH -c 'exit 256'
13 echo status=$?
14
15 $SH -c 'exit 257'
16 echo status=$?
17
18 echo ===
19
20 $SH -c 'exit -1'
21 echo status=$?
22
23 $SH -c 'exit -2'
24 echo status=$?
25
26 ## STDOUT:
27 status=255
28 status=0
29 status=1
30 ===
31 status=255
32 status=254
33 ## END
34 ## OK dash STDOUT:
35 status=255
36 status=0
37 status=1
38 ===
39 status=2
40 status=2
41 ## END
42
43 #### Truncating 'return' status
44 f() { return 255; }; f
45 echo status=$?
46
47 f() { return 256; }; f
48 echo status=$?
49
50 f() { return 257; }; f
51 echo status=$?
52
53 echo ===
54
55 f() { return -1; }; f
56 echo status=$?
57
58 f() { return -2; }; f
59 echo status=$?
60
61 ## STDOUT:
62 status=255
63 status=0
64 status=1
65 ===
66 status=255
67 status=254
68 ## END
69
70 # dash aborts on bad exit code
71 ## OK dash status: 2
72 ## OK dash STDOUT:
73 status=255
74 status=256
75 status=257
76 ===
77 ## END
78
79
80 #### subshell OverflowError https://github.com/oilshell/oil/issues/996
81
82 # We have to capture stderr here
83
84 filter_err() {
85 # check for bash/dash/mksh messages, and unwanted Python OverflowError
86 egrep -o 'Illegal number|bad number|return: can only|OverflowError'
87 return 0
88 }
89
90 # true; disables subshell optimization!
91
92 # exit status too big, but integer isn't
93 $SH -c 'true; ( return 2147483647; )' 2>err.txt
94 echo status=$?
95 cat err.txt | filter_err
96
97 # now integer is too big
98 $SH -c 'true; ( return 2147483648; )' 2> err.txt
99 echo status=$?
100 cat err.txt | filter_err
101
102 # even bigger
103 $SH -c 'true; ( return 2147483649; )' 2> err.txt
104 echo status=$?
105 cat err.txt | filter_err
106
107 ## STDOUT:
108 ## END
109
110 # Other shells check this error, but let's just truncate deterministically
111
112 ## STDOUT:
113 status=255
114 status=0
115 status=1
116 ## END
117
118 # dash uses '2' as its "bad status" status!
119
120 ## OK dash STDOUT:
121 status=255
122 status=2
123 Illegal number
124 status=2
125 Illegal number
126 ## END
127
128 # mksh uses '1' as its "bad status" status!
129
130 ## OK mksh STDOUT:
131 status=255
132 status=1
133 bad number
134 status=1
135 bad number
136 ## END
137
138 # bash disallows return
139 ## OK bash STDOUT:
140 status=1
141 return: can only
142 status=1
143 return: can only
144 status=1
145 return: can only
146 ## END
147
148
149 #### func subshell OverflowError https://github.com/oilshell/oil/issues/996
150
151 # We have to capture stderr here
152
153 filter_err() {
154 # check for bash/dash/mksh messages, and unwanted Python OverflowError
155 egrep -o 'Illegal number|bad number|return: can only|OverflowError'
156 return 0
157 }
158
159 # exit status too big, but integer isn't
160 $SH -c 'f() ( return 2147483647; ); f' 2>err.txt
161 echo status=$?
162 cat err.txt | filter_err
163
164 # now integer is too big
165 $SH -c 'f() ( return 2147483648; ); f' 2> err.txt
166 echo status=$?
167 cat err.txt | filter_err
168
169 # even bigger
170 $SH -c 'f() ( return 2147483649; ); f' 2> err.txt
171 echo status=$?
172 cat err.txt | filter_err
173
174 ## STDOUT:
175 status=255
176 status=0
177 status=1
178 ## END
179
180 ## OK dash STDOUT:
181 status=255
182 status=2
183 Illegal number
184 status=2
185 Illegal number
186 ## END
187
188 # bash truncates it to 0 here
189 ## OK bash STDOUT:
190 status=255
191 status=0
192 status=1
193 ## END
194
195 ## OK mksh STDOUT:
196 status=255
197 status=1
198 bad number
199 status=1
200 bad number
201 ## END
202
203
204 # Weird case from bash-help mailing list.
205 #
206 # "Evaluations of backticks in if statements". It doesn't relate to if
207 # statements but to $?, since && and || behave the same way.
208
209 # POSIX has a special rule for this. In OSH strict_argv is preferred so it
210 # becomes a moot point. I think this is an artifact of the
211 # "stateful"/imperative nature of $? -- it can be "left over" from a prior
212 # command, and sometimes the prior argv is []. OSH has a more "functional"
213 # implementation so it doesn't have this weirdness.
214
215 #### If empty command
216 if ''; then echo TRUE; else echo FALSE; fi
217 ## stdout: FALSE
218 ## status: 0
219
220 #### If subshell true
221 if `true`; then echo TRUE; else echo FALSE; fi
222 ## stdout: TRUE
223 ## status: 0
224
225 #### If subshell true WITH OUTPUT is different
226 if `sh -c 'echo X; true'`; then echo TRUE; else echo FALSE; fi
227 ## stdout: FALSE
228 ## status: 0
229
230 #### If subshell true WITH ARGUMENT
231 if `true` X; then echo TRUE; else echo FALSE; fi
232 ## stdout: FALSE
233 ## status: 0
234
235 #### If subshell false -- exit code is propagated in a weird way (strict_argv prevents)
236 if `false`; then echo TRUE; else echo FALSE; fi
237 ## stdout: FALSE
238 ## status: 0