fish-shell/tests/count.in

# Validate the behavior of the `count` command.

logmsg no args
count

logmsg one args
count x

logmsg two args
count x y

logmsg args that look like flags or are otherwise special
count -h
count --help
count --
count -- abc
count def -- abc

logmsg big counts

# See #5611
for i in seq 500
    set c1 (count (seq 1 10000))
    test $c1 -eq 10000
    or begin
        echo "Count $c1 is not 10000"
        break
    end
end
`count -h` should report 1 The count command should not treat any flag specially. Not even `-h` and `--help`. It should simply return a count of the number of arguments it received. Fixes #4189 2017-07-06 08:22:48 +08:00			# Validate the behavior of the `count` command.

use new `logmsg` and `set --show` in tests 2017-08-05 02:41:51 +08:00			`logmsg no args`
`count -h` should report 1 The count command should not treat any flag specially. Not even `-h` and `--help`. It should simply return a count of the number of arguments it received. Fixes #4189 2017-07-06 08:22:48 +08:00			`count`

use new `logmsg` and `set --show` in tests 2017-08-05 02:41:51 +08:00			`logmsg one args`
`count -h` should report 1 The count command should not treat any flag specially. Not even `-h` and `--help`. It should simply return a count of the number of arguments it received. Fixes #4189 2017-07-06 08:22:48 +08:00			`count x`

use new `logmsg` and `set --show` in tests 2017-08-05 02:41:51 +08:00			`logmsg two args`
`count -h` should report 1 The count command should not treat any flag specially. Not even `-h` and `--help`. It should simply return a count of the number of arguments it received. Fixes #4189 2017-07-06 08:22:48 +08:00			`count x y`

use new `logmsg` and `set --show` in tests 2017-08-05 02:41:51 +08:00			`logmsg args that look like flags or are otherwise special`
`count -h` should report 1 The count command should not treat any flag specially. Not even `-h` and `--help`. It should simply return a count of the number of arguments it received. Fixes #4189 2017-07-06 08:22:48 +08:00			`count -h`
			`count --help`
			`count --`
			`count -- abc`
			`count def -- abc`
Fill io_buffer via background thread This is a large change to how io_buffers are filled. The essential problem comes about with code like (example): echo ( /bin/pwd ) The output of /bin/pwd must go to fish, not the tty. To arrange for this, fish does the following: 1. Invoke pipe() to create a pipe. 2. Add an io_bufferfill_t redirection that owns the write end of the pipe. 3. After fork (or equiv), call dup2() to replace pwd's stdout with this pipe. Now when /bin/pwd writes, it will send output to the read end of the pipe. But who reads it? Prior to this fix, fish would do the following in a loop: 1. select() on the pipe with a 10 msec timeout 2. waitpid(WNOHANG) on the pwd proc This polling is ugly and confusing and is what is replaced here. With this new change, fish now reads from the pipe via a background thread: 1. Spawn a background pthread, which select()s on the pipe's read end with a long (100 msec) timeout. 2. In the foreground, waitpid() (allowing hanging) on the pwd proc. The big win here is a major simplification of job_t::continue_job() since it no longer has to worry about filling buffers. This will make things easier for concurrent execution. It may not be obvious why the background thread still needs a poll (100 msec). The answer is for cases where the write end of the fd escapes, in particular background processes invoked inside command substitutions. psub is perhaps the only important case of this (other shells typically just hang here). 2019-02-01 17:58:06 +08:00
			`logmsg big counts`

			`# See #5611`
			`for i in seq 500`
			`set c1 (count (seq 1 10000))`
			`test $c1 -eq 10000`
			`or begin`
			`echo "Count $c1 is not 10000"`
			`break`
			`end`
			`end`