fish-shell/tests/checks/invocation.fish

#RUN: %fish -C 'set -l fish %fish' %s

$fish -c "echo 1.2.3.4."
# CHECK: 1.2.3.4.

PATH= $fish -c "command a" 2>/dev/null
echo $status
# CHECK: 127

PATH= $fish -c "echo (command a)" 2>/dev/null
echo $status
# CHECK: 127
set error code on failed command substitution to 255 instead of -1 the exit status ought to be in 0-255, e.g. exit -1 2020-01-17 15:08:14 +01:00			`#RUN: %fish -C 'set -l fish %fish' %s`

			`$fish -c "echo 1.2.3.4."`
Port most of the invocation tests to littlecheck This is a bit weird sometimes, e.g. to test the return status (that fish actually returns $status), we use a #RUN line with %fish invoking %fish, so we can use the substitution. Still much nicer. The missing scripts are those that rely on config. 2019-06-25 20:47:28 +02:00			`# CHECK: 1.2.3.4.`
set error code on failed command substitution to 255 instead of -1 the exit status ought to be in 0-255, e.g. exit -1 2020-01-17 15:08:14 +01:00
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-23 17:34:46 -08:00			`PATH= $fish -c "command a" 2>/dev/null`
			`echo $status`
			`# CHECK: 127`

set error code on failed command substitution to 255 instead of -1 the exit status ought to be in 0-255, e.g. exit -1 2020-01-17 15:08:14 +01:00			`PATH= $fish -c "echo (command a)" 2>/dev/null`
			`echo $status`
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-23 17:34:46 -08:00			`# CHECK: 127`