github-mirror/fish-shell
2
0
Fork 0
mirror of https://github.com/fish-shell/fish-shell.git synced 2024-11-25 01:35:13 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity
0c5deacedc
fish-shell/tests/checks/status-value.fish

48 lines
1.1 KiB
Fish
Raw Normal View History

tests: filter control sequences only when interactive This demonstrates that we only write control sequences when interactive.
2024-04-12 18:19:32 +08:00
# RUN: %fish -C 'set -g fish %fish' %s
Rationalize $status and errors Prior to this fix, fish was rather inconsistent in when $status gets set in response to an error. For example, a failed expansion like "$foo[" would not modify $status. This makes the following inter-related changes: 1. String expansion now directly returns the value to set for $status on error. The value is always used. 2. parser_t::eval() now directly returns the proc_status_t, which cleans up a lot of call sites. 3. We expose a new function exec_subshell_for_expand() which ignores $status but returns errors specifically related to subshell expansion. 4. We reify the notion of "expansion breaking" errors. These include command-not-found, expand syntax errors, and others. The upshot is we are more consistent about always setting $status on errors.
2020-01-24 09:34:46 +08:00
# Empty commands should be 123
set empty_var
$empty_var
echo $status
# CHECK: 123
# CHECKERR: {{.*}} The expanded command was empty.
# CHECKERR: $empty_var
Add more tests These were correct, but littlecheck escapes quotes!
2022-08-12 00:20:40 +08:00
# CHECKERR: ^~~~~~~~~^
Rationalize $status and errors Prior to this fix, fish was rather inconsistent in when $status gets set in response to an error. For example, a failed expansion like "$foo[" would not modify $status. This makes the following inter-related changes: 1. String expansion now directly returns the value to set for $status on error. The value is always used. 2. parser_t::eval() now directly returns the proc_status_t, which cleans up a lot of call sites. 3. We expose a new function exec_subshell_for_expand() which ignores $status but returns errors specifically related to subshell expansion. 4. We reify the notion of "expansion breaking" errors. These include command-not-found, expand syntax errors, and others. The upshot is we are more consistent about always setting $status on errors.
2020-01-24 09:34:46 +08:00
# Failed expansions
echo "$abc["
echo $status
# CHECK: 121
# CHECKERR: {{.*}} Invalid index value
# CHECKERR: echo "$abc["
Clamp error carets to the end instead of refusing to print This skipped printing a "^" line if the start or length of the error was longer than the source. That seems like the correc thing at first glance, however it means that the caret line isn't skipped *if the file goes on*. So, for example ```fish echo "$abc[" ``` by itself, in a file or via `fish -c`, would not print an error, but ```fish echo "$abc[" true ``` would. That's not a great way to print errors. So instead we just.. imagine the start was at most at the end. The underlying issue why `echo "$abc["` causes this is that `wcstol` didn't move the end pointer for the index value (because there is no number there). I'd fix this, but apparently some of our recursive variable calls absolutely rely on this position value.
2022-08-12 01:24:41 +08:00
# CHECKERR: ^
Rationalize $status and errors Prior to this fix, fish was rather inconsistent in when $status gets set in response to an error. For example, a failed expansion like "$foo[" would not modify $status. This makes the following inter-related changes: 1. String expansion now directly returns the value to set for $status on error. The value is always used. 2. parser_t::eval() now directly returns the proc_status_t, which cleans up a lot of call sites. 3. We expose a new function exec_subshell_for_expand() which ignores $status but returns errors specifically related to subshell expansion. 4. We reify the notion of "expansion breaking" errors. These include command-not-found, expand syntax errors, and others. The upshot is we are more consistent about always setting $status on errors.
2020-01-24 09:34:46 +08:00
# Failed wildcards
echo *gibberishgibberishgibberish*
echo $status
# CHECK: 124
# CHECKERR: {{.*}} No matches for wildcard '*gibberishgibberishgibberish*'. {{.*}}
# CHECKERR: echo *gibberishgibberishgibberish*
Add acceptable errors to tests
2022-08-11 23:22:03 +08:00
# CHECKERR: ^~~~~~~~~~~~~~~~~~~~~~~~~~~~^
builtins: Don't crash for negative return values Another from the "why are we asserting instead of doing something sensible" department. The alternative is to make exit() and return() compute their own exit code, but tbh I don't want any *other* builtin to hit this either? Fixes #9659
2023-03-14 17:50:22 +08:00
$fish -c 'exit -5'
Log original exit code used when a builtin returns a negative exit code Port of b91723dab6888d25f6b959859289f2aed719992c
2024-01-05 23:52:18 +08:00
# CHECKERR: warning: builtin exit returned invalid exit code -5
builtins: Don't crash for negative return values Another from the "why are we asserting instead of doing something sensible" department. The alternative is to make exit() and return() compute their own exit code, but tbh I don't want any *other* builtin to hit this either? Fixes #9659
2023-03-14 17:50:22 +08:00
echo $status
# CHECK: 251
$fish -c 'exit -1'
Log original exit code used when a builtin returns a negative exit code Port of b91723dab6888d25f6b959859289f2aed719992c
2024-01-05 23:52:18 +08:00
# CHECKERR: warning: builtin exit returned invalid exit code -1
builtins: Don't crash for negative return values Another from the "why are we asserting instead of doing something sensible" department. The alternative is to make exit() and return() compute their own exit code, but tbh I don't want any *other* builtin to hit this either? Fixes #9659
2023-03-14 17:50:22 +08:00
echo $status
# CHECK: 255
# (we avoid 0, so this is turned into 255 again)
$fish -c 'exit -256'
Log original exit code used when a builtin returns a negative exit code Port of b91723dab6888d25f6b959859289f2aed719992c
2024-01-05 23:52:18 +08:00
# CHECKERR: warning: builtin exit returned invalid exit code -256
builtins: Don't crash for negative return values Another from the "why are we asserting instead of doing something sensible" department. The alternative is to make exit() and return() compute their own exit code, but tbh I don't want any *other* builtin to hit this either? Fixes #9659
2023-03-14 17:50:22 +08:00
echo $status
# CHECK: 255
$fish -c 'exit -512'
Log original exit code used when a builtin returns a negative exit code Port of b91723dab6888d25f6b959859289f2aed719992c
2024-01-05 23:52:18 +08:00
# CHECKERR: warning: builtin exit returned invalid exit code -512
builtins: Don't crash for negative return values Another from the "why are we asserting instead of doing something sensible" department. The alternative is to make exit() and return() compute their own exit code, but tbh I don't want any *other* builtin to hit this either? Fixes #9659
2023-03-14 17:50:22 +08:00
echo $status
# CHECK: 255
Reference in New Issue Copy Permalink