github-mirror/fish-shell
2
0
Fork 0
mirror of https://github.com/fish-shell/fish-shell.git synced 2024-11-28 12:13:55 +08:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity
f1e19884fb
fish-shell/tests/checks/count.fish

51 lines
724 B
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 %s
`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.
Port count test to littlecheck
2019-06-27 00:57:10 +08:00
# 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
Port count test to littlecheck
2019-06-27 00:57:10 +08:00
# CHECK: 0
`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
Port count test to littlecheck
2019-06-27 00:57:10 +08:00
# 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
Port count test to littlecheck
2019-06-27 00:57:10 +08:00
# CHECK: 1
`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
Port count test to littlecheck
2019-06-27 00:57:10 +08:00
# 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
Port count test to littlecheck
2019-06-27 00:57:10 +08:00
# CHECK: 2
`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
Port count test to littlecheck
2019-06-27 00:57:10 +08:00
# 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
Port count test to littlecheck
2019-06-27 00:57:10 +08:00
# CHECK: 1
`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 --help
Port count test to littlecheck
2019-06-27 00:57:10 +08:00
# CHECK: 1
`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 --
Port count test to littlecheck
2019-06-27 00:57:10 +08:00
# CHECK: 1
`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 -- abc
Port count test to littlecheck
2019-06-27 00:57:10 +08:00
# CHECK: 2
`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 def -- abc
Port count test to littlecheck
2019-06-27 00:57:10 +08:00
# CHECK: 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 17:58:06 +08:00
Port count test to littlecheck
2019-06-27 00:57:10 +08:00
# big counts
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
# 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] 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 07:42:12 +08:00
Port count test to littlecheck
2019-06-27 00:57:10 +08:00
# stdin
[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 07:42:12 +08:00
# Reading from stdin still counts the arguments
printf '%s\n' 1 2 3 4 5 | count 6 7 8 9 10
Port count test to littlecheck
2019-06-27 00:57:10 +08:00
# CHECK: 10
[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 07:42:12 +08:00
# Reading from stdin counts newlines - like `wc -l`.
echo -n 0 | count
Port count test to littlecheck
2019-06-27 00:57:10 +08:00
# CHECK: 0
[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 07:42:12 +08:00
echo 1 | count
Port count test to littlecheck
2019-06-27 00:57:10 +08:00
# CHECK: 1
Reference in New Issue Copy Permalink