h/fish-shell
1
Fork 0
mirror of https://github.com/fish-shell/fish-shell.git synced 2026-04-21 08:51:14 -03:00
Code Issues Packages Projects Releases Wiki Activity
Files
397969ddccf05ac50f3c64ea3bf8dabfbb02276e
fish-shell/tests/checks/commandline.fish

68 lines
1.6 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 12:19:32 +02:00
#RUN: %fish %s
commandline: Add --is-valid option (#8142) * commandline: Add --is-valid option to query whether it's syntactically complete This means querying when the commandline is in a state that it could be executed. Because our `execute` bind function also inserts a newline if it isn't. One case that's not handled right now: `execute` also expands abbreviations, those can technically make the commandline invalid again. Unfortunately we have no real way to *check* without doing the replacement. Also since abbreviations are only available in command position when you _execute_ them the commandline will most likely be valid. This is enough to make transient prompts work: ```fish function reset-transient --on-event fish_postexec set -g TRANSIENT 0 end function maybe_execute if commandline --is-valid set -g TRANSIENT 1 commandline -f repaint else set -g TRANSIENT 0 end commandline -f execute end bind \r maybe_execute ``` and then in `fish_prompt` react to $TRANSIENT being set to 1.
2021-08-14 11:29:22 +02:00
builtins commandline/complete: allow handling commandline before reader initialization Commands like "commandline foo" silently fail, and "complete -C" fails with a weird "option requires an argument" error. I think at least the first one can be useful in edge cases, e.g. to test code that does not separate the `commandline` input and output (#11570), and to set fish's initial commandline, see the next commit. I don't think there are super strong reasons to allow these, but if the existing state is merely due to "no one has ever thought of doing this", then we should try changing it. For consistency, also allow "complete -C". I guess an argument for that is that it's weird to make a command behave differently in non-interactive shells. For now, keep the historical behavior of disabling access to the command line in non-interactive shells. If we find a good reason for allowing that (which seems unlikely), we can. Ref: https://github.com/fish-shell/fish-shell/pull/11570#discussion_r2144544053 Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
2025-06-13 07:55:09 -07:00
set -g fish (status fish-path)
commandline: Add --is-valid option (#8142) * commandline: Add --is-valid option to query whether it's syntactically complete This means querying when the commandline is in a state that it could be executed. Because our `execute` bind function also inserts a newline if it isn't. One case that's not handled right now: `execute` also expands abbreviations, those can technically make the commandline invalid again. Unfortunately we have no real way to *check* without doing the replacement. Also since abbreviations are only available in command position when you _execute_ them the commandline will most likely be valid. This is enough to make transient prompts work: ```fish function reset-transient --on-event fish_postexec set -g TRANSIENT 0 end function maybe_execute if commandline --is-valid set -g TRANSIENT 1 commandline -f repaint else set -g TRANSIENT 0 end commandline -f execute end bind \r maybe_execute ``` and then in `fish_prompt` react to $TRANSIENT being set to 1.
2021-08-14 11:29:22 +02:00
commandline --input "echo foo | bar" --is-valid
and echo Valid
# CHECK: Valid
commandline --input "echo foo | " --is-valid
or echo Invalid $status
# CHECK: Invalid 2
# TODO: This seems a bit awkward?
# The empty commandline is an error, not incomplete?
commandline --input '' --is-valid
or echo Invalid $status
# CHECK: Invalid 1
commandline --input 'echo $$' --is-valid
or echo Invalid $status
Revert accidentally pushed fork Revert "README for this fork" This reverts commit 97db461e7f19c51e84fbf0dcb10fb25e0f582870. Revert "Allow foo=bar global variable assignments" This reverts commit 45a2017580ceb1ef2d79100b6cbf65d1db3c7fa5. Revert "Interpret () in command position as subshell" This reverts commit 0199583435c3b584b90769d50252d16105349671. Revert "Allow special variables $?,$$,$@,$#" This reverts commit 4a71ee12883a720408419a53482818177a834ec7. Revert "Allow $() in command position" This reverts commit 4b99fe2288da07ea1d0bc79ac0c829b65fee230a. Revert "Turn off full LTO" This reverts commit b1213f1385ad07578ca4db5f4fa7cb6371cb3be9. Revert "Back out "bind: Remove "c-" and "a-" shortcut notation"" This reverts commit f43abc42f91adf43bb2dfc65b29dd4f838ea21cf. Revert "Un-hide documentation of non-fish shell builtins" This reverts commit 485201ba2e326a0c711c003290d6f6eb2e247012.
2025-01-19 18:34:42 +01:00
# CHECK: Invalid 1
commandline: Borrow libdata later builtin_print_help will end up borrowing it as mutable. Fixes #10342
2024-03-04 16:51:57 +01:00
fixup! status again Dangit I should double-check these
2024-03-04 17:07:46 +01:00
commandline --help &>/dev/null
echo Help $status
# CHECK: Help 0
commandline: Fix setting cursor Fixes #10358
2024-03-10 09:25:48 +01:00
commandline -pC 0 --input "test | test"
echo $status
# CHECK: 0
Strip "$ " prefixes on paste Code blocks are often written like $ echo hello world hello world The "$ " is widely understood to introduce a shell command. It's often easier to copy the whole line than copying everything after "$ ". This gets more pronounced when there are multiple commands without interleaved output (either due to omission or the rule of silence). Copying the whole code block is the most natural first step. You could argue that this is a presentation issue - the dollar prefix should be rendered but not copied to clipboard. But in my experience there are many cases where there is no HTML or Javascript that would allow the copy-to-clipboard functionality to strip the prefixes. The "$ " prefix is almost never useful when pasting; strip it automatically. Privileged commands use "# " as prefix which overlaps with comments, so do not strip that until we can disambiguate (another potential reason not to do that would be safety but it's unclear if that really matters). Add the new logic to the commandline builtin, because we don't know about the AST in fish script. (Technically, the tokenizer already knows whether a "$ " is in command position and at the beginning of a line, but we don't have that either (yet).) Maybe we should move the rest of __fish_paste over as well. I'm not sure what difference that would make; for one, pasting could no longer be cancelled by ctrl-c (in theory), which seems like a good direction?
2025-02-28 03:58:51 +01:00
commandline --insert-smart '$ echo 123' --current-token
# CHECKERR: commandline: --insert-smart --current-token: options cannot be used together
# CHECKERR: {{.*}}/commandline.fish (line {{\d+}}):
# CHECKERR: commandline --insert-smart '$ echo 123' --current-token
# CHECKERR: ^
# CHECKERR: (Type 'help commandline' for related documentation)
builtin commandline: fix "-x" spuriously including redirection targets completions frequently use argparse ... -- (commandline -xpc) The "commandline -xpc" output contains only string tokens. A syntactically-valid process ("-p") consistes of only string tokens and redirection tokens. We skip all non-string tokens, but we do include redirection targets, which are always strings. This is weird, and confuses completion scripts such as the one above. Leave out redirection targets too. Part of #11084
2025-05-05 13:31:23 +02:00
commandline --input "echo {arg1,arg2} <in >out" --tokens-expanded
# CHECK: echo
# CHECK: arg1
# CHECK: arg2
commandline --input "echo <" --tokens-expanded
# CHECK: echo
commandline --input "echo >" --tokens-expanded
# CHECK: echo
commandline --input "echo > > arg" --tokens-expanded
# CHECK: echo
commandline --input "echo > {a,b}" --tokens-expanded
# CHECK: echo
commandline --input "echo {arg1,arg2} <in >out" --tokens-raw
# CHECK: echo
# CHECK: {arg1,arg2}
builtins commandline/complete: allow handling commandline before reader initialization Commands like "commandline foo" silently fail, and "complete -C" fails with a weird "option requires an argument" error. I think at least the first one can be useful in edge cases, e.g. to test code that does not separate the `commandline` input and output (#11570), and to set fish's initial commandline, see the next commit. I don't think there are super strong reasons to allow these, but if the existing state is merely due to "no one has ever thought of doing this", then we should try changing it. For consistency, also allow "complete -C". I guess an argument for that is that it's weird to make a command behave differently in non-interactive shells. For now, keep the historical behavior of disabling access to the command line in non-interactive shells. If we find a good reason for allowing that (which seems unlikely), we can. Ref: https://github.com/fish-shell/fish-shell/pull/11570#discussion_r2144544053 Co-authored-by: Johannes Altmanninger <aclopte@gmail.com>
2025-06-13 07:55:09 -07:00
$fish -ic '
commandline hello
commandline
commandline -i world
commandline
commandline --cursor 5
commandline -i " "
commandline
'
# CHECK: hello
# CHECK: helloworld
# CHECK: hello world
Reference in New Issue Copy Permalink