tests/count.out


####################
# no args
0

####################
# one args
1

####################
# two args
2

####################
# args that look like flags or are otherwise special
1
1
1
2
3

####################
# big counts

####################
# stdin
10
0
1
use new `logmsg` and `set --show` in tests 2017-08-04 11:41:51 -07:00
			`####################`
`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-05 17:22:48 -07:00			`# no args`
			`0`
use new `logmsg` and `set --show` in tests 2017-08-04 11:41:51 -07:00
			`####################`
`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-05 17:22:48 -07:00			`# one args`
			`1`
use new `logmsg` and `set --show` in tests 2017-08-04 11:41:51 -07:00
			`####################`
`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-05 17:22:48 -07:00			`# two args`
			`2`
use new `logmsg` and `set --show` in tests 2017-08-04 11:41:51 -07:00
			`####################`
`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-05 17:22:48 -07:00			`# args that look like flags or are otherwise special`
			`1`
			`1`
			`1`
			`2`
			`3`
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 01:58:06 -08:00
			`####################`
			`# big counts`
[count] Allow counting lines from stdin As a simple replacement for `wc -l`. This counts both lines on stdin _and_ arguments. So if "file" has three lines, then `count a b c < file` will print 6. And since it counts newlines, like wc, `echo -n foo \| count` prints 0. 2018-01-04 00:42:12 +01:00
			`####################`
			`# stdin`
			`10`
			`0`
			`1`