* Improve prompt execution time
* Change status to changes
* Remove grep/awk/sort
* Remove calls to grep/awk/sort
* Don't overwrite user defined colors
* Make look more consistent with git
This removes a weird `ls` call (that just decorates directories), and
makes it behave like normal path completion.
(really, this should be a proper option to complete)
Fixes#9285
Add completions for trash-cli commands:
trash, trash-empty, trash-list, trash-put and trash-restore.
``trash --help`` are used to identify the executable in trash cli completion.
Keeps the location of original function definition, and also stores
where it was copied. `functions` and `type` show both locations,
instead of none. It also retains the line numbers in the stack trace.
Rewrite completions for meson to expose meson commands with their
options and subcommands. New completions are based on the meson 1.0.
Subcommands were introduced in meson 0.42.0 (August 2017), so new
completions will only work for versions after 0.42.0. At this moment,
even oldstable Debian (buster) has meson 0.49.2 -- which means it is
unlikely someone will be affected.
---------
Co-authored-by: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
By default, fish does not complete files that have leading dots, unless the
wildcard itself has a leading dot. However this also affected completions;
for example `git add` would not offer `.gitlab-ci.yml` because it has a
leading dot.
Relax this for custom completions. Default file expansion still
suppresses leading dots, but now custom completions can create
leading-dot completions and they will be offered.
Fixes#3707.
When we draw the prompt, we move the cursor to the actual
position *we* think it is by issuing a carriage return (via
`move(0,0)`), and then going forward until we hit the spot.
This helps when the terminal and fish disagree on the width of the
prompt, because we are now definitely in the correct place, so we can
only overwrite a bit of the prompt (if it renders longer than we
expected) or leave space after the prompt. Both of these are benign in
comparison to staircase effects we would otherwise get.
Unfortunately, midnight commander ("mc") tries to extract the last
line of the prompt, and does so in a way that is overly naive - it
resets everything to 0 when it sees a `\r`, and doesn't account for
cursor movement. In effect it's playing a terminal, but not committing
to the bit.
Since this has been an open request in mc for quite a while, we hack
around it, by checking the $MC_SID environment variable.
If we see it, we skip the clearing. We end up most likely doing
relative movement from where we think we are, and in most cases it
should be *fine*.
This removes a possibility of an infinite loop where something in
__fish_config_interactive triggers a fish_prompt or fish_read event,
which calls __fish_on_interactive which calls
__fish_config_interactive again, ...
Fixes#9564
This wanted to get the default priority, and it ran a thing *at source
time*.
This can lead to a variety of errors and I don't believe it's all that
useful, so we remove it.
This is an additional tool, and this function is executed on source
time so we'd spew errors.
(also remove an ineffective line - it's probably *nicer* with the
read, but that's not what's currently effectively doing anything)
Separate the neovim completions from the vim ones, as their supported
options have diverged considerably.
Some documented options are not yet implemented, these are added but
commented out.
Closes#9535.
---------
Co-authored-by: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
This is an easy win for `git add ` completion time if we have multiple descriptions.
What happened was we did things once per description string, but the
things included a bunch of computation (including multiple `string`
calls and even a `realpath`!). Because these don't change, we can
simply do them once.
And it turns out we can just use a cartesian product:
for d in $desc
printf '%s\t%s\n' $file $d
end
becomes
printf '%s\n' $file\t$desc
I have no idea why `apt-cache --no-generate show` is so slow since it basically
dumps the contents of the cache file located at `/var/lib/dpkg/status`. We are
technically bypassing any waits on the cache lock file so this may produce
incorrect results if the cache is being regenerated in the moment, but that's a
small price to pay and the results are likely confined to simply not generating
comprehensive results.
With this change, we no longer need to truncate results to the first n matches
and we no longer only print packages beginning with the commandline argument
enabling fish's partial completions logic to offer less-perfect suggestions when
no better options are available.
Even though we are generating more usable completions, we still trounce the old
performance by leaps and bounds:
```
Benchmark #1: fish -c "complete -C\"apt install ac\""
Time (mean ± σ): 2.165 s ± 0.033 s [User: 267.0 ms, System: 1932.2 ms]
Range (min … max): 2.136 s … 2.256 s 10 runs
Benchmark #2: build/fish -c "complete -C\"apt install ac\""
Time (mean ± σ): 111.1 ms ± 1.8 ms [User: 38.9 ms, System: 72.9 ms]
Range (min … max): 108.2 ms … 114.9 ms 26 runs
Summary
'build/fish -c "complete -C\"apt install ac\""' ran
19.49 ± 0.44 times faster than 'fish -c "complete -C\"apt install ac\""'
```
I think this should be preferred for all subcommand completions because it
handles typos or subcommands we don't recognize better (`apt foo <TAB>` no
longer suggests subcommands since the subcommand position has been taken).
- Added phx completions. These are very common completions for the Elixir Phoenix Framework.
Documentation can be found here: https://hexdocs.pm/phoenix/1.7.0-rc.2/Mix.Tasks.Local.Phx.html#content
- Added argument completions
- Made all descriptions start with an uppercase for better consistency
- Update CHANGELOG.rst
The `cmake` meta package pulls in `cmake-core`, `cmake-docs`, and `cmake-man` -
we don't need the latter two.
(It seems to be available on all the versions/architectures we target.)
The git-lite flavor, being significantly smaller and downloading/installing much
faster with fewer dependencies, is much better suited for CI environments (at
the cost of not supporting interactive git commands).
By default /etc/pkg/FreeBSD.conf uses either the /quarterly or /latest pkg
builds, which are built against the latest minor release of FreeBSD for the
given ${ABI} string at the time they were last updated.
The nature of the shared binary packages means everyone (across all minor
versions of the same major version on the same architecture, all of which share
the same stable ABI) gets the same binary build.
There are however packages which depend on symbols exported by system-provided
libraries (rather than by other packages, which are always going to be in sync)
that *aren't* stable across minor releases, leaving packages like llvm
broken if you install the latest llvm from pkg's binary repos built against,
say, FreeBSD 13.1 while running FreeBSD 13.0.
The other option is to use the "snapshots" of the binary packages available upon
the release of each minor version, by using /release_0, /release_1, etc instead
of /quarterly or /latest, but then you're limited to the ports that were
available at that specific date and those old versions.
tl;dr just make sure we're always using the latest minor release for each major
version of FreeBSD we intend to support.
In v3 several input parameters where renamed and since v4 it requires Node.js 16.
This resolves warnings about Node.js 12 and `set-output` being deprecated and
slated for removal in the `Lock threads` workflow.
This addresses the node v12 deprecation warning in the GitHub CI, caused by the
dependency on actions/checkout@v2.
While actions/checkout@v3 introduces some new features and changes some
defaults, the subset of features that we use should not be affected by this
migration.
The "breaking change" from v2 to v3 can be seen at [0]. Since we are tracking
only v2 without a dot release specified, we are already opting into any breakage
across minor versions, so really the only change of note is the node version
upgrade.
[0]: https://github.com/actions/checkout/compare/v2.4.2...v3.0.0
This translated ctrl-k to "\v", which is a "vertical tab", and ctrl-l
to "\f" and ctrl-g to "\a".
There is no "vertical tab" or "alarm" or "\f" *key*, so these
shouldn't be translated. Just drop these and call them `\ck` and such.
(vertical tab specifically is utterly useless and I would be okay with
dropping it entirely, I have never seen it used anywhere)
That commit did way too many things, making it hard to see the 5 regressions
it introduced. Let's revert it and its stragglers. In future, we could redo
some of the changes.
Reverts changes to share/completions/git.fish from
- 3548aae55 (completions/git: Don't leak submodule subcommands, 2023-01-23)
- 905f788b3 (completions/git: Remove awkward newline symbol, 2023-01-10)
- 2da1a4ae7 (completions/git: Fix git-foo commands, 2023-01-09)
- e9bf8b9a4 (Run fish_indent on share/completions/*.fish, 2022-12-08)
- d31847b1d (Fix apparent dyslexia, 2022-11-12)
- 054d0ac0e (git completions: undo mistaken `set -f` usage, 2022-10-28)
- f5711ad5e (git.fish: collapse repeat complete cmds, set -f, rm unneeded funcs, 2022-10-27)
Bracketed paste adds one undo entry unless the pasted text contains a '
or \. This is because the "paste" bind-mode has bindings for those keys,
so they effectively start a new undo entry.
Let's fix this by adding an explicit undo group (our first use of this
feature!).
As pointed out by faho, the completions will be deduplicated by the completion
mechanics. We don't use this list directly except to pass it up the chain to the
shell, so there's no benefit to shelling out to eagerly deduplicate the list.
Plus, as of 3.6.0, even manual `complete -C"..."` invocations now deduplicate
results the same as if completions were triggered.
`fail2ban-client` uses nested subcommand syntax and intermixes fixed/enumerable
values with dynamically detected ones. If you know exactly what your overall
command structure looks like, these completions will work great. Unfortunately
their discoverability is a bit lacking, but that's not really fish's fault.
e.g.
* `f2b-c get/set` take certain known values but also accepts a dynamic jail name
* `f2b-c get/set <jail>` take certain fixed options but...
* `f2b-c get/set <jail> action` require enumerating an entirely different set
of values to generate the list of completions, bringing us to...
* `f2b-c get <jail> action <action>` has a fixed number of options but
* `f2b-c set <jail> action <action> <property>` can be any valid command and its
arguments
The intermixing of fixed, enumerable, and free-form inputs in a single command
line is enough to make one's head spin!
Similar to when we changed the color to the default mode-prompt.
I didn't notice that because my prompt uses $fish_color_error here, so
I reused the same color.
Commit 3b30d92b6 (Commit transient edit when closing pager, 2022-08-31)
inadvertently introduced two regressions to history search:
1. It made Escape keeps the selected history entry,
instead of restoring the commandline before history search.
2. It made history search commands add undo entries.
Fix both of this issues.
macOS 11+ (possibly 12+) has an additional place where certain
applications will be installed, `/System/Applications`. This is a sealed
system volume and includes the following applications:
- `App Store.app`
- `Automator.app`
- `Books.app`
- `Calculator.app`
- `Calendar.app`
- `Chess.app`
- `Clock.app`
- `Contacts.app`
- `Dictionary.app`
- `FaceTime.app`
- `FindMy.app`
- `Font Book.app`
- `Freeform.app`
- `Home.app`
- `Image Capture.app`
- `Launchpad.app`
- `Mail.app`
- `Maps.app`
- `Messages.app`
- `Mission Control.app`
- `Music.app`
- `News.app`
- `Notes.app`
- `Photo Booth.app`
- `Photos.app`
- `Podcasts.app`
- `Preview.app`
- `QuickTime Player.app`
- `Reminders.app`
- `Shortcuts.app`
- `Siri.app`
- `Stickies.app`
- `Stocks.app`
- `System Settings.app`
- `TextEdit.app`
- `Time Machine.app`
- `TV.app`
- `Utilities`
- `VoiceMemos.app`
- `Weather.app`
The change here adds `/System/Applications` to the search locations for
`-a` and `-b` options on the macOS completions for `open`. There are
possibly other locations that may be considered (I’m not using `mdls` or
`mdfind` in my functions for "reasons"), but this is partially based on
https://github.com/halostatue/fish-macos/blob/main/functions/__macos_app_find.fish
Inadvertently broken in a2d816710f,
this made `cd .` no longer offer `cd ../` (same for general file completions
like `ls .`, which only offers dotfiles)
This meant we didn't actually do our weird en/decoding scheme for e.g.
a C locale, which meant that, when you then switch to a proper locale
the previous variables were broken.
I don't know how to test this automatically - none of my attempts seem
to ever *fail* with the old code, here's what you'd do manually:
- Run fish with an actual C locale (LC_ALL=C
fish_allow_singlebyte_locale=1 fish)
- `set -gx foo 💩`
- `set -e LC_ALL`
- `echo $foo` outputs "💩" if it works and "ð⏎" if it's broken.
Fixes#2613
This means cleaning out old universal variables is now just:
```fish
abbr --erase (abbr --list)
```
which makes upgrading much easier.
Note that this erases the currently defined variable and/or any
universal. It doesn't stop at the former because that makes it *easy*
to remove the universals (no running `abbr --erase` twice), and it
doesn't care about globals because, well, they would be gone on
restart anyway.
Fixes#9468.
Since the new expanded abbreviations in 3.6.0, abbr no longer accepts
new universal variables. That means this tab is now
non-functional (except that it could technically remove abbrs that
were set in universal variables).
Because making it work with the expanded abbreviations requires some
awkwardness like a dedicated conf.d snippet (or writing into
config.fish!), we simply remove it.
Konsole draws ⏎ with a width of 2, but widechar_width says it's 1.
That leads to awkward display.
It's also a surprising and distracting symbol in this use.
So just use spaces.
Like I mentioned in #9089, 12 entries is a bit few.
So, instead, we do like we do for completions before disclosing and
pick half the screen (but at least X, in this case 12).
This avoids filling the entire screen, and will avoid an unsightly "X
more entries" (which requires scrolling down to fully disclose)
because it matches what the pager does.
Note: For multiline commands we can be pushed further upwards, and in
case of a multi-column layout we could fit more lines. That would
require asking the pager to fit as many as possible and give us back
the index of the last matching entry and rewinding the history search.
That's gonna be left as an exercise for later if it turns out to be necessary.
This keeps tripping people up. We can't mention it *everywhere*, but
lets see if it works just in "match", since that sees to be where
people hit it most.
This used the naive `__fish_seen_subcommand_from`, which isn't
powerful enough once you allow for `conda create` and `conda env
create`.
Hattip to jvanheugten for the env completions.
Fixes#9452
On macOS, fish_git_prompt was failing to correctly handle the case where
another git was installed, e.g. /usr/local/bin/git from Homebrew.
Disable the workarounds in that case.
On macOS, fish_git_prompt was failing to correctly handle the case where
another git was installed, e.g. /usr/local/bin/git from Homebrew.
Disable the workarounds in that case.
a lynx-internal hash of div.contents collided with em>a which caused
built-in styling to render much of entire pages as emphasized links.
Since switching from doxygen, we haven't had a <div class="contents">
so this workaround is no longer needed.
Our macOS workarounds involve running "xcrun" to check if Git is installed.
On a freshly upgraded Ventura system that does not have XCode or
CommandLineTools installed, "xcrun" will print this error:
xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun
on every prompt. Let's silence this error.
(cherry picked from commit a0840637fa)
Our macOS workarounds involve running "xcrun" to check if Git is installed.
On a freshly upgraded Ventura system that does not have XCode or
CommandLineTools installed, "xcrun" will print this error:
xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun
on every prompt. Let's silence this error.
These four completions all have a strange pattern (that doesn't
work.)
set -l subcommands cmd1 cmd2 cmd3 ...
complete -n "__fish_use_subcommand $subcommands" -c foo -a cmd1
complete -n "__fish_use_subcommand $subcommands" -c foo -a cmd2
complete -n "__fish_use_subcommand $subcommands" -c foo -a cmd3
Remove the redundant lists of subcommands and the unused argument
passed to __fish_use_subcommand for bosh, cf, mariner, and port.
- fix complete condition
- add short flag
the conditions are not include short flags currently.
and conditions are not right, causing the complete to not work as expected.
The `git` can already have finished here, leading to "disown: There
are no suitable jobs". This has caused a failure on Github Actions.
So we do $last_pid and silence all output, like we do in other spots
This allows linking them from elsewhere (currently fish_indent) and
also improves the formatting - the code formatting here isn't actually a good look.
macOS ships with a stub `/usr/bin/python3` which by default opens a
dialog to install the command line tools. As we run `python3` initially
at launch, this causes the dialog to appear on first run of fish, if the
command line tools are not installed.
Fix this by detecting the case of `/usr/bin/python3` on Darwin without
the command line tools installed, and do not offer that as a viable
python.
git on macOS has two hazards:
1. It comes "preinstalled" as a stub which pops a dialog to install
command line developer tools.
2. It may populate the xcrun cache when run for the first time, which
may take several seconds.
We fix these as follows, both fixes limited to Darwin:
1. If git is `/usr/bin/git` and `xcode-select --print-path` fails,
then do not run git automatically.
2. Second, if there is no file at `xcrun --show-cache-path`, we take it
as an indication that the cache is not yet populated. In this case we
run `git` in the background to populate the cache.
Credit to @floam for the idea.
Fixes#9343. Fixes#6625.
This now means `abbr --add` has two modes:
```fish
abbr --add name --function foo --regex regex
```
```fish
abbr --add name --regex regex replacement
```
This is because `--function` was seen to be confusing as a boolean flag.
Example output from a Cirrus bionic-asan-clang run:
```
fish: Unknown command: man
/tmp/cirrus-ci-build/share/functions/__fish_man_page.fish (line 30):
if man "$maincmd" &>/dev/null
^~^
in function '__fish_man_page'
�
[I] prompt 9>echo TEXT
[I] prompt 9>echo TEXThrAi
[I] prompt 9>echo TEXThrAi
TEXThrAi
```
Yes, this detected escape, waiting *300ms* and then "h" as being below
the escape timeout of 120ms.
This adds a section on completions *first* and removes all mentions of
oclint as it appears to be dead.
The Vim configuration section seems to be likely to be outdated and we
don't *really* use doxygen anymore.
Unfortunately print_hints was true *by default* - so for all builtins
that didn't pass it it would now be false instead.
This resulted in the trailer missing, which includes the line number
and context. So if you ran a script that includes `bind -M` the error
message would now just be "bind: -M: option requires an argument",
with no indication as to where.
This reverts commit 8a50d47a46.
This committed the sin of introducing a concept by giving it two
names:
> An alias, or wrapper, around ``ls`` might look like this
The term "wrapper" doesn't pull its weight here. It's simpler to just
call them aliases throughout. We do use "a simple wrapping function"
in another place, but that's to define "alias", not as a separate name.
The print_hints variable was always false, so just remove it.
This caused a cascade of other changes where the parser_t variable
becomes unused, so remove it from the call sites.
No functional change expected here.
When we insert characters that don't yet have highlighting, we use the
highlighting to the left, unless there is nothing to our left. The logic to
check if we are the leftmost character uses an overly loose comparison. Let's
make it more specific.
No functional change.
When there are multiple event handlers for a single event, we would print
the same log statement twice. Let's add the function name to make this
less confusing.
I often hit Shift-Return accidentally, which makes my terminal echo a
weird escape sequence. Traditionally, terminals interpret Shift-Return
as Return, so let's follow that behavior. Analoguous to commit 1dc526884
(Bind Shift+Space CSI u sequence to Space, 2022-04-24).
Went by the docs at https://yarnpkg.com/cli/install.
Anything not in the sidebar was removed.
(also rename "upgrade" to "up" because that's a great idea)
See #9375.
This would print
```
abbr -a -- dotdot --regex ^\\.\\.+\$ --function multicd
```
which expands "dotdot" to "--regex ^\\.\\.+\$...".
Instead, we move the name to right before the replacement, and move
the `--` before that:
```
abbr -a --regex ^\\.\\.+\$ --function -- dotdot multicd
```
It might be possible to improve that, but this at least round-trips.
Historical behavior is to stop option parsing at the first non-option argument.
Since we have added more options, it seemed impractical to keep that behavior.
However people are using options in their abbr expansions ("abbr e emacs
-nw"). To support this, we ignore options. However, we only ignore them
if they are not valid "abbr" options. Let's ignore all options in the
expansion definition, which is a small price to pay to keep most existing
configurations working.
Fixes#9410
This does not fix other cases which used to work, like
abbr x -unknown
Those are hopefully not used by anyone, so I don't think we need to maintain
support for that.
Enhances abbreviations with extra features
- global abbreviations
- trigger on regex match as alternative to literal match
- the ability to expand abbreviations with a user-defined function
- the ability to set cursor position after expansion
Also default the marker to '%'. So you may write:
abbr -a L --position anywhere --set-cursor "% | less"
or set an explicit marker:
abbr -a L --position anywhere --set-cursor=! "! | less"
This renames abbreviation triggers from `--trigger-on entry` and
`--trigger-on exec` to `--on-space` and `--on-enter`. These names are less
precise, as abbreviations trigger on any character that terminates a word
or any key binding that triggers exec, but they're also more human friendly
and that's a better tradeoff.
set-cursor enables abbreviations to specify the cursor location after
expansion, by passing in a string which is expected to be found in the
expansion. For example you may create an abbreviation like `L!`:
abbr L! --position anywhere --set-cursor ! "! | less"
and the cursor will be positioned where the "!" is after expansion, with
the "| less" appearing to its right.
This adds support for the `--function` option of abbreviations, so that the
expansion of an abbreviation may be generated dynamically via a fish
function.
Prior to this change, abbreviations were stored as fish variables, often
universal. However we intend to add additional features to abbreviations
which would be very awkward to shoe-horn into variables.
Re-implement abbreviations using a builtin, managing them internally.
Existing abbreviations stored in universal variables are still imported,
for compatibility. However new abbreviations will need to be added to a
function. A follow-up commit will add it.
Now that abbr is a built-in, remove the abbr function; but leave the
abbr.fish file so that stale files from past installs do not override
the abbr builtin.
This allows adjusting a pattern string so that it matches an entire
string, by wrapping the regex in a group like ^(?:...)$
This is a workaround for the fact that PCRE2_ENDANCHORED is unavailable
on PCRE2 prior to 2017, so we have to adjust the pattern instead.
Also introduce an overload of match() which creates its own
match_data_t.
We have had multiple crashes for relative CDPATH entries. Commit 5e274066e
(Always return absolute path in path_get_cdpath, 2019-10-17) tried to fix
all of them but it failed to do justice to its title. Let's fix this to
actually return absolute paths, always. Take care to to normalize the path
because it is used for autosuggestions. The normalization is mostly relevant
for CDPATH=. (the default) but it doesn't hurt others.
Closes#9407
It reads nicer to not have the "see also" thing right in the first
paragraph. I'm not even done reading this, why are you sending me
elsewhere?
(of course if it's a hotlink on a specific word that's different)
wopterr was a feature to allow wgetopt to emit error messages; but we do
not use this and never will. Remove its support. No functional change
expected here.
We wrongly highlight this as prefix when actually the trailing slash should
invalidate it. Turns out path normalization drops the slash, so let's
sidestep that.
Fixes#9394
The "flag" field enables an option to discover which flag it was invoked
with. However in practice none of our options use multiple flags so this
parameter was always nullptr. Remove it and fix up all the builtins to
stop passing this.
No functional change here.
I believe this should be identical to the previous code and handle the same
cases (I'm guessing going by the comment that this came from a C codebase
without `bool` types).
The problem with the previous code is that it tripped up the `clangd` analyzer
into thinking `assert()` expressions can/should be simplified via DeMorgan's to
improve readability (because it was seeing the fully expanded macro).
The tty_ownership test was sometimes failing. In this test,
`fish_test_helper` creates a child and transfers the tty to it,
"abandoning" the tty. In some cases, the child was running before the
parent; the child claims the tty. When the parent tries to transfer it to
the child, it get SIGTTIN and stops. Fix this by ignoring SIGTTIN and
SIGTTOU.
This only affects macOS and BSDs.
scp completions use "ls" to list files on the remote host. If a user aliases
them (in noninteractive shells) this will break. In general, this is the
users fault but also kind of ours because we shouldn't really use "ls" here.
Let's work around this problem by skipping functions.
Fixes#9363
Implement completion for vim tags from any place within the source tree.
To prevent freezes on a huge tags file (e.g., on one from the Linux
kernel source tree), amount of completion lines is limited to 10000.
Note that the TAGS file (EMACS-compatible tags file) is not searched
here as it would not be used by vim anyway.
The stack overflow tests are too slow without this.
This is because the tests are essentially quadratic: with 500 jobs, and
each job attempts to reap all jobs.
Inside a comment we offer plain file completions (or command completions if
the comment is in command position). However these completions are broken
because they don't consider any of the surrounding characters. For example
with a command line
echo # comment
^ cursor
we suggest file completions and insert them as
echo # comsomefile ment
Providing completions inside comments does not seem useful and it can be
misleading. Let's remove the completions; this should communicate better that
we are in a free-form comment that's not subject to fish syntax.
Closes#9320
flatpak completions gate some features behind checks like
test $flatpakversion -gt 1.2
which does a floating point comparison, which is different
from version comparison.
Most of these version checks are irrelevant anyway because they check for
a version that's not even in Debian oldstable. The only one that might be
relevant is a check for version 1.5 but that only gates some extra subcommands;
there's little harm in providing them too.
So let's just remove the version check.
Hopefully fixes#9341 (untested)
Note that flatpak upstream provides a completion file too - but it's shadowed
by ours on my system. This is a tricky issue for another day.
It is 1 whole year, for an already closed issue.
Any "engagement" that happens at that point is irrelevant to the
original issue at hand, and a new issue should be opened instead.
Increasing the grace period even further is even less likely to be helpful.
When unsetting, the scope indicates the scope that was *removed* not
set, so the warning is incorrectly triggered. If anything, the confusion
is now removed or we emit a warning that the variable is still present
in another scope (but don't do that!).
Closes#9338.
It's fine if it doesn't show up in the synopsis above, but putting it
under "Notes" is just too awkward.
It's a short option that exists, and so it should be documented.
I tried to make the synopsis a little less theoretical with
the placeholders and instead introduced the actual scope
options, long and short once, then refer to them as -Uflg from
then on.
I mentioned that list indicies are accepted / work to erase stuff.
In the list of options, we pretend like --unexport is long-only.
Especially with --unpath and --path, and what would go wrong
if one confused it with --univeral, and how rarely it's used,
I think it's better this way. I mention it as a synonym later
in the document so that it's not literally undocumented.
Changed phrasing such as:
"Causes the specified shell variable to be given a global scope"
Which can be read as we are taking a shell variable that exists
and giving it global scope, upgrading it to global (retaining
the value).
Redid the example section using the > syntax for things entered
into a prompt, with shell output following. The explanatory
Added in missing newlines at the ends of sentences.
Previously an environment variable to redefine would only be suggested if you
had not yet started typing one out. This makes it so that `env C<TAB>` will also
complete to, for example, [ `CC=`, `CXXFLAGS=`, ... ].
It also is smarter when suggesting variable names to complete: if a variable has
already been completed, it isn't suggested again. Additionally, it only suggests
names for variables that are exported, not all variables (the previous list was
insanely long and including things like all our `fish_...` variables).
I'm not sure if line continuations are covered anywhere else in the docs, but I
think the escapes section of the language page is a good place to mention them.
Update completions for the tree command. There are a lot of new options
were added since the 1.6.0 release (which apparently was used to create
current completions).
Options are also reordered to follow the "tree" help.
Introduced with 3.6.0 `fish_cursor_selection_mode` variable breaks
existing vi bindings (for example, input sequence `abc<Esc>0vd` doesn't
delete the `a` character as would be expected).
This patch fixes it by switching `fish_cursor_selection_mode` to
`inclusive` and back.
This fixes#9321
IEEE Std 1003.1-2017 Issue 6 added optional error condition
[EINVAL] for if no conversion could be performed.
Switch back to wcstoimax/wcstoumax: do not work around the old FreeBSD
8 issue.
Add a test for printf '%d %d' 1 2 3
Like the pexpect-based pager compeltions test `complete-group-order.py`, but for
the `complete` builtin. Verifies the same sort/dedup rules that apply to the
pager are also applied to the output of `complete` and asserts the sort behavior
for multiple `complete -k` calls for the same command and with the same (or with
both passing) preconditions.
This addresses a long-standing TODO where `complete -C` output isn't
deduplicated.
With this patch, the same deduplication and sort procedure that is run on actual
pager completions is also executed for `complete -C` completions (with a `-C`
payload specified).
This makes it possible to use `complete -C` to test what completions will
actually be generated by the completions pager instead of it displaying
something completely divorced from reality, improving the productivity of fish
completions developers.
Note that completions that wouldn't be shown in the pager are also omitted from
the results, e.g. `test/buildroot/` and `test/fish_expand_test/` are omitted
from the check matches in `checks/complete_directories.fish` because even if
they were generated, the pager wouldn't have shown them. This again makes
reasoning about and debugging completions much easier and more sane.
When this was introduced, we used fish_indent --ansi to format
the output of `builtin functions` for color output in `type`, etc.
We don't anymore.
Today it's not a potential showstopper if one launches a fish
session with a five year-old fish_indent in $PATH. We need not
go to lengths to try to make sure we run whatever is in the
build dir adjacent to the `fish` binary.
Adds a few options I see in my git manpage that were omitted:
-v, -h, -P, --config-env, --no-optional-locks, --list-cmds
Reword most general option descriptions
Simple way to make the apt completions spew:
function apt; end
on a system without an apt command installed. (even if it isn't
Darwin, because this uses test combiners!)
This is a thing some people do to avoid learning other package managers.
(of course our completions would probably be *wrong* still, but at least they
won't spew a `test` error)
This reverts commit 1c92d4c5db and
reintroduces support for trivially copyable `maybe_t` impls but with a
GCC version check to disable the optimization for GNU GCC compiler
versions 9 and below.
GCC 8.3.0 armhf builds seem to have a problem with the trivially
copyable `maybe_t` impl that introduces odd heisenbugs that cause the
tests to fail. GDB reveals that `maybe_t` function parameters received
in the callee differ from what was passed-in by the caller.
This behavior appears to be (but has not been confirmed as) a
platform-specific compiler bug. Under the same system (32-bit Debian 10
armhf), compiling with clang 7.0.1 does not result in any bugs and
causes all the tests to pass while compiling with GCC 10.2 under 32-bit
Debian 11 armhf also doesn't run into any problems, so just expand the
existing GCC version check that gates support for trivially copyable
`maybe_t` impls to encompass both the troublesome GCC 8 version and the
untested GCC 9 version.
This reverts commit 9d303a74e3.
This reverts commit 0305c842e6.
9d303a7 broke 32-bit armhf builds for unknown reasons, specifically in
settings where a trivial copy of `maybe_t<int>` was performed. A caller
would pass a literal int in the place of a `maybe_t<int>` parameter and
the callee would see a populated `maybe_t` but with a value of `0`
rather than the actual value that was passed in. It was too painful to
debug to a resolution under qemu.
The 'str' variable was apparently mistakenly removed by 49c5f96470.
Re-add it, and regex-escape it as well.
Allow completing on apropos <TAB> instaed of requiring an initial char.
Use __fish_apropos instead of apropos.
New regex to hopefully work on more platforms.
Explicitly use ^ instead of adding it at __fish_apropos
None of these __functions defined in completions are used or
referenced anywhere.
Found with:
function unused -a file search -d 'find unused functions'
set -f (string replace -fr '^[\s]*function ([\w_]+).*' '$1' < $file)
for cmd in $cmds
printf %d\ %s\n (grep -r ".*$cmd.*" $search < $argv | count) $cmd
end | string match '1 *'
end
for file in share/*/*.fish
unused $file share && printf "in %s\n" $file
end
Get rid of functions:
__fish_git_diff_opt,
__fish__git_append_letters_nosep,
__fish_git_sort_keys
Use `set -f` inside blocks instead of `set -l foo` before blocks.
Two of these just printed out the argument\tdescription dictionaries
without providing any utility: only used once, just do it inline.
Collapse adjacent lines that look like
complete git -n '(blah)' -l option -d 'option help'
complete git -n '(blah)' -l option -a 'arg1' -d 'description 1'
complete git -n '(blah)' -l option -a 'arg2' -d 'description 2'
complete git -n '(blah)' -l option -a 'arg2' -d 'description 3'
...
into
complete git -n '(blah)' -l option -d 'option help' -a "
arg1\t'description 1'
arg2\t'description 2'
arg3\t'description 3'
..."
This sped up the source time about 10% by running complete
less.
Fixes ommitted newline char shown after complete -n'(foo)'
Also axes the 'contains syntax errors' line before the error.
Update tests
before
> complete -n'(foo)'
complete: Condition '(foo)' contained a syntax error
complete: Command substitutions not allowed⏎
after
> complete -n'(foo)'
complete: -n '(foo)': command substitutions not allowed here
Ensure that multiple `-k` completions intermixed with one or more non-`-k`
completions are produced in the expected order with the order of all completions
in a single `-k` completion respected, non-`-k` completions correctly sorted and
interspersed, and the results of multiple `-k` completions in the
reverse-intuitive order (with chronologically later completions coming before
chronologically earlier `-k` counterparts), as per #9221.
This is a salvage of the "no functional changes" part of #9221, and cherry-picks
storing completion entries in a vector instead of a linked list. The legacy
"reverse intuitive" group ordering is kept by iterating in reverse order.
Tests pass but don't actually cover group order, which needs another test.
Makes it possible to retrieve the currently executing command line as
opposed to the currently executing command (`status current-command`).
Closes#8905.
There should be no functional changes in this commit.
The global variable `$_` set in the parser variables by `reader.cpp` and
read by the `status` builtin was deprecated in fish 2.0 but kept around
internally because there's no good way to store/share/forward parser
variables.
A new enum is added that identifies the status variable and they are
stored in a private array in the parser. There is no need for
synchronization because they are only set during job init and never
thereafter. This is currently asserted via ASSERT_IS_MAIN_THREAD() but
that assert can be dropped in the interest of making the parser possible
to clone and use from worker threads.
The old `$_` global variable is still kept for backwards compatibility,
though it will be dropped in a future release.
As the user is typing an argument, fish continually checks if the input is
the prefix of a valid file path. If yes, the input is underlined.
The same prefix-logic is used for all tokens on the command line, even for
"finished" tokens. This means we highlight any token that happens to be
a prefix of a valid file path. We actually want this to only apply to the
token that the user is currently typing.
Let's use the prefix-logic only for tokens adjacent to the cursor. This should
better match user expectations (and reduce IO traffic). I don't think this is
the perfect criteria but I don't know how else we can determine if a token is
"unfinished".
When visiting the "cd" node, we mark invalid paths as error, but don't
underline valid paths. This works fine most of the time because we later
underline paths (for any command, not just "cd").
However the latter check fails to honor CDPATH. Let's correct that, which
also allows to simplify the logic.
The next commit wants to move the "Underline every valid path" logic into the
visit() methods. The logic currently polls the cancel checker before checking
each path. If that's valid, it should probably have the same behavior inside
visit(). Since we currently can't cancel an AST-visitation, the next best
thing seems to suspend all IO operations, the rest should be very fast anyway.
I'm not sure if the motivation is strong enough; a conceivable alternative
would be to stop using the cancel checker altogether for highlighting.
When passing a value of type maybe_t<size_t>, clangd complains:
Parameter 'cursor' is passed by value and only copied once; consider
moving it to avoid unnecessary copies (fix available)
We get this warning because maybe_t<size_t> is not trivially copyable
because it has a user-defined destructor and copy-constructor. Let's remove
them if the contained type is trivially copyable, to avoid such warnings.
No functional change.
The destructor is equivalent to the compiler-generated one. The user-defined
destructor prevents maybe_t<size_t> from bearing the predicate "trivially
copyable". Let's remove it. No functional change.
This particular variant must be executed as a pexpect test since it relies on
the interactive-only `$history` to trigger the recursion. Note that recursion is
possible via other means (e.g. reading/writing a file), the usage of history
here is just one such example.
A false negative while testing locally should be a rare thing, and individual
pexpect tests already take too long in case of a non-match making for a painful
edit-test loop.
It seems to have originally been thought that the only possible way a stack
overflow could happen is via function calls, but there are other possibilities.
Issue #9302 reports how `eval` can be abused to recursively execute a string
substitution ad infinitum, triggering a stack overflow in fish.
This patch extends the stack overflow check to also check the current
`eval_level` against a new constant `FISH_MAX_EVAL_DEPTH`, currently set to a
conservative but hopefully still fair limit of 500. For future reference, with
the default stack size for the main/foreground thread of 8 MiB, we actually have
room for a stack depth around 2800, but that's only with extremely minimal state
stored in each stack frame.
I'm not entirely sure why we don't check `eval_depth` regardless of block type;
it can't be for performance reasons since it's just a simple integer comparison
- and a ridiculously easily one for the branch predictor handle, at that - but
maybe it's to try and support non-recursive nested execution blocks of greater
than `FISH_MAX_STACK_DEPTH`? But even without recursion, the stack can still
overflow so may be we should just bump the limit up some (to 500 like the new
`FISH_MAX_EVAL_DEPTH`?) and check it all the time?
Closes#9302.
A `block_t` instance is allocated for each live block type in memory when
executing a script or snippet of fish code. While many of the items in a
`block_t` class are specific to a particular type of block, the overhead of
`maybe_t<event_t>` that's unused except in the relatively extremely rare case of
an event block is more significant than the rest, given that 88 out of the 216
bytes of a `block_t` are set aside for this field that is rarely used.
This patch reorders the `block_t` members by order of decreasing alignment,
bringing down the size to 208 bytes, then changes `maybe_t<event_t>` to
`shared_ptr<event_t>` instead of allocating room for the event on the stack.
This brings down the runtime memory size of a `block_t` to 136 bytes for a 37%
reduction in size.
I would like to investigate using inheritance and virtual methods to have a
`block_t` only include the values that actually make sense for the block rather
than always allocating some sort of storage for them and then only sometimes
using it. In addition to further reducing the memory, I think this could also be
a safer and saner approach overall, as it would make it very clear when and
where we can expect each block_type_type_t-dependent member to be present and
hold a value.
This is a false positive as a result of disabling TLS support in LSAN due to an
incompatibility with newer versions of glibc.
Also remove the older workaround (because it didn't work).
These are NOT build-time defines but rather run-time environment variables! They
have never had any effect and we have effectively never used them to affect
sanitizer behavior under CI with ASAN/UBSAN/LSAN enabled.
(I caught this because the tests don't pass with either of LSAN_OPTIONS
`verbosity=1` or `log_threads=1` because they inject text into the stderr
output, ensuring they never pass littlecheck.)
For security reasons, some terminals require explicit permission from the
user to interpret OSC 52. One of them is [tmux] but that one usually runs
inside another terminal. This means we can usually write directly to the
underlying terminal, bypassing tmux and the need for user configuration.
This only works if the underlying terminal is writable to the fish user,
which may not be the case if we switched user. For this reason, keep writing
to stdout as well, which should work fine if tmux is configured correctly.
[tmux]: https://github.com/tmux/tmux/wiki/Clipboard
When running inside SSH, Control-X runs a clipboard utility on the remote
system. For pbcopy (and probably clip.exe too) this means that we write to the
remote system's clipboard. This is usually not what the user wants (although
it is consistent with fish_clipboard_paste). When X11 forwarding is used,
xclip/xsel copy to the SSH client's clipboard, which is what most users want.
When we don't have X11 forwarding, we need a different solution. Fortunately,
modern terminal emulators implement the OSC 52 escape sequence for setting
the clipboard of the terminal's system. Use it in fish_clipboard_copy.
Tested in SSH and Docker containers on foot, iTerm2, kitty, tmux and xterm
(this one requires "XTerm.vt100.allowWindowOps: true").
Should also work in GNU screen and Windows Terminal. On terminals that don't
support OSC 52 (like Gnome Terminal or Konsole), it seems to do nothing.
Since there does not seem to be a way to feature-probe OSC 52, let's just
always do both (pbcopy and friends as well as OSC 52). In future, we should
probably stop calling pbpaste and clip.exe, at least on remote systems.
I think there is also an escape sequence to request pasting the system
clipboard but that's less important and less popular, possibly due to
security concerns.
This makes the output a little easier on the eyes.
Tests appear to not need any changes to pass. I always forget whether or not
littlecheck cares about whitespace.
Two different bugs completely broke `trap -p`. First bug broke filtering of
functions with trap handlers (`functions -na` prints functions separated by a
comma, not a new line). Second bug broke showing of function definitions for
traps because a refactor renamed only some call sites but references to `$i`
renamed.
These issues were introduced in a6820cbe and appear to have been caught just in
time: no released version is affected (changes made post-3.5.1).
The Dockerfiles had bitrotted some.
Get them passing again, add libpcre2-dev where we can so we aren't
hitting more servers than necessary, and reformat the bionic files so
they can share more of the same image.
- Clean up the wording a little.
- Highlight the limitations of the "debugger" more clearly and don't mislead
people into thinking it's possible to really interactively set/remove
breakpoints except in select circumstances.
Sidenote: I can't believe we're using a markup language that doesn't support
nested inline markup. What a crying shame, rST!
It's a variable that holds all potential directories. The old name
makes it confusing to look at some of its usage sites and figure out
what is actually going on because they make no sense if $dir is only one
entry.
Don't just save known color values but any values that could have been loaded
from a .theme file.
Also, refactor the theme variable name whitelist/filter in a shared "global"
variable so we never forget to update it at any of the individual use sites.
The documentation states that running `fish_config theme save` after
`fish_config theme choose [theme_name]` will result in "saving" the
currently chosen theme, but this does not match the actual behavior of
`fish_config theme save` which expects a trailing argument specifying
the name of the theme to select/persist.
Given that the documented way has been included in a release and that it
makes more sense than calling `fish_config theme save xxx` when you are
*loading from* xxx and not *saving to* xxx, this patch revises
`fish_config.fish` to support the documented behavior.
When `fish_config theme save xxx` is used, xxx is loaded w/ its specified colors
saved to the according variables in the universal scope. But if `fish_config
theme save` is used without a theme's name specified, then the currently
specified (known) fish color variables are persisted from whatever scope they're
currently in (usually in the global scope from previewing a theme) to universal
variables of the same name.
This does *not* catch color variables unknown to fish! If a theme and a
prompt agree on some variable to hold some color but it's not a color variable
known to fish, it won't be persisted!
Closes#9088.
This makes these tools usable in a pipe.
You can run
```fish
some-long-command | fish_clipboard_copy
```
to copy some command's output to your clipboard, and
```fish
fish_clipboard_paste | some-other-command
```
To feed your clipboard to some command.
When there are multiple screens worth of output and `history` is writing to the
pager, pressing Ctrl-C at the end of a screen doesn't exit the pager (`q` is
needed for that) but previously caused fish to emit an error ("write:
Interrupted system call) until we starting silently handling SIGINT in
`fd_output_stream_t::append()`.
This patch makes `history` detect when the `append()` call returns with an error
and causes it to end early rather than repeatedly trying (and failing) to write
to the output stream.
If EINTR caused by SIGINT is encountered while writing to the
`fd_output_stream_t` output fd, mark the output stream as errored and return
false to the caller but do not visibly complain.
Addressing the outstanding TODO notwithstanding, this is needed to avoid
littering the tty with spurious errors when the user hits Ctrl-C to abort a
long-running builtin's output (w/ the primary example being `history`).
The previous check was including these as relative includes, meaning the actual
system header files weren't actually being explicitly included and the check
could spuriously fail.
CMAKE_EXTRA_INCLUDE_FILES doesn't seem to have a way to specify that the
includes should be treated as system/global includes and CHECK_TYPE_SIZE() isn't
documented as being affected by any other variables that do, so switch to
another method altogether.
This requires that `struct winsize` have a member `ws_row`, but as best as I can
tell that is always the case.
Closes#9279.
In the presence of modified files, assume `git checkout ...` is being
invoked/completed with the intention of restoring modifications. Even if not the
case, this list is likely going to be shortest if someone is about to change
branches.
Afterwards, list branches (with local branches sorted by recency), then remote
unique remotes, heads, tags, and recent commits. The order of these last four
is up for debate, and honestly if any of them generate a lot of results it makes
finding what you're actually looking for in the autocompletions a lot harder.
It may be better to merge these last contenders and sort them by individual
recency instead, but that does make the pager entries rather messy (and we would
need to add a new function to do that in order to interleave them in the desired
sort order but preserve the overall sort after the completions subshell
terminates).
It's really hard to see where -k is applied to git completions, so always group
it with -a to make it more consistent and easier to spot.
There should be no functional changes in this commit.
* Add clojure completions
* More ideomatic fish code
* Clojure completions in separate file
* Aboid use of psb using bb -e
* Return early when bb can not be found
* Remove superflous escape
* Another superflous escape
`describe-future-incompatibilities` is no longer a supported subcommand. It was
also never something very popular so we don't have to worry about older
versions.
[ci skip]
We only erase existing globals for some of the theme-related variables
but not for all the `known_colors`, causing `fish_config` to still emit
warnings for these if saving a theme choice after trying it.
Up to now, in normal locales \x was essentially the same as \X, except
that it errored if given a value > 0x7f.
That's kind of annoying and useless.
A subtle change is that `\xHH` now represents the character (if any)
encoded by the byte value "HH", so even for values <= 0x7f if that's
not the same as the ASCII value we would diverge.
I do not believe anyone has ever run fish on a system where that
distinction matters. It isn't a thing for UTF-8, it isn't a thing for
ASCII, it isn't a thing for UTF-16, it isn't a thing for any extended
ASCII scheme - ISO8859-X, it isn't a thing for SHIFT-JIS.
I am reasonably certain we are making that same assumption in other
places.
Fixes#1352
Closes#9240.
Squash of the following commits (in reverse-chronological order):
commit 03b5cab3dc40eca9d50a9df07a8a32524338a807
Author: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
Date: Sun Sep 25 15:09:04 2022 -0500
Handle differently declared posix_spawnxxx_t on macOS
On macOS, posix_spawnattr_t and posix_spawn_file_actions_t are declared as void
pointers, so we can't use maybe_t's bool operator to test if it has a value.
commit aed83b8bb308120c0f287814d108b5914593630a
Author: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
Date: Sun Sep 25 14:48:46 2022 -0500
Update maybe_t tests to reflect dynamic bool conversion
maybe_t<T> is now bool-convertible only if T _isn't_ already bool-convertible.
commit 2b5a12ca97b46f96b1c6b56a41aafcbdb0dfddd6
Author: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
Date: Sun Sep 25 14:34:03 2022 -0500
Make maybe_t a little harder to misuse
We've had a few bugs over the years stemming from accidental misuse of maybe_t
with bool-convertible types. This patch disables maybe_t's bool operator if the
type T is already bool convertible, forcing the (barely worth mentioning) need
to use maybe_t::has_value() instead.
This patch both removes maybe_t's bool conversion for bool-convertible types and
updates the existing codebase to use the explicit `has_value()` method in place
of existing implicit bool conversions.
The parent commit made the destructor of the DIR* member close it if necessary
(i.e. only if it's not null). This means that we can use the same logic in
the move constructor (where the source DIR* is null) and for move assignment
(where it might not be).
No functional change.
dir_iter_t closes its DIR* member in two places: the move assignment and
the destructor. Simplify this by closing it in the destructor of the DIR*
member which is called in both places. Use std::unique_ptr, which is shorter
than a dedicated wrapper class. Conveniently, it calls the deleter only if
the pointer is not-null. Unfortunately, std::unique_ptr requires explicit
conversion to DIR* when interacting with C APIs but it's probably still
better than a wrapper class.
This means that the noncopyable_t annotation is now implied due to the
unique_ptr member.
Additionally, we could probably remove the user-declared move constructor
and move assignment (the compiler-generated ones should be good enough). To
be safe, keep them around since they also erase the fd (though I hope we
don't rely on that behavior anywhere).
We should perhaps remove the user-declared destructor entirely but
dir_iter_t::entry_t also has one, I'm not sure why. Maybe there's a good
reason, like code size.
No functional change.
This was recently converted to a while-loop. However, we only
loop in a specific case when (by hitting "continue") so a
loop condition is not necessary.
No functional change.
We forgot to decode (i.e. turn into nice wchar_t codepoints)
"byte_literal" escape sequences. This meant that e.g.
```fish
string match ö \Xc3\Xb6
math 5 \X2b 5
```
didn't work, but `math 5 \x2b 5` did, and would print the wonderful
error:
```
math: Error: Missing operator
'5 + 5'
^
```
So, instead, we decode eagerly.
This is made much harder than it has to be by the fact that -k (where specified)
may be in any of a million different places, including as the first parameter,
as -ka, as a random standalone parameter, or tagged on to some other parameter
elsewhere; making it difficult to tell where it's actually missing!
Next job: automate cleaning up the order of arguments in this completions file.
There are many applications with "primitive" argument parsing capabalities that
cannot handle munging two short options together (`-xf` for `-x -f`) or a short
option and its required value (`-dall` for `-d all`). To prevent fish from
suggesting munged arguments/payloads, the options (both long and short, not just
long!) can be specified as `-o` or `--old-option` but none of this is
documented.
descend_unique_hierarchy is used for the cd autosuggestion: if a directory
contains exactly one subdirectory and no other entries, then propose that
as part of the cd autosuggestion.
This had a bug: if the subdirectory is a symlink to the parent, we would
chase that, going around the loop suggesting a longer path until we hit
PATH_MAX.
Fix this by using the new API which provides the inode "for free," and
track whether we've seen this inode before. This is technically too
conservative since the inode may be for a directory on a different device,
but devices are not available for free so this would incur a cost. In
practice encountering the same inode twice with different devices in a
unique hierarchy is unlikely, and should it happen the consequences are
merely cosmetic: we fail to suggest a longer path.
This introduces dir_iter_t, a new class for iterating the contents of a
directory. dir_iter_t encapsulates the logic that tries to avoid using
stat() to determine the type of a file, when possible.
I have about fifty git branches for fish and I almost always `git checkout`
between the most recent two or three - this makes the completions list more
usable. If you're using `git cherry-pick` or `git merge`, etc. you also most
likely to want to reference a recently changed branch.
The decision was made to only sort local branches and not remote ones in the PR
at #9248.
The performance of changing from one `git for-each-ref` invocation to two
separate ones (so we could sort them separately) was checked and found to be OK.
Food for future thought: consider ergonomics, caveats, and performance of
excluding the current branch's name from the list of completions (or perhaps
only from the first completion). Or maybe there's another way to have
`for-each-ref` give priority to a different branch while still sorting by
recency?
There are a million existing ways of skinning this cat, but it's a good parallel
to `__fish_seen_argument` to have, in a similar vein to
`__fish_seen_subcommand_from`.
Confirmed on NetBSD: The `ls -o` option groups. I tested `ls -gon` and
it didn't give an error.
It's quite suspect that this one option couldn't be grouped, so I'm
assuming this was a typo.
Prior to 1811a2d, the return value for negative return codes was UB and I'd
witnessed both expected cases like -256 mapping to a $status of 0 and unexpected
cases like a return value of -1 mapping to a $status of 0. As such, this doesn't
test just one fixed return value but the entire range from negative multiples of
256 all the way down (rather, up!) to -1.
While we hardcode the return values for the rest of our builtins, the `return`
builtin bubbles up whatever the user returned in their fish script, allowing
invalid return values such as negative numbers to make it into our C++ side of
things.
In creating a `proc_status_t` from the return code of a builtin, we invoke
W_EXITCODE() which is a macro that shifts left the return code by some amount,
and left-shifting a negative integer is undefined behavior.
Aside from causing us to land in UB territory, it also can cause some negative
return values to map to a "successful" exit code of 0, which was probably not
the fish script author's intention.
This patch also adds error logging to help catch any inadvertent additions of
cases where a builtin returns a negative value (should one forget that unix
return codes are always positive) and an assertion protecting against UB.
Hyphenation in our documentation is aggressive, even to the point of caus-
ing options themselves to be broken across lines. This makes the document-
ation hard to read, especially when you have an option like `string colle-
ct` which gets a weird hyphen.
Remove the hyphenation from the CSS.
This makes it so we link to the very top of the document instead of a
special anchor we manually include.
So clicking e.g. :doc:`string <cmds/string>` will link you to
cmds/string.html instead of cmds/string.html#cmd-string.
I would love to have a way to say "this document from the root of the
document path", but that doesn't appear to work, I tried
`/cmds/string`.
So we'll just have to use cmds/string in normal documents and plain
`string` from other commands.
This was always the case if HAVE_TEXT wasn't defined, but if it was then we were
coercing the result of `_C()` to a `const wchar_t *` pointer, because we were
returning the address of a constant zero-length wchar_t pointer. This reserves a
local static `wcstring` variable that we can return as the "no text" sentinel
and bubbles back the `wcstring` reference rather than decomposing it into a
pointer.
This is a prerequisite for a bigger change I'm working on.
It's gone from 136 bytes to a 128 bytes by rearranging the items in order of
decreasing alignment requirements. While this reduces the memory consumption
slightly (by around 6%) for each completion we have in-memory, that translates
to only around ~8KiB of savings for a command with 1000 possible completions,
which is nice but ultimately not that big of a deal.
The bigger benefit is that a single `complete_entry_t` might now fit in a cache
line, hopefully making the process of testing completions for matches more
cache friendly (and maybe even faster).
...for improved cross-platform support.
Following up on the work in c90ac7b. There was one more test that had mktemp in
the littlecheck "shebang" and this also removes a now-unnecessary `env` prefix.
Commit 09685c3682 tried making the apt
completions faster by doing two things:
1. Introduce a limiting "head"
2. Re-replace our "string" usage with tr
Unfortunately, in doing so it introduced a few issues:
1. The "tr" had a dangling "+" so it cut apart package
descriptions that contained a "+".
This caused e.g. "a C++ library" to generate another completion
candidate, "library".
2. In reusing "tr" it probably reintroduced #8575,
as tr is not 8-bit-clean.
3. It filtered too early, on the raw apt-cache output,
which caused it to fill up with long descriptions.
So e.g. for "texlive" it would only generate 10 completions,
where it should have matched 54 packages.
Because most of the speedup is in the "head" stopping early, we
instead go back to the old string way, but introduce a limiting "head"
after the "sed" (which will have removed everything but the package
name line and the first line of the description)
In my tests this is about ~10% slower than doing head early and using
tr, but it's more correct.
Admittedly I haven't been able to reproduce the 35s scenario that
09685 talks about, but the most likely cause of that is *apt-cache*
being slow - I don't see how string can be that much slower on another
system - and so it will most likely also be fixed by doing head here.
Future possibilities here include:
1. Using "apt-cache search --names-only", which gives a much nicer
format (but only for non-installed packages - the search strings are
apparently ANDed?)
2. Switching to `string split`, possibly using NUL and using `string
split0`?
3. Introducing a `string --null-in` switch so we can get by with one
`string`
4. (multi-threaded execution so the `string`s run in parallel)
All usages of `mktemp` must go through the (fish-only) `mktemp` test function
that abstracts over the differences across multiple platforms/flavors.
Tests can be easily run individually via `ninja -C build test_xxx` and there
isn't a good reason to randomly manually override $HOME and $XDG_CONFIG_HOME for
a test here and a test there.
If it's absolutely necessary, littlecheck.py should be extended to support a
`%temp` variable initialized to a temporary directory and that can be used
instead of calling out to the platform-provided `mktemp` via a subshell.
The impact here depends on the command and how much output it
produces.
It's possible to get up to 1.5x - `string upper` being a good example,
or a no-op `string match '*'`.
But the more the command actually needs to do, the less of an effect
this has.
This basically immediately issues a "write()" if it's to a pipe or the
terminal.
That means we can reduce syscalls and improve performance, even by
doing something like
```c++
streams.out.append(somewcstring + L"\n");
```
instead of
```c++
streams.out.append(somewcstring);
streams.out.push_back(L'\n');
```
Some benchmarks of the
```fish
for i in (string repeat -n 2000 \n)
$thing
end
```
variety:
1. `set` (printing variables) sped up 1.75x
2. `builtin -n` 1.60x
3. `jobs` 1.25x (with 3 jobs)
4. `functions` 1.20x
5. `math 1 + 1` 1.1x
6. `pwd` 1.1x
Piping yields similar results, there is no real difference when
outputting to a command substitution.
This writes the output once per argument instead of once per format or
escaped char.
An egregious case:
```fish
printf (string repeat -n 200 \\x7f)%s\n (string repeat -n 2000 aaa\n)
```
Has been sped up by ~20x by reducing write() calls from 40000 to 200.
Even a simple
```fish
printf %s\n (string repeat -n 2000 aaa\n)
```
should now be ~1.2x faster by issuing 2000 instead of 4000 write
calls (the `\n` was written separately!).
This at least halves the number of "write()" calls we do if it goes to
a pipe or the terminal, or reduces them by 75% if there is a
description.
This makes
```fish
complete -c foo -xa "(seq 50000)"
complete -C"foo "
```
faster by 1.33x.
`apt-cache` is just so incredibly slow that filtering against the final results
just doesn't cut it. Attempting to match against 'ac.*' (already taking
advantage of changing short search terms into prefix-only matches) would take
35 seconds, all of bottlenecked before the filtering step. This change uses more
of a heuristic to filter `apt-cache` results directly (before additional
filtering) to speed things up.
A variety of different limits from 100 to 5000 were timed and their result sets
compared to see what ended up artificially limiting valid completions vs what
took too long to be considered functional/usable and this is where we ended up.
This uses wreaddir_resolving, which tries to use the dirent d_type
field if it exists. In that way, it can skip the `stat` to determine
if the given file is a directory.
This allows `cd` completions to skip stat in most cases:
```fish
strace -Ce newfstatat fish --no-config -c 'complete -C"cd /tmp/completion_test/"' >/dev/null
```
prints before:
```
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100,00 0,002627 2 1033 4 newfstatat
```
after:
```
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100,00 0,000054 1 31 3 newfstatat
```
for a directory with 1000 subdirectories.
(just `fish --no-config -c exit` does 26 newfstatat)
This should improve the situation with slow filesystems like fuse or
network fsen.
In case we have no d_type, we use `stat`, which would yield about the
same results.
The worst case is that we need directories *and* descriptions or the
"executable" flag (which we don't currently check for cd, if I read
this right?).
For unknown reasons, the i686 launchpad builders fail on this date,
but apparently not the others.
Let's just remove it, we've tested dates older than the epoch, this is
slightly redundant.
This adds preprocessor defines for _LARGEFILE_SOURCE and
_FILE_OFFSET_BITS=64 and a few others, fixing a bug that was reported on
gitter. This prevents issues when running fish on 32 bit systems that
have filesystems with 64 bit inodes.
As discussed in #9221, a bug in the autocomplete that was fixed in 66391922
caused completions to be incorrectly suppressed. The dropped test/check was
inadvertently relying on the buggy behavior and expected a git invocation to
generate no completions but there are, in fact, completions now that the bug has
been resolved.
cc @faho: I'm not sure if you want to replace this with a different check that
actually doesn't yield any completions or if you're happy with it just being
dropped.
This flag determines whether or not more shortopt switches will be offered up as
potential completions (vs only the payload for the last-parsed shortopt switch).
Previously, it was being stomped before it was determined whether or not two
`complete` rules with different `result_mode.requires_param` values were
actually resolved against the current command line or not, and the last
evaluated completion rule would win out.
There are two changes here:
* `last_option_requires_param` is only assigned if all associated conditions for
a potential completion are also met, and
* If already assigned by a conflicting rule (which can only be user/developer
error), `last_option_requires_param` is allowed to change from true to false
but not the other way around (i.e. in case of a conflict, generate both
payloads and other shortopt completions)
The first change is immediately noticeable and affects many of our own
completions, see the discussion in #9221 for an example regarding `git` where
`-c` has any of about a million different possible meanings depending on which
completion preconditions have been met. The second change should only happen if
a dev/user mistakenly enters a `complete -c ...` rule for the same shortopt more
than once, both with conditions matching, sometimes requiring an argument and
not sometimes not. It should be a rare occurence.
g++ 4.8 emits a bogus warning on code like foo{}. Add a compiler flag
-Wno-missing-field-initializers if that warning is detected, because it
is annoying.
This reverts commit 3d8f98c395.
In addition to the issues mentioned on the GitHub page for this commit,
it also broke the CentOS 7 build.
Note one can locally test the CentOS 7 build via:
./docker/docker_run_tests.sh ./docker/centos7.Dockerfile
This fails on old Ubuntu with:
> touch: invalid date format ‘190112112040.39’
Because we don't actually need the seconds here, we just use minute
resolution. It's fine.
Also use `path mtime`, because that's a portable way to get the mtime.
Be more careful with sign extension issues stemming from the differences in how
an untyped literal is promoted to an integer vs how a typed (and signed) `char`
is promoted to an integer.
Also convert some `const[expr] static xxx` to `const[expr] xxx` where it makes
sense to let the compiler deduce on its own whether or not to allocate storage
for a constant variable rather than imposing our view that it should have STATIC
storage set aside for it.
A few call sites were not making use of the `XXX_LEN` definitions and were
calling `strlen(XXX)` - these have been updated to use `const_strlen(XXX)`
instead.
I'm not sure if any toolchains will have raise any issues with these changes...
CI will tell!
The optimization takes references to strings which are stored in a vector,
and stores those references in a set; but the strings are simultaneously
being moved within the vector, which may invalidate those references.
It's probably safe if you work through which particular strings are being
moved, but as a matter of principle we shouldn't take references to elements
of a vector while the vector is being rearranged, absenet a clear improvement
on a benchmark.
This reverts commit d5561623aa.
I forgot `stat` is non-portable. There's no great way to portably get a
machine-readable representation of stat(2) for a file. I don't want to ship our
own lstat(2) wrapper executable just for this test and don't want to fork out to
python or perl for this either - I just wanted to get the tests to pass under
WSL :'(
Anyway, just give up and make it skip just for WSL. If another OS fails this
test in the future, the comments and existing workaround will make it easy to
figure out what the problem is and what needs to be done. We'll cross that
bridge when we get there.
Whenever the command line changes, we redraw it with the previously computed
syntax highlighting. At the same time we start recomputing highlighting in
a background thread.
On some systems, the highlighting computation is slow, so the stale syntax
highlighting is visible.
The stale highlighting was computed for an old commandline. When the user
had inserted or deleted some characters in the middle, then the highlighting
is wrong for the characters to the right. This is because the characters
to the right have shifted but the highlighting hasn't. Fix this by also
shifting highlighting.
This means that text that was alrady highlighted will use the same
highlighting until a new one is computed. Newly inserted text uses the color
left of the cursor.
This is implemented by giving editable_line_t ownership of the highlighting.
It is able to perfectly sync text and highlighting; they will invariably
have the same length.
Fixes#9180
While its true that we only ever call this with temporaries, there is no
fundamental reason for this restriction. Taking by value is simpler and
more flexible. I think it does not change the generated code.
No functional change.
The idea for this function was that it stands as the one place that modifies
the text without push_edit. In practice I don't think it helps.
No functional change.
In theory this does less work so we should generally use this style.
In practice it looks uglier so I'm not sure. Maybe wait for stdlib ranges...
No functional change.
It turns out that not all systems print an unsigned integer as the output of
`stat -c %Y xxx` and the leading `-` can be misinterpreted as a parameter to
`string match`.
It turns out there *is* an obviously portable way... except it's
not-so-obviously not portable after all.
POSIX specifies that sigqueue(2) can be used to validate pid and signo
separately, returning EINVAL in the specific case of an invalid or unsupported
signal number. This would be perfect... if only it were actually implemented.
It seems that the WSLv1 implementation of pselect(2) does not check for
undelivered signals after the temporary sigmask is un-applied from the thread in
question.
`gh` doesn't write its errors to stderr and doesn't exit with a non-zero status
code in case of failure. The completions are short enough that buffering them
isn't a huge deal.
There's no guarantee (nor requirement) that the filesystem support pre-epoch
modification dates. If it doesn't, the `test` tests were failing to get the
expected results.
Skip the test if it seems the fs doesn't support pre-epoch timestamps
(determined by pre-epoch mt of `oldest` evaluating to 0 or the unix epoch).
This cuts down `__fish_git_using_command` calls from 75 to 68, saving
some time in the common case.
(it would be possible to remove the check from
`__fish_git_stash_using_command` now, but that's brittle and it's one
call, so it's not a big issue)
* Replace ";" with "\n" in alias-generated functions
This can let us add a "#" in our aliases to make
them ignore additional arguments.
* Update changelog about aliases that ignore arguments
* Update test for alias.fish
This is now compliant with the aliases that can
ignore arguments.
This used a prompt command, but since the prompt was interpolated and
included a `?` it would be run as a glob without qmark-noglob.
Since it's simpler to pass a prompt string, just do that.
When fish runs with job control enabled, it transfers ownership of the
tty to a child process, and then reclaims the tty after the process
exits. If job control is disabled then fish does not transfer or reclaim
the tty.
It may happen that the child process creates a pgroup and then transfers
the tty to it. In that case fish will not attempt to reclaim the tty, as
fish did not transfer it. Then when fish reads from stdin it will
receive SIGTTIN instead of data.
Fix this by unconditionally claiming the tty in readline().
Fixes#9181
This errored out *later* because the result was infinite or NaN, but
it didn't actually stop evaluation.
I'm not sure if there is a way to get floating point math to turn an
infinity back into something that doesn't depend on a literal
infinity, but division by zero conceptually isn't a thing we can
support.
There's entire branches of maths dedicated to figuring out what
dividing by "basically zero" means and we don't have to get into it.
This checked the locale, but did so in a way that's fundamentally
broken:
1. $LANG isn't the only variable ($LC_ALL and $LC_CTYPE)
2. Even if $LANG is set that doesn't mean it's actually working
We could add a `status is-multibyte` here to figure out if we have a
multibyte locale?
But instead, since this is dealing with adding an ellipsis, let's just
add it to `string ellipsize`.
One slight difference is that shortening the branch now counts the ellipsis width.
I.e. assuming the branch is "long-branch-name"
```fish
set -g __fish_git_prompt_shorten_branch_len 8
```
might now print "long-br…" instead of "long-bra…". This is nicer because we can now give the actual maximum width.
The alternative is to add a "--exclusive" option to "string ellipsize" that doesn't count the ellipsis width. So `string ellipsize --char "..." --max 8" long-branch-name` might result in "long-bra...", which is 11 wide.
This is essentially the inverse of `string pad`.
Where that adds characters to get up to the specified width,
this adds an ellipsis to a string if it goes over a specific maximum width.
The char can be given, but defaults to our ellipsis string.
("…" if the locale can handle it and "..." otherwise)
If the ellipsis string is empty, it just truncates.
For arguments given via argv, it goes line-by-line,
because otherwise length makes no sense.
If "--no-newline" is given, it adds an ellipsis instead and removes all subsequent lines.
Like pad and `length --visible`, it goes by visible width,
skipping recognized escape sequences, as those have no influence on width.
The default target width is the shortest of the given widths that is non-zero.
If the ellipsis is already wider than the target width,
we truncate instead. This is safer overall, so we don't e.g. move into a new line.
This is especially important given our default ellipsis might be width 3.
pipenv switched from older click-completion package to new built-in completions
from click framework in v2021.11.9.
This command achieves compatibility with both, older and more recent versions.
`cargo search` can be used to quickly get crates matching a search string, so we
can pass the current token for first-arg completions to `cargo add` and `cargo
install` to `cargo search` to look up matches.
`cargo search` doesn't restrict itself to (nor prioritize for) prefix matches,
while fish will only display prefix matches (for dynamically generated
completions) so it's perfectly possible for `cargo search foo` to return 20
results none of which will successfully result in a completion, but for a
further-narrowed completion of `cargo install foob^I" to then result in
completions because `cargo search` ended up returning a prefix match for `foob`
while it didn't for `foo`.
The only other oob cargo subcommand that takes a crate name (that isn't the name
of a crate specified in `Cargo.toml`) is `cargo search` but there's no point in
providing completions to that... I think (it's possible to search for crate
"foo" in order to get its latest version number rather than its name, but I'm
not sure that's worth supporting).
This expands completions of `cargo^I` to list any commands named `cargo-xxx` as
cargo subcommands invokable as `cargo xxx` in addition to the default oob
subcommands cargo ships with.
(This is very similar to how git allows users to shim their own subcommands.)
NOTE: This would stay even after cargo someday moves to clap and generates or
even ships/installs an official machine-generated `cargo.fish` completions
script.
The old way of generating cargo completions no longer work, so we need
to manually maintain the completions until clap completions support[1].
[1]: https://github.com/clap-rs/clap/issues/3166
When selecting items in the pager, only the latest of those items is kept
in the edit history, as so-called transient edit. Each new transient edit
evicts any old transient edit (via undo).
If the pager is closed by a command that performs another transient edit
(like history-token-search-backward) we thus inadvertently undo (= remove)
the token inserted by the pager. Fix this by closing a transient edit
session when closing the pager. Token search will start its own session.
Fixes#9160
strncpy will fill the entire buffer with NUL.
In this case we have a 128 byte buffer and write "empty" - 5 bytes -
into it.
So now instead of writing 6 bytes it'll write 128 bytes. Especially
wasteful because we already did memset before
This fixes a crash when you open the history pager and then do
history-token-search-backward (e.g. alt+. or alt-up).
It would sometimes crash because the `colors.at(i)` was an
out-of-bounds access.
Note: This might still leave the highlighting offset in some
cases (not quite sure why), but at least it doesn't *crash*, and the
search generally *works*.
This used `realpath -eq`, which for GNU realpath:
1. Suppresses "most error messages" (-q)
2. Requires that all parts exist (rather than allowing the last not
to)
Since we don't actually need a real path here, just filter.
Fixes#9099
* added completions for sad and added note in changelog
* ran fish_indent on completion file
* split -h and --help into two distinct completion options
This was written while we changed how our synopses are formatted, so
we missed adding a "synopsis" marker to it.
The tokenizer here is a bit cheesy, so we can't mark continuation
lines with a "\", and we also can't mark the general options with a
":=". Tbh that's not a big deal.
Fixes#9154
This starts two sleep processes and expects them to be killed on
SIGHUP.
Unfortunately, if this ever fails the second run will also fail
because it'll see the old sleep still lying around (because it'll run
for 130 seconds).
So, what we do is:
1. Keep the pids for these specific sleeps
2. Check if any of them are still running (and only fail for them)
3. Kill them from python
Fixes#9152
This reverts commit 3e556b984c.
Revert "Further fix the issue and add the assert that'd have prevented it."
This reverts commit 056502001e.
Revert "Fix actual issue with allow_use_posix_spawn."
This reverts commit 85b9f3c71f.
Revert "Stop using posix_spawn when it is not allowed"
This reverts commit 9c896e1990.
Revert "don't even set up a fish_use_posix_spawn handler if unsupported"
This reverts commit 8b14ac4a9c.
Commit 8b14ac4a9c started using
posix_spawn even if allow_use_posix_spawn() returns false. Stop doing
that.
This may be reproduced with:
./docker/docker_run_tests.sh ./docker/centos7.Dockerfile
as centos7 has a too-old glibc.
Let's hope this doesn't causes build failures for e.g. musl: I just
know it's good on macOS and our Linux CI.
It's been a long time.
One fix this brings, is I discovered we #include assert.h or cassert
in a lot of places. If those ever happen to be in a file that doesn't
include common.h, or we are before common.h gets included, we're
unawaringly working with the system 'assert' macro again, which
may get disabled for debug builds or at least has different
behavior on crash. We undef 'assert' and redefine it in common.h.
Those were all eliminated, except in one catch-22 spot for
maybe.h: it can't include common.h. A fix might be to
make a fish_assert.h that *usually* common.h exports.
Fixed a line or two tripped IWYU asserts about visibility
when doing e.g. a private -> public mapping but the visibility
it came up with was identical. Like the <iosfwd> to <string>
mapping, it was defined as private -> public but they're both
"public".
Added a whole bunch of lines necessary to get sane/correct
reccomendations from current IWYU on clang 10 on macOS Ventura.
Incrementally I manually added these as needed while going through
each line change IWYU wanted in each file.
This is a *tiny* commit code-wise, but the explanation is a bit
longer.
When I made string read in chunks, I picked a chunk size from bash's
read, under the assumption that they had picked a good one.
It turns out, on the (linux) systems I've tested, that's simply not
true.
My tests show that a bigger chunk size of up to 4096 is better *across
the board*:
- It's better with very large inputs
- It's equal-to-slightly-better with small inputs
- It's equal-to-slightly-better even if we quit early
My test setup:
0. Create various fish builds with various sizes for
STRING_CHUNK_SIZE, name them "fish-$CHUNKSIZE".
1. Download the npm package names from
https://github.com/nice-registry/all-the-package-names/blob/master/names.json (I
used commit 87451ea77562a0b1b32550124e3ab4a657bf166c, so it's 46.8MB)
2. Extract the names so we get a line-based version:
```fish
jq '.[]' names.json | string trim -c '"' >/tmp/all
```
3. Create various sizes of random extracts:
```fish
for f in 10000 1000 500 50
shuf /tmp/all | head -n $f > /tmp/$f
end
```
(the idea here is to defeat any form of pattern in the input).
4. Run benchmarks:
hyperfine -w 3 ./fish-{128,512,1024,2048,4096}"
-c 'for i in (seq 1000)
string match -re foot < $f
end; true'"
(reduce the seq size for the larger files so you don't have to wait
for hours - the idea here is to have some time running string and not
just fish startup time)
This shows results pretty much like
```
Summary
'./fish-2048 -c 'for i in (seq 1000)
string match -re foot < /tmp/500
end; true'' ran
1.01 ± 0.02 times faster than './fish-4096 -c 'for i in (seq 1000)
string match -re foot < /tmp/500
end; true''
1.02 ± 0.03 times faster than './fish-1024 -c 'for i in (seq 1000)
string match -re foot < /tmp/500
end; true''
1.08 ± 0.03 times faster than './fish-512 -c 'for i in (seq 1000)
string match -re foot < /tmp/500
end; true''
1.47 ± 0.07 times faster than './fish-128 -c 'for i in (seq 1000)
string match -re foot < /tmp/500
end; true''
```
So we see that up to 1024 there's a difference, and after that the
returns are marginal. So we stick with 1024 because of the memory
trade-off.
----
Fun extra:
Comparisons with `grep` (GNU grep 3.7) are *weird*. Because you both
get
```
'./fish-4096 -c 'for i in (seq 100); string match -re foot < /tmp/500; end; true'' ran
11.65 ± 0.23 times faster than 'fish -c 'for i in (seq 100); command grep foot /tmp/500; end''
```
and
```
'fish -c 'for i in (seq 2); command grep foot /tmp/all; end'' ran
66.34 ± 3.00 times faster than './fish-4096 -c 'for i in (seq 2);
string match -re foot < /tmp/all; end; true''
100.05 ± 4.31 times faster than './fish-128 -c 'for i in (seq 2);
string match -re foot < /tmp/all; end; true''
```
Basically, if you *can* give grep a lot of work at once (~40MB in this
case), it'll churn through it like butter. But if you have to call it
a lot, string beats it by virtue of cheating.
clang-format (since 10) can output diagnostics which indicate
lines needing formatting with --dry-run and -Werror: the exit
code indicates if a file is correctly formatted or not.
We used to copy each .cpp file, run clang_format on the duplicate
and then `cmp` to see if there were changes made, before just
printing a line with the filename and moving the new ontop of
the original.
Now we show clang-format diagnostics which indicate which
lines will be changed, prompt for confirmation and then let
clang-format modify the files in-place without the juggling.
Looks like this: https://user-images.githubusercontent.com/291142/184561633-c16754c8-179e-426b-ba15-345ba65b9cf9.png
Rephrase this to more explicitly indicate that the uvar actually
was successfully set. I believe the prior phrasing can leave some
ambiguity as far as wether set just failed with an error, whether it
has done anything or not.
Now uses the same macro other builtins use for a missing -e arg,
and the error message show the short or long option as it was used.
e.g. before
$ set -e
set: Erase needs a variable name
after
$ set --erase
set: --erase: option requires an argument
$ set -e
set: -e: option requires an argument
This moves the stuff that creates skeleton/boilerplate files to
the same place we initialize uvars for the first time or on upgrade.
Being a bit less aggresssive here theoretically makes launch a little
lighter but really I personally just found it weird I couldn't
just delete my empty config.fish file without it getting recreated
and sourced every launch.
A recenty commit was loathe to assume the unicode ellipsis character
was safe so just used '..' instead. However I noticed we actually
already do use that character elsehwere in the completions.
So, just make both spots try to somewhat carefully use it.
We do this same `string match` check on LANG in fish_job_summary.fish
Intern'd strings were intended to be "shared" to reduce memory usage but
this optimization doesn't carry its weight. Remove it. No functional
change expected.
We store filenames in function definitions to indicate where the
function comes from. Previously these were intern'd strings. Switch them
to a shared_ptr<wcstring>, intending to remove intern'd strings.
The history pager will show multiline commands in single-line cells.
We escape newline characters as \\n but that looks awkward if the next line
starts with a letter. Let's render control characters using their corresponding
symbol from the Control Pictures Unicode block.
This means there is also no need to escape backslashes, which further improves
the history pager - now the rendering has exactly as many backslashes as
the eventual command.
This means that (multiline) commands in the history pager will be rendered
with the same amount of characters as are in the actual command (unless
they contain funny nonprintables). This makes it easy for the next commit
to highlight multiline commands correctly in the history pager.
The font size for these symbols (for example ␉) is quite small, but that's
okay since for the proposed uses it's not so important that they readable.
The important thing is that the stand out from surrounding text.
When adding a VLAN-enabled interface, it is named like enp0s31f6.100@enp0s31f6
with the physical interface being appended behind an @.
But subsequent ip commands operate on the interface name without this suffix,
so it needs to be removed when completing interface names in __fish_ip_device
This checked specifically for "| and" and "a=b" and then just gave the
error without a caret at all.
E.g. for a /tmp/broken.fish that contains
```fish
echo foo
echo foo | and cat
```
This would print:
```
/tmp/broken.fish (line 3): The 'and' command can not be used in a pipeline
warning: Error while reading file /tmp/broken.fish
```
without any indication other than the line number as to the location
of the error.
Now we do
```
/tmp/broken.fish (line 3): The 'and' command can not be used in a pipeline
echo foo | and cat
^~^
warning: Error while reading file /tmp/broken.fish
```
Another nice one:
```
fish --no-config -c 'echo notprinted; echo foo; a=b'
```
failed to give the error message!
(Note: Is it really a "warning" if we failed to read the one file we
wer told to?)
We should check if we should either centralize these error messages
completely, or always pass them and remove this "code" system, because
it's only used in some cases.
This skipped printing a "^" line if the start or length of the error
was longer than the source.
That seems like the correc thing at first glance, however it means
that the caret line isn't skipped *if the file goes on*.
So, for example
```fish
echo "$abc["
```
by itself, in a file or via `fish -c`, would not print an error, but
```fish
echo "$abc["
true
```
would. That's not a great way to print errors.
So instead we just.. imagine the start was at most at the end.
The underlying issue why `echo "$abc["` causes this is that `wcstol`
didn't move the end pointer for the index value (because there is no
number there). I'd fix this, but apparently some of
our recursive variable calls absolutely rely on this position value.
This makes the awkward case
fish: Unexpected end of string, square brackets do not match
echo f[oo # not valid, no matching ]
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
(that `]` is simply the last character on the line, it's firmly in a comment)
less awkward by only marking the starting brace.
The implementation here is awkward mostly because the tok_t
communicates two things: The error location and how to carry on.
So we need to store the error length separately, and this is the first
time we've done so.
It's possible we can make this simpler.
This makes it so instead of marking the error location with a simple
`^`, we mark it with a caret, then a run of `~`, and then an ending `^`.
This makes it easier to see where exactly an error occured, e.g. which
command substitution was meant.
Note: Because this uses error locations that haven't been exposed like
that, it's likely to shake out weirdnesses and inaccuracies. For that
reason I've not adjusted the tests yet.
This stops us from loading the completions for e.g. `./foo` if there
is no `foo` in path.
This is because the completion scripts will call an unqualified `foo`,
and then error out.
This of course means if the script would work because it never calls
the command, we still don't load it.
Pathed completions via `complete --path` should be unaffected because
they aren't autoloaded anyway.
Workaround for #3117Fixes#9133
These should be friendlier, but aren't as pedantically accurate.
I think the term "index" is terrible and much prefer "staging area".
Also "rev-parse" simply must be believed to be seen, it can't be
described in a single paragraph. (did you know you can use `git
rev-parse --parseopt` as a replacement for `getopt` in arbitrary
shell scripts?)
This was misguidedly "fixed" in
9e08609f85, which made printf error out
with any "-"-prefixed words as the first argument.
Note: This means currently `printf --help` doesn't print the help.
This also matches `echo`, and we currently don't have anything to make
a literal `--help` execute a builtin help except for keywords. Oh well.
Fixes#9132
"socket.has_ipv6" is basically useless - it tells you python has
been *compiled* with ipv6 support.
Instead just try ipv6 and if that fails with EAFNOSUPPORT (checking
the actual errno), try v4.
Yes, I explicitly do not care to test this on python2.
Fixes#3857
I have an alias called "lg" for
log --color --graph --pretty=format:\'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset\' --abbrev-commit --first-parent
Having that in my completions ensures that git commands essentially
always use one column at most. That's not great, so we now shorten it
to 35 chars (plus an annoying 2 for ".." because I can't be bothered
to check for unicode support - an argument for a "string ellipsize", I guess?)
* Disclose pager to screen height immediately
This removes that bit where we only show 4 rows at most at first,
instead we disclose between half of terminal height up to the full terminal height (but still at least 4 rows).
This results in less pressing of tab to get the other results, and
better visibility of results.
Unlike moving it to the actual top of the screen, it's not as jarring and doesn't push terminal history off-screen as much.
Fixes#2698
This used to be kept, so e.g. testing it with
fish_read_limit=5 echo (string repeat -n 10 a)
would cause the prompt and such to error as well.
Also there was no good way to get back to the default value
afterwards.
* string repeat: Don't allocate repeated string all at once
This used to allocate one string and fill it with the necessary
repetitions, which could be a very very large string.
Now, it instead uses one buffer and fills it to a chunk size,
and then writes that.
This fixes:
1. We no longer crash with too large max/count values. Before they
caused a bad_alloc because we tried to fill all RAM.
2. We no longer fill all RAM if given a big-but-not-too-big value. You
could've caused fish to eat *most* of your RAM here.
3. It can start writing almost immediately, instead of waiting
potentially minutes to start.
Performance is about the same to slightly faster overall.
This newline apparently dates back to when we required all statements to
be terminated; but our AST no longer requires that so we can remove
this. No functional change expected here.
GIT_WORK_TREE is an environment variable which tells git where the
worktree is. It may be set by the user or by git itself, e.g. when
running `git rebase -i --exec ...`. If it is set, it overrides the
working directory, causing the `git checkout` from FetchContent_Populate
to fail. Clear this variable.
Do the same for GIT_DIR for the same reason.
A way to reproduce the failure that this commit fixes is:
git rebase -i HEAD^^^ --exec 'ninja -C /path/to/build/dir fish'
prior to this commit, using the fetched PCRE2, this would fail in CMake.
The previous fix was reverted because it broke another scenario. Add tests
for both scenarios.
The first test exposes another problem: autosuggestions are sometimes not
recomputed after selecting the first completion with Tab Tab. Fix that too.
"git add ./" shows only hidden files (if at all). It should show all files
that can be added.
The problem is that candidates come from "git status" which prints clean
relative paths. Let's allow some unclean paths.
This is far from a complete fix but it should work for the common scenario.
Observe that wildcard_complete_internal() actually filters out all non-hidden
files, if the query is `./`.
Closes#9091
This makes it easy to see where the individual commands start. Perhaps we
can get rid of this once we have syntax highlighting for the commands in
the history pager, or if we add timestamps as descriptions.
Note that every change to the search field still starts a new search, from
the end of history. We could change this in future but it's unclear to me
what the expected behavior is. I don't find the traditional readline behavior
very intuitive.
This reimplements ridiculousfish/control_r which is a more future-proof
approach than #6686.
Pressing Control+R shows history in our pager and allows to search filter
commands with the pager search field.
On the surface, this works just like in other shells; though there are
some differences.
- Our pager shows multiple results at a time.
- Other shells allow to use up arrow/down arrow to select adjacent entries
in history. Shouldn't be hard to implement but the hidden state might
confuse users and it doesn't play well with up-or-search, so this is
left out.
Users might expect the history pager to use subsequence matching (fuzzy
matching) like the completion pager, however due to the history pager design it
uses substring matching. We could change this in future, however that means
we would also want to change the ordering from "reverse-chronological" to
"longest common subsequence" (e.g. what fuzzy finders do), because otherwise
a query "fis" might give this ordering:
fsck /dev/disk/by-partlabel/Linux\x20filesystem
fish
which is probably not what the user wants.
The pager shows only a small number of history items at a time. This is
because, as explained above, the history pager does not support subsequence
matching, so navigating it does not scale well.
Closes#602
The next patch wants to add state that should be reset when we clear the
pager, which will happen in this function.
This reverts commit b25b291d38.
No functional change.
The pager's rendering_needs_update() function detects some but not all
scenarios where a rendering is stale. In particular, it does not compare
the completion strings.
To make this work, we manually invalidate the pager rendering whenever we
update completion strings. The history pager needs the same functionality,
so let's move it into the pager.
No functional change.
This addresses code review feedback to not couple the purely visual
concept of cursor style with the logical concept of the selection size.
Instead this now uses a dedicated variable
`$fish_select_char_after_cursor` to determine whether to extend the
selection beyond the cursor:
* fish_select_char_after_cursor = 1 or unset -> extend selection
* all other cases -> place the selection end that the cursor
This fixes the handling of the right end of the selection. Currently the
right end is considered to be at the cursor position + 1. When using a
`block` or `underline` cursor this is arguably correct, because the
cursor has a width of 1 and spans from the current position to the next:
```
x x [x x x̲] x
```
This is incorrect though (or at least very unintuitive), when using a
`line` cursor:
```
x x [x x|x] x
```
This commit changes the strategy for determining the end of the
selection in the following way:
* If the current cursor as determined by `$fish_cursor_<bind_mode>` is
set to `line`, then a cursor width of `0` is assumed.
* In all other cases, including `block` and `underscore` as well as when
no value is set we retain the previous behavior of assuming a cursor
width of `1`.
```
x x [x x x̲] x
x x [x x|]x x
```
This change should not affect many users, because the selection is
probably used most by vi-mode users, who are also likely to use a
block cursor.
We use "c > 0" but we actually mean "c != 0". The former looks like the
other code path handles negative c. Yet if c is negative, our code would
print a single escaped byte (\xXY) which is wrong because a negative value
has "sizeof wchar_t" bytes which is at least 2.
I think on platforms with 16-bit wchar_t it's possible that we actually
get a negative value but I haven't checked.
Since the fix for #3892, this escaping style escapes
\n to \\n
as well as
\\ to \\\\
\' to \\'
I believe these two are the only printable characters that are escaped with
ESCAPE_NO_PRINTABLES.
The rationale is probably to keep the encoding unambiguous and reversible.
However that doesn't justify escaping the single quote. Probably this was
an accident, so let's revert that part.
This has the nice effect that single quotes will no longer be escaped
when rendered in the completion pager (which is consistent with other
special characters). Try it:
complete : -a "aaa\'\; aaaa\'\;" -f
Also this makes the error output of builtin bind consistent:
$ bind -e --preset \;
$ bind -e --preset \'
$ bind \;
bind: No binding found for sequence “;”
$ bind \'
bind: No binding found for sequence “'”
the last line is clearly better than the old version:
bind: No binding found for sequence “\'”
In general, the fact that ESCAPE_NO_PRINTABLES escapes the (printable)
backslash is weird but I guess it's fine because it looks more consistent to
users, even though the result is an undocumented subset of the fish language.
ESCAPE_ALL is not really a helpful name. Also it's the most common flag.
Let's make it the default so we can remove this unhelpful name.
While at it, let's add a default value for the flags argument, which helps
most callers.
The absence of ESCAPE_ALL makes it only escape nonprintable characters
(with some exceptions). We use this for displaying strings in the completion
pager as well as for the human-readable output of "set", "set -S", "bind"
and "functions".
No functional change.
When listing variables, "set" tries to escape variable names.
Since variable names cannot have special characters, this doesn't do anything.
The escaping is one of the few places that does not use ESCAPE_ALL. This has
complex behavior; let's alleviate the problem by getting rid of this call.
No functional change.
Or should we stop using it?
I'm fine with either always or never using auto-formatting but our current
way of using it only sometimes is confusing.
No functional change.
Almost all edits to our commandline are funneled through
reader_data_t::push_edit(). Notable exceptions are undo/redo (which move
across existing edits instead). Due to an oversight, undo/redo fail to
trigger commandline update hooks. Fix that.
Our behavior of triggering hooks only for the search field looks weird. I
reckon that the command line eventually catches up, but this means we trigger
some hooks redundantly. Once we figure that out we can remove the new function.
command_line_has_transient_edit tracks the actual command line, not the
pager search field. We accidentally reset it after modifying the search field
which causes unexpected behavior - the commandline added by the completion
pager remains even after I press Escape.
If the completion pager renders as
foo1 bar1 baz1 qux1
foo2 bar2 baz2
foo3 bar3 baz3
and we go backwards from "foo1" (using left arrow), we'll end up at "baz3",
not "qux1". Pretty smart!
If however we go backwards once more, nothing happens.
The root cause is that there are two different kinds of selection indices:
the one before rendering (9/qux1) and the one after we cleverly subtract
the half-filled last column (8/baz3). The backwards movement ends up
decrementing the first, so it moves from 9 to 8 and nothing changes in
the rendering.
Fix this by using the selection index that we actually rendered.
There is another caller that relies on the old behavior of using the unrendered
selection index. Make it use a dedicated overload that does not depend on
the rendering.
Otherwise realpath would add the cwd, which would be broken if fish
ever cd'd.
We could add the original cwd, but even that isn't enough, because we
need *the parent's* idea of cwd and $PATH.
Or, alternatively, what we need is for the OS to give us the actual
path to ourselves.
get_executable_path says: "This needs to be realpath'd"
So how about we do that? The only other place we use it is fish.cpp,
and we realpath it there already.
See #9085
Our pager computes the selected completion based on its rendering. The number
of rows affect the selection, in particular when moving left from the top
left cell. This computation breaks if the number of rows is zero, which
happens in at least
two scenarios:
1. If the completion pager was not shown (as is the case for complete-or-search)
2. If the search field had filtered away every candidate but not anymore.
I believe in these scenarios the selected completion index is always 0,
so let's fix the selection for that case.
Probably too minor for a changelog entry.
Closes#9080
Posix allows this as an alternative with the same semantics for read.
Found in conjunction with #9067.
Should be no functional difference on other systems.
The wait status value, which we also use internally, is read by a
bunch of macros.
Unfortunately because we want to *create* such a value, and some
systems lack the "W_EXITCODE" macro to do that, we need to figure out
how it's encoded.
So we simply check a specific value, and assume the encoding from
that.
On Haiku the return status is in the lower byte, on other systems it's
typically the upper byte.
TODO: Test on musl (that's the other system without W_EXITCODE).
Fixes#9067
PR #6777 changed all the keys to uppercase, but many Vi commands are case
sensitive.
PR #7908 changed the "u" binding but the documentation still had the old
meaning.
These are used in prompts only, and it feels weird not to have them.
In practice, fish_color_host_remote would not be used at all (just
because you switched from the default theme!), while fish_color_status
would fall back on a different value.
That'll be adjusted in the next commit.
This was an inadvertent change from
cc632d6ae9.
Because we used wgetcwd directly before, we always got the "physical"
resolved $PWD.
There's an argument to be made to use the logical $PWD here as well
but I prefer not to make changes lik that in a random commit without
good reason.
This can be used to print the modification time, like `stat` with some
options.
The reason is that `stat` has caused us a number of portability
headaches:
1. It's not available everywhere by default
2. The versions are quite different
For instance, with GNU stat it's `stat -c '%Y'`, with macOS it's `stat
-f %m`.
So now checking a cache file can be done just with builtins.
/etc/hosts specifies, that everything after a #-character is to be
treated as a comment. The current __fish_print_hostnames however only
considers #-characters at the beginning of a line.
Thus the comment from following valid hosts-entry would end up in the
completion output:
1.2.3.4 myhost # examplecomment
getent hosts properly handles comments.
These are non-POSIX extensions other test(1) utilities implement,
which compares the modification time of two files as proposed for
fish in #3589: testing if one file is newer than another file.
-ef is a common extension to test(1) which checks if two paths refer
to the same file, by comparing the dev and inode numbers.
As explained by the comment, this was dead code. If it were ever executed,
it would cause very weird behavior because it would make some completions
randomly affect others.
Let's just print a warning (maybe this is better than crashing?).
That's apparently errno 86 on macOS, and it's triggered when the
architecture is wrong.
I'll leave other macOS errors to the macOS users.
See #9052.
(cherry picked from commit 60f87ef3be)
This was supposed to be number of lines in the prompt minus 1, but
string repeat added one.
Also it triggered even in case of the stopped job message, which is
already repainted differently.
So we add it when we need to repaint ourselves.
As a bonus add a newline before in that case so the message isn't
awkwardly printed into the commandline.
Fixes#9044.
(cherry picked from commit 80fe0a7fcb)
Previously, the search text is used to find out which part of the
updated command line should be highlighted during a history search. This
approach will cause the incorrect part to be highlighted when the line
contains multiple instances of the search text.
To address this, we have to find out exactly where to highlight, i.e.
the offset of the current token in the command line (0 if not a token
search) plus the offset of the search text in the match.
If you run an initial command via `fish -c`, and that command is
cancelled e.g. via control-C, then ensure that the cancellation signal
is cleared before running config files.
Fixes#9024
(cherry picked from commit 137a4ecdf5)
Discussions with the tmux maintainer show that:
1. We no longer need the passthrough sequence at all (and it's
deactivated by default)
2. Tmux can check if the outer terminal supports cursor shaping
Fixes#8981
(cherry picked from commit b4a3b9982c)
This function is supposed to return "the next directory". Because this
is imperfect, it only tries to.
Except it went to all the trouble of figuring out the type and then
just... returned it anyway.
This has nice speedups in globs with directory components like `*/` or
`**`. I have observed 1.1x to 2.0x.
We could also return when we know it's definitely a directory and then
skip a stat() later, but preliminary testing seemed to show that's not
worth much.
GIT_SHALLOW 1 here improves generation speed and _deps in the build
dir like is 6 or 7 MB less according to `du`.
Bump the minimum PCRE2 to 10.35 on account of we use
PCRE2_SUBSTITUTE_LITERAL.
These are now available on all supported platforms, and the download
process tends to break on build workers (where Internet access is
deliberately denied).
Take advantage of additional cleanup unlocked by this refactoring,
including eliminating unneeded error returns and simplifying some
control flow.
No user-visible behavior change expected here.
This switches builtin_string from using PCRE2 directly, to using the new re
component. This simplifies some code and removes redundancy.
No user-visible behavior change expected here.
This migrates our PCRE2 dependency from builtin/string.cpp to new files
re.h/re.cpp, allowing regexes to be used in other places in fish.
No user-visible behavior change expected here.
- Generally better descriptions,
- uname checks to not complerte unavailable options on
NetBSD, FreeBSD, DragonFly, Solaris, Darwin
- Describe/complete GNU's --time=access,mtime... arg
- Remove -f it is a no-op and not documented.
When we want to print something while the prompt is still active, we move the
cursor by printing a newline for each line in the prompt beyond the first
one. As established by 80fe0a7fc (fish_job_summary: Format message better
for multiline prompts, 2022-06-28), our use of "string repeat" actually
prints an extra newline. Let's remove it here as well.
This switches the flag_to_function from a map to just an ordinary switch
statement. This saves some memory/startup time and removes some
relocations. No functional change here.
Commit ad9b4290e optimized git completions by adding a completion that would
run on every completion request, which allows to precompute data used by
other completion entries. Unfortunately, the completion entry is not run
when the commandline contains a flag like `git -C`. If we didn't
already load git.fish, we'd error. Additionally, we got false positive
completions for `git diff -c`.
So this hack was a very bad idea. We should optimize in another way.
(cherry picked from commit fee5a9125a)
This switches to using the CMake FetchContent path to dynamically download
and build PCRE2, allowing us to drop the vendored sources.
The FISH_USE_SYSTEM_PCRE2 CMake option is kept, but if false it now means
fetch-and-build PCRE2 rather than building vendored sources.
Note FetchContent was introduced in CMake 3.11. That is now a prerequisite
for building fish with FISH_USE_SYSTEM_PCRE2 disabled.
This was supposed to be number of lines in the prompt minus 1, but
string repeat added one.
Also it triggered even in case of the stopped job message, which is
already repainted differently.
So we add it when we need to repaint ourselves.
As a bonus add a newline before in that case so the message isn't
awkwardly printed into the commandline.
Fixes#9044.
This adds a line to `set --show`s output like
```
$PATH: originally inherited as |/home/alfa/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/var/lib/flatpak/exports/bin|
```
to help with debugging.
Note that this means keeping an additional copy of the original
environment around. At most this would be one ARG_MAX's worth, which
is about 2M.
This is sort of slow because it's called hundreds of times.
We used to have a cache, introduced in ad9b4290e, but it was removed
in fee5a9125a because it had
false-positives.
So what we do, because the issue is that this is called hundreds of
times per-commandline, we cache it keyed on the commandline.
This speeds up `complete -C'git sta'` by a factor of 2.3x.
It's still useful without, for instance to implement a command that
takes no options, or to check min-args or max-args.
(technically no optspecs, no min/max args and --ignore-unknown does
nothing, but that's a very specific error that we don't need to forbid)
Fixes#9006
Commit ad9b4290e optimized git completions by adding a completion that would
run on every completion request, which allows to precompute data used by
other completion entries. Unfortunately, the completion entry is not run
when the commandline contains a flag like `git -C`. If we didn't
already load git.fish, we'd error. Additionally, we got false positive
completions for `git diff -c`.
So this hack was a very bad idea. We should optimize in another way.
Resolves this warning:
> warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Wdeprecated-declarations]
[100%] Building HTML documentation with Sphinx
../CHANGELOG.rst:42: ERROR: Document or section may not begin with a transition.
[100%] Built target sphinx-docs
This is essentially a duplicate of commit cd1f0cc5d :-)
This enhances our documentation to look for the file
/release_version.json in the root of our site. If found, and if it
contains a RELEASE_VERSION other than this version, then unhide a banner
warning about the stale documentation and linking to the current.
If you run an initial command via `fish -c`, and that command is
cancelled e.g. via control-C, then ensure that the cancellation signal
is cleared before running config files.
Fixes#9024
Discussions with the tmux maintainer show that:
1. We no longer need the passthrough sequence at all (and it's
deactivated by default)
2. Tmux can check if the outer terminal supports cursor shaping
Fixes#8981
This concerns what happens if the user types e.g. `grep --i` and grep or
its completions have not yet been loaded. Previously we would "bounce to
the main thread" from within the autosuggestion thread to load grep's
completions. However under concurrent execution, this may deadlock as the
main thread is waiting for something else.
In the new implementation, complete simply records the commands that it
would autoload, and returns them back to the caller, where the caller can
decide how to handle them.
In general iothread_perform_on_main risks deadlock under concurrent
execution and we should try to get rid of it.
There should be no user-visible change from this fix.
This is simply an error in test setup. There's a limit to how far we
can isolate them from the system.
(it's possible new cmake versions close fds automatically since I
can't reproduce the original issue via `ninja test` or `make test`)
Fixes#9017
This commit lets you check the manpage for a leading command by moving
the cursor over it, matching the behavior of tab complete.
It also lets you select the man page for the base of a two-part command
like `string match`.
The additional regex case is added because
`commandline -t` returns an empty string when the cursor is after a
space, e.g. at the end of 'sudo ', which the later checks don't handle.
This diagram shows the manpage picked for different cursor positions:
> sudo -Es time git commit -m foo
+-------++---++--++------------+
| || || || |
| || || |+------------+
| || || | git-commit
| || |+--+
| || | git
| |+---+
| | time
+-------+
sudo
Unlike before, this doesn't force the number to be on the same line as
strongly, that's fine.
So short footnotes look like
-------------
[1] Some text
-------------
Longer footnotes may look like
--------------
[2]
Some more text
--------------
The "Warning:" on the warning (in index.html#default shell) wasn't in
the line with the text, the features list had more padding and some
headers were smaller, some table stuff
This has required workarounds a few times, plus if it changes it might
break our theme. See e.g.
4712da3eb1e27456df24a6d484836e85522036f5
So we import the rules we *use* and throw away the rest. Note that
this might still have rules that are no longer necessary - e.g. some
that are required to work around sphinx bugs would still be left.
It could benefit from some cleanup and simplification, and from
switching to a flex layout instead of the 230px hardcoded
sidebar - sphinx tried that, but it doesn't really work with our
narrow layout, so we disabled it again.
I keep some files around that I don't *want* to commit or ignore, but
it's fine to restyle them.
It's also fine to restyle everything if you are about to commit
something because then it'll be committed in the correct style.
The last remnant of the old debug system, this was only used in
show_stackframe.
Because that's only ever called with an "E" level currently I've
removed the level argument entirely. If it's needed we'd have to pass
a flog category here.
* updated function __fish_print_portage_repository_paths.fish to support file, dir and modified defaults
* Revised version of share/functions/__fish_print_portage_repository_paths.fish
* improved syntax and regex as suggested
The recent improvements to multiline prompts and vi-mode in #3481 appear
to be sufficient to make iTerm2 well behaved, so remove our hack which
disabled it by default.
Fixes#3696
The fix for #3481 caused us to save the screen status after external
commands were run, fixing an unnecessary abandon-line when switching
modes. But we may also run commands not directly as part of a binding,
but instead via an on-variable event, e.g. for fish_bind_mode.
Extend this fix to all bindings, guarded by changes to exec_count. Now
any time an external command runs as part of a binding we should pick up
changes to the tty and not abandon the line.
Fixes#3481 again.
git versions that only support porcelain v1 output (like on CentOS 7,
which has 1.8.3) weren't completing files prefixed with : correctly iff
the name after the colon was also a valid relative path.
Fixes the tests on CentOS 7.
This lacks the tmux-256color terminfo entry, leading to spurious
warnings like
warning: Could not set up terminal. <= no check matches
warning: TERM environment variable set to \'tmux-256color\'. <= no check matches
warning: Check that this terminal type is supported on this system. <= no check matches
warning: Using fallback terminal type \'ansi\'. <= no check matches
This removes the awkward secondary logic.
Note that we still ship a function called `__terlar_git_prompt`
because people who picked the prompt will still be calling it - we
don't update the prompt.
Old version of CMake seem to have trouble connecting the standard test
target with the need to build the fish_tests binary; use the target that
has been added specifically for this purpose instead.
Git's pathspec system is kind of annoying:
> A pathspec that begins with a colon : has special meaning. In the short form, the leading colon : is followed by zero or more "magic signature" letters (which optionally is terminated by another colon :), and the remainder is the pattern to match against the path. The "magic signature" consists of ASCII symbols that are neither alphanumeric, glob, regex special characters nor colon. The optional colon that terminates the "magic signature" can be omitted if the pattern begins with a character that does not belong to "magic signature" symbol set and is not a colon.
So if we complete `:/foo`, that "works" because "f" is alphanumeric
and so the "/" is the only magic character here.
If, however the filename starts with a magic character, that's used as
a magic signature.
So we do what the docs say and terminate the magic signature after the
"/" (which means "from the repo root").
Fixes#9004
This makes it so
1. The informative status can work without showing untracked
files (previously it was disabled if bash.showUntrackedFiles was
false)
2. If untrackedfiles isn't explicitly enabled, we use -uno, so git
doesn't have to scan all the files.
In a large repository (like the FreeBSD ports repo), this can improve
performance by a factor of 5 or up.
In b0084c3fc4, we refactored out event handlers get removed. But this
also caused us to remove "one-shot" handlers even if they have not yet
been fired. Fix this.
This concerns running a key binding which invokes a command. If that
command modifies the tty, then fish will spot the modification later and
then react to it by redrawing the prompt. However tty modifications may
be benign or desirable; for example switching the cursor from a line to
a block. Fix this by re-fstating the tty after running external
commands.
Fixes#3481
Previously, `kill-whole-line` kills the line and its following
newline. This is insufficient when we are on the last line, because
it would not actually clear the line. The cursor would stay on the
line, which is not the correct behavior for bindings like `dd`.
Also, `cc` in vi-mode used `kill-whole-line`, which is not correct
because it should not remove any newlines. We have to introduce
another special input function (`kill-inner-line`) to fix this.
Arguments to --ignored were introduced in Git 2.16, from January 2018.
The git completions specifically work around this, allowing older
versions to be used; match this in the git prompt.
Fixes the tests on CentOS 7.
This is broken in narrow screens - the sidebar shrinks to unusable
proportions but still stays.
So instead we go the *other* way, force the left margin and undo the flexifying.
(again we should really stop relying on sphinx' css)
When the user adds a completion for a command, we push it to the front
of the completion list so it appears first; for that reason we don't
want to use a vector. However we can do better than std::list; try using
std::forward_list which is singly linked. No functional change here (but
we will see if this breaks any old platforms in which case it's fine to
revert this).
Prior to this change, the list of completions was stored as a
std::unordered_set, using some funny comparators and suspicious
const_cast to make it map-like. Use a real map instead, simplifying
the code. No functional change here.
Sphinx 5.0 makes the document div a flex container, which clashes
badly with the margin that earlier versions need.
So we remove the margin and flex the div ourselves, which should work
with either.
It's time we make this freestanding - these changes are annoying.
When switching this to use `git status`, I neglected to use the
correct definition of what a "dirty" and a "staged" change is.
So this now showed already staged files still as "dirty".
Fixes#8986
Prior to this commit, setting a universal variable may trigger syncing
against the file which will modify other universal variables. But if we
want to support multiple environments we need the parser to decide when to
sync uvars. Shift the decision of when to sync to the parser itself. When a
universal variable is modified, now we just set a flag and it's up to the
(main) parser when to pick it up. This is hopefully just a refactoring with
no user-visible changes.
This makes it so `complete -c foo -n test1 -n test2` registers *both*
conditions, and when it comes time to check the candidate, tries both,
in that order. If any fails it stops, if all succeed the completion is offered.
The reason for this is that it helps with caching - we have a
condition cache, but conditions like
```fish
test (count (commandline -opc)) -ge 2; and contains -- (commandline -opc)[2] length
test (count (commandline -opc)) -ge 2; and contains -- (commandline -opc)[2] sub
```
defeats it pretty easily, because the cache only looks at the entire
script as a string - it can't tell that the first `test` is the same
in both.
So this means we separate it into
```fish
complete -f -c string -n "test (count (commandline -opc)) -ge 2; and contains -- (commandline -opc)[2] length" -s V -l visible -d "Use the visible width, excluding escape sequences"
+complete -f -c string -n "test (count (commandline -opc)) -ge 2" -n "contains -- (commandline -opc)[2] length" -s V -l visible -d "Use the visible width, excluding escape sequences"
```
which allows the `test` to be cached.
In tests, this improves performance for the string completions by 30%
by reducing all the redundant `test` calls.
The `git` completions can also greatly benefit from this.
This adds a path builtin to deal with paths.
It offers the following subcommands:
filter to go through a list of paths and only print the ones that pass some filter - exist, are a directory, have read permission, ...
is as a shortcut for filter -q to only return true if one of the paths passed the filter
basename, dirname and extension to print certain parts of the path
change-extension to change the extension to a different one (as a string operation)
normalize and resolve to canonicalize the paths in various flavors
sort to sort paths, also only using the basename or dirname as a key
The definition of "extension" here was carefully considered and should line up with how extensions are actually used - ~/.bashrc doesn't have an extension, but ~/.conf.d does (".d").
These subcommands all compose well - they can read from arguments or stdin (like string), they can use null-delimited input or output (input is autodetected - if a NULL happens in the first PATH_MAX bytes it switches automatically).
It is both a failglob exception (so like set if a glob passed to it fails it just doesn't get any arguments for it instead of triggering an error), and passes output to command substitution buffers explicitly split (like string split0) so newlines are easy to handle.
This would still remove non-existent paths, which isn't a strict
inversion and contradicts the docs.
Currently, to only allow paths that exist but don't pass a type check,
you'd have to filter twice:
path filter -Z foo bar | path filter -vfz
If a shortcut for this becomes necessary we can add it later.
This is now added to the two commands that definitely deal with
relative paths.
It doesn't work for e.g. `path basename`, because after removing the
dirname prepending a "./" doesn't refer to the same file, and the
basename is also expected to not contain any slashes.
Because we now count the extension including the ".", we print an
empty entry.
This makes e.g.
```fish
set -l base (path change-extension '' $somefile)
set -l ext (path extension $somefile)
echo $base$ext
```
reconstruct the filename, and makes it easier to deal with files with
no extension.
This means "../" components are cancelled out even after non-existent
paths or files.
(the alternative is to error out, but being able to say `path resolve
/path/to/file/../../` over `path resolve (path dirname
/path/to/file)/../../` seems worth it?)
This sorts paths by basename, dirname or full path - in future
possibly size or age.
It takes --invert to invert the sort and "--what=basename|dirname|..."
to specify what to sort
This can be used to implement better conf.d sorting, with something
like
```fish
set -l sourcelist
for file in (path sort --what=basename $__fish_config_dir/conf.d/*.fish $__fish_sysconf_dir/conf.d/*.fish $vendor_confdirs/*.fish)
```
which will iterate over the files by their basename. Then we keep a
list of their basenames to skip over anything that was already
sourced, like before.
The recent change to skip the newline for `string` changed this, and
it also hit builtin path (which is in development separately, so it's
not like it broke master).
Let's pick a good default here.
Yeah, the macOS tests fail because it's started in /private/var... with a
$PWD of /var.... So resolve canonicalizes the path, which makes it no
longer match $PWD.
Simply use pwd -P
This just goes back until it finds an existent path, resolves that,
and adds the normalized rest on top.
So if you try
/bin/foo/bar////../baz
and /bin exists as a symlink to /usr/bin, it would resolve that, and
normalize the rest, giving
/usr/bin/foo/baz
(note: We might want to add this to realpath as well?)
This includes the "." in what `path extension` prints.
This allows distinguishing between an empty extension (just `.`) and a
non-existent extension (no `.` at all).
These are short flags for "--perm=read" and "--type=link" and such.
Not every type or permission has a shorthand - we don't want "-s" for
"suid". So just the big three each get one.
This is needed because you might feasibly give e.g. `path filter`
globs to further match, and they might already present no results.
It's also well-handled since path simply does nothing if given no paths.
These were officially called "--null-input", but I just used
"--null-in" everywhere, which worked because getopt allows unambiguous abbreviations.
But since *I* couldn't keep it straight and the "put" is just
superfluous, let's remove it.
This is theoretically sound, because a path can only be PATH_MAX - 1
bytes long, so at least the PATH_MAXest byte needs to be a NULL.
The one case this could break is when something has a NULL-output mode
but doesn't bother printing the NULL for only one path, and that path
contains a newline. So we leave --null-in there, to force it on.
This adds a "path" builtin that can handle paths.
Implemented so far:
- "path filter PATHS", filters paths according to existence and optionally type and permissions
- "path base" and "path dir", run basename and dirname, respectively
- "path extension PATHS", prints the extension, if any
- "path strip-extension", prints the path without the extension
- "path normalize PATHS", normalizes paths - removing "/./" components
- and such.
- "path real", does realpath - i.e. normalizing *and* link resolution.
Some of these - base, dir, {strip-,}extension and normalize operate on the paths only as strings, so they handle nonexistent paths. filter and real ignore any nonexistent paths.
All output is split explicitly, so paths with newlines in them are
handled correctly. Alternatively, all subcommands have a "--null-input"/"-z" and "--null-output"/"-Z" option to handle null-terminated input and create null-terminated output. So
find . -print0 | path base -z
prints the basename of all files in the current directory,
recursively.
With "-Z" it also prints it null-separated.
(if stdout is going to a command substitution, we probably want to
skip this)
All subcommands also have a "-q"/"--quiet" flag that tells them to skip output. They return true "when something happened". For match/filter that's when a file passed, for "base"/"dir"/"extension"/"strip-extension" that's when something about the path *changed*.
Filtering
---------
`filter` supports all the file*types* `test` has - "dir", "file", "link", "block"..., as well as the permissions - "read", "write", "exec" and things like "suid".
It is missing the tty check and the check for the file being non-empty. The former is best done via `isatty`, the latter I don't think I've ever seen used.
There currently is no way to only get "real" files, i.e. ignore links pointing to files.
Examples
--------
> path real /bin///sh
/usr/bin/bash
> path extension foo.mp4
mp4
> path extension ~/.config
(nothing, because ".config" isn't an extension.)
The best effort parser over-eagerly strips all extensions off a manual
page file's basename, hence commands containing dots will output
completions for a different command.
Prominent examples are the mkfs.*(8) and fsck.*(8) families, e.g.
completions for mkfs.xfs.8.gz are generated for the command `mkfs`
is not only incorrect but can also filename collisions in case .fish
files for multiple commands are put into the same directory.
Thus do not strip everything past the first dot from the left, but
instead merely strip expected extensions from the right.
This teaches `--on-signal SIGINT` (and by extension `trap cmd SIGINT`)
to work properly in scripts, not just interactively. Note any such
function will suppress the default behavior of exiting. Do this for
SIGTERM as well.
s_observed_signals is used to inform the signal handler which signals may
have --on-signal functions attached to them, as an optimization. Prior to
this change it was latched: once we started observing a signal we assume we
will keep observing that signal. Make it properly increment and decrement,
in preparation for making trap work non-interactively.
edit_command_buffer uses the "norm" command for moving the cursor to a column
with the "|" primitive. The problem is that the user can remap "|". Fix this
by using the "norm!" variant which ignores user mappings (see ":h norm").
Closes#8971
git had a CVE related to arbitrary code being run when you run git status and similar, and instead of doing something about those arbitrary code bits they decided to lock it down entirely.
So now git will refuse to do basically anything once it detects the .git directory is owned by someone else.
So, what we do is:
If `git describe` failed with a status of 128, we keep an already
built version file.
This is an awful hack, but should help with the normal `cmake; make; sudo
make install` cycle.
(the only *real* way around this seems to be to not attempt to rebuild
the version file at install time entirely, but I have no idea how to
do that)
Fixes#8973.
With sphinx 4.5.0:
1. Some of our builtins actually give results (cd, end, set)
2. Some give broken results (and, if, or)
3. Only "for" even triggers the help page we hacked in
So this is of dubious use, and removing it gets us out of the awkward situation of shipping it.
Plus upstream sphinx has ditched jquery, so we would have to rewrite it anyway.
Like `set` and `read` before it, `eval` can be used to set variables,
and so it can't be shadowed by a function without loss of
functionality.
So this forbids it.
Incidentally, this means we will no longer try to autoload an
`eval.fish` file that's left over from an old version, which would
have helped with #8963.
Previously, running `fish_add_path /foo /foo` would result in /foo
being added to $PATH twice.
Now we check that it hasn't already been given, so we skip the
second (and any further) occurence.
[ 97%] Building man pages with Sphinx
../CHANGELOG.rst:123: WARNING: Bullet list ends without a blank line; unexpected unindent.
[ 97%] Built target sphinx-manpages
[ 98%] Building HTML documentation with Sphinx
../CHANGELOG.rst:123: WARNING: Bullet list ends without a blank line; unexpected unindent.
This concerns what happens if one event handler removes another, when
both are responding to the same event. Previously we had a "double lock"
where we would traverse the list twice. Now track directly in the
handler when it is removed; this simplifies the code a lot. No
functional changes expected here.
Hitting tab on "echo **" will often result in more than 256 matches.
Commit 143757e8c (Expand wildcards on tab, 2021-11-27) describes this scenario
> If the expansion would produce more than 256 items, we flash the command
> line and do nothing, since it would make the commandline overfull.
Yet we actually erase the "**" token, which seems wrong since we already
flash the command line. Fix this, at the cost of making the code a bit uglier.
I tried to write a test in tests/pexpects/wildcard_tab.py but that doesn't
seem to work because pexpect provides only a "dumb" terminal. I wonder if we
can test what we write to the screen without depending on a terminal emulator.
`wg show` command shows entire interfaces configuration, not just the
list. This breaks completion when running fish from root, because
command output looks like this:
interface: wg0
public key: fred2rX85AxpcTObLuiWTzkRPZaXjnhd1C4XOdZOGWs=
private key: (hidden)
listening port: 12345
fwmark: 0xca6c
peer: g2YHHDkxmgoT9EV0TxKtq556WLXpaOh4zgC5L7EAGTQ=
endpoint: 192.168.88.50:54321
allowed ips: 0.0.0.0/0, ::/0
latest handshake: 1 minute, 37 seconds ago
transfer: 1.83 MiB received, 927.19 KiB sent
To show just the list of active interfaces, `wg show interfaces` should
be used instead.
man-db's man 2.7 as shipped in OpenSUSE fails to set a non-zero
exit code when invoked like "man ls-some/dir". This means
that we fail to display the man page if the commandline is
"ls some/dir". Work around this by never treating tokens
with slashes as subcommand.
Because TAGs are easy to type and complete, but commits with its SHA are
difficult to complete manualy. Keep commits and TAGs order to show more recent
commits first.
Pressing Ctrl-D while a command is running results in a null key code in
our input queue. That key code is bound to insert a space (without expanding
abbreviations). Make it only insert a space if the commandline is non-empty,
to accommodate this use case.
This probably affects other keys as well.
Closes#8871
c4fb857dac (in 3.4.1) introduced a regression where process_exit
events would only fire once the job itself is complete. Allow
process_exit events to fire before that. Fixes#8914.
This is after we've tried to find the interpreter, so we would already
have complained about e.g. /usr/bin/pthyon not existing.
Realistically the most common case here is things that don't start
with a shebang like ELFs. Writing special extraction code here is
overkill, and I can't see a good function to do it for us.
But this should point you in the right direction.
Fixes#8938
This gets the passwd entry for $USER (if it is set). If that gives the
same uid that geteuid() gives us, we assume the data is correct.
If not, we reset $USER (and $HOME if it's empty) from the passwd value for our UID.
This allows using $USER in a prompt even if you've `su`d. Bash gets around this by having a special escape in its $PS1 DSL that checks passwd instead.
Fixes#8583
Whenever completing any git commandline, we invoke __fish_git_using_command
173 times*. Every invocation calls "commandline" and "argparse"
to the same effect. Let's parse the command line once, and reuse the results
later.
I'm observing a speed-up from 200ms to 120ms with
perf stat -r 10 buildrel/fish -c 'complete -C "git checkout ">/dev/null'
Alternative solutions:
1. teach fish to cache such things automatically.
2. rewrite git completions to compute most completions in a single function,
which will naturally avoid redundant work. This sounds viable but it's
a lot of work.
* we have a thousand uses of __fish_git_using_command, so I'm not sure why
it's only 173.
See the discussion in #8266
As we've noticed a few times now, mingw/msys/cygwin has a fairly
horrible kill implementation that annoys us here.
However our workaround wasn't enough - "mingw" is also a name that is
used here and "msys" can also be a substring.
Also we need to silence the `kill` because it's better to not list the
signals than it is to spew errors.
Fixes#8915.
We don't need to make the feature flag descriptions as terse as
possible, I believe some people were confused by what this all means,
so we can dedicate a few lines to explaining it again.
This reverts commit ccb6cb1abe.
CI fails with
/home/runner/work/fish-shell/fish-shell/src/autoload.cpp:148:1: error: function ‘autoload_t::autoload_t(autoload_t&&)’ defaulted on its redeclaration with an exception-specification that differs from the implicit exception-specification ‘’
148 | autoload_t::autoload_t(autoload_t &&) noexcept = default;
| ^~~~~~~~~~
make[2]: *** [CMakeFiles/fishlib.dir/build.make:96: CMakeFiles/fishlib.dir/src/autoload.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:369: CMakeFiles/fishlib.dir/all] Error 2
make: *** [Makefile:139: all] Error 2
Not sure what's wrong - it compiles fine on my machine. Will check later.
Some terminals can be configured to send variuos escape sequences for keys
that could historically not be detected. Turns out some usage pattern rely
on those quirks.
Shift+Space is easy to mistype when wanting to insert a space (especially
when typing ALL CAPS). Map it to Space, to match user expectations.
Similarly for Control+Return, for which xterm can be configured to send
something other than \cr:
echo 'XTerm.vt100.modifyOtherKeys: 1' | xrdb && xterm
I'm working on a change to builtin bind that allows to bind CSI sequences via
human-readable key names (#3018) but for now let's just map the raw sequences.
Closes#8874
Even though we disable exceptions, we use noexcept in some
places to enable certain optimizations in std::vector, see
https://en.cppreference.com/w/cpp/utility/move_if_noexcept.
Some methods have noexcept only at their declaration (or only at the
definition). This will be an error when compiling with "g++ -std=c++17". Make
both signatures match.
micro only parses the [FILE]:LINE:COL syntax
if the parsecursor option is enabed
in the meanwhile, the +LINE:COL syntax is unambiguous and always valid
You can use an index with vared, like `vared PATH[4]`. However this was
inadverently broken in fa2450db30, because you cannot use `read` to
modify an element of a variable, only the whole variable. Fix this.
Unfortunately this means using another local variable, so we name it
__fish_vared_temp_value instead of just temp so that collisions are
unlikely.
This cleans up the path_get_path function which is used to resolve a
command name against $PATH, by removing the dependence on errno and
being explicit about which error is returned.
Should be no user-visible change here.
[100%] Building HTML documentation with Sphinx
[100%] Building man pages with Sphinx
../CHANGELOG.rst:13: ERROR: Unexpected indentation.
../CHANGELOG.rst:15: WARNING: Block quote ends without a blank line; unexpected unindent.
../CHANGELOG.rst:13: ERROR: Unexpected indentation.
../CHANGELOG.rst:15: WARNING: Block quote ends without a blank line; unexpected unindent.
localectl may emit an error for whatever reason. The localectl
completion runs localectl in a command substitution so our stderr
redirect doesn't apply. Just redirect to null. Hopefully this fixes the
tests.
This *might* be a bit faster running under TSAN, otherwise it takes >
400 seconds on Github Actions.
If this doesn't work we need to disable it for TSAN.
I *think* this is printing
> debconf: DbDriver "passwords" warning: could not open /var/cache/debconf/passwords.dat: Permission denied
On Github Actions?
Might need to adjust the test to store the output.
The current Github Actions ubuntu-latest image crashes in the
autosuggest_suggest_special test with ASAN.
We have not been able to reproduce this locally, and this is getting
in the way.
I have no idea how to disable this test on ASAN specifically, all my
attempts have failed. So the only recourse I know is to disable the
ASAN tests on GA entirely.
* Print message in set_fish_path -v when a path doesnt exist
* Update changelog
* Remove "; or continue"
* use printf instead of echo, avoid localizing the path
Curses variables like `enter_italics_mode` are secretly defined to
dereference through the `cur_term` variable. Be sure we do not read or
write these curses variables if cur_term is NULL. See #8873, #8875.
Add a regression test.
Apple's terminfo has missing support for enter_italics_mode,
exit_italics_mode, and enter_dim_mode. Previously we would hack in such
support in set_color; migrate that to init_curses so we do it up-front
instead of opportunistically.
To recap, this means `&` in the middle of a word no longer
backgrounds.
So:
```fish
echo foo&bar # prints foo&bar
echo foo& bar # backgrounds an echo that prints "foo" and runs "bar"
```
This can no longer be changed. If "no-stderr-nocaret" is in
$fish_features it will simply be ignored.
The "^" redirection that was deprecated in fish 3.0 is now gone for good.
Note: For testing reasons, it can still be set _internally_ by running
"feature_flags_t::set". We simply shouldn't do that.
This is a follow-up to #8811, which fixed fish_config on newer versions of
Sailfish OS.
Using the previous method to open the fish_config URL on Sailfish OS worked
only on 4.4 (and 4.3 IIRC), but not on older OS versions. Opening the URL
using xdg-open works well with new and old OS version, and has been tested on
- Sony Xperia 10 II running SFOS 4.4 aarch64
- Sony Xperia XA2 Ultra running SFOS 4.4 armv7hl
- Sony Xperia X running SFOS 4.1 armv7hl
- Jolla Phone running SFOS 3.4 armv7hl
Closes#8872
* feat(completions): add sops completions
* fix: start descriptions with uppercase letter
* fix: shorten descriptions
* fix: use spaces instead of ;
* fix: typo
* feat: better option than __fish_is_first_token
* feat: improve __fish_sops_commands function
* fix: remove useless code
* fix: fix the second argument is not called
If we get an E2BIG while executing a process, we check how large the
exported variables are. We already did this, but then immediately
added it to the total.
So now we keep the tally just for the variables around, and if it's
over half (which is an atypical value if your system has an ARG_MAX of
2MB), we mention that in the error.
Figuring out which variable is too big (in case it's just one) is probably too complicated,
but we can at least complain if things seem suspect.
Untested because I don't know *how* to do so portably
Prior to this change, if you tab-completed a token with a wildcard (glob), we
would invoke ordinary completions. Instead, expand the wildcard, replacing
the wildcard with the result of expansions. If the wildcard fails to expand,
flash the command line to signal an error and do not modify it.
Example:
> touch file(seq 4)
> echo file*<tab>
becomes:
> echo file1 file2 file3 file4
whereas before the tab would have just added a space.
Some things to note:
1. If the expansion would produce more than 256 items, we flash the command
line and do nothing, since it would make the commandline overfull.
2. The wildcard token can be brought back through Undo (ctrl-Z).
3. This only kicks in if the wildcard is in the "path component
containing the cursor." If the wildcard is in a previous component,
we continue using completions as normal.
Fixes#954.
When fish expands a string that starts with a tilde, like `~/stuff/*`, it
first must resolve the tilde (e.g. to the user's home directory) before
passing it to wildcard expansion. The wildcard expansion will produce full
paths like `/home/user/stuff/file`. fish then "unexpands" the home directory
back to a tilde.
Previously this was only used during completions, but in the next commit
we plan to use it for string expansions as well.
Rationalize this behavior by adding an explicit flag to request it and
explain some subtleties about completions.
When a pexpect test fails, it reports the "failing line." Prior to this
commit, it did so by walking up the Python call stack, looking for
the first frame which is not in the pexpect_helper module, and so presumably
in the test itself. However sometimes the test wants to define a helper
function; then if the test fails the helper function is reported as the
failing line, not the callsite of the helper.
Fix this by skipping functions which have the `callsite_skip` attribute set.
Nothing to relnote here.
As explained in the parent commit, if we print things to the command line,
we move the cursor down before redrawing a multi-line prompt. This is a
workaround to avoid erasing what we printed.
We forgot to do add this workaround to fish_job_summary. When running
`sleep 1 &` with a multiline prompt, the job exit notification is immediately
overwritten (most of the time). This can be observed consistently on Linux
by waiting before redrawing:
diff --git a/share/functions/fish_job_summary.fish b/share/functions/fish_job_summary.fish
index a552fabbc..f457ee8e8 100644
--- a/share/functions/fish_job_summary.fish
+++ b/share/functions/fish_job_summary.fish
@@ -52,6 +52,7 @@ function fish_job_summary -a job_id is_foreground cmd_line signal_or_end_name si
string repeat \n --count=(math (count (fish_prompt)) - 1) >&2
if test $is_foreground -eq 0; and test $signal_or_end_name != STOPPED
+ sleep 1
commandline -f repaint
end
end
Move the cursor down to work around this. In future, we could avoid calling
fish_prompt. Also, this solution add an extra blank lines before the next
prompt. With a real fix, we could get rid of that. Even worse, sometimes
there are two blank lines instead of one (for a two-line prompt).
Fixes#8817
We have some key bindings that print directly to the terminal while the user
is still typing the command line. Thereafter, we redraw the command line,
so the user can resume typing. To redraw a multiline command line, we first
erase several lines above the cursor. To not erase the key bindings' output,
we move the cursor down that many lines.
Simplify the logic; no functional change.
This commit was problematic for a few reasons:
1. It silently changed the behavior of argparse, by switching which
characters were replaced with `_` from non-alphanumeric to punctuation.
This is a potentially breaking change and there doesn't appear to be any
justification for it.
2. It combines a one-line if with a multi-line else which we should try
to avoid.
This reverts commit 63bd4eda55.
This reverts commit 4f835a0f0f.
These macros were historically used only in internal error messages which
should never happen! Now we are able to enforce they never happen at
compile time so we can remove them.
No functional change here.
If we ever need any of these... they're in this commit:
fish_wcswidth_visible()
status_cmd_opts_t::feature_name
completion_t::is_naturally_less_than()
parser_t::set_empty_var_and_fire()
parser_t::get_block_desc()
parser_keywords_skip_arguments()
parser_keywords_is_block()
job_t::has_internal_proc()
fish_wcswidth_visible()
When you do
```fish
set foo-bar baz
```
"foo-baz" isn't usable as a variable *name*. When you just say the
"variable" is invalid that could also be interpreted to be a special
type of variable or something.
This conditionally set a function variable in an unsafe way.
If you do something like
```fish
if condition
set -f foo bar
end
```
then, if the condition was false, $foo could still use a global variable.
In this case, alias would now fail if a variable $wraps was defined globally.
This reverts most of commit 14458682d9.
The message rewording can stay, it's *fine* (tho it'll break the
translations but then we'd need a real string freeze with a
translation team for those to be worth anything anyway, soo)
* completions/lxc: parse container names with numbers and other commands
* Revert CHANGELOG.rst
* Code Review: use multiple subcommands ability of __fish_seen_subcommand_from
String tokens are subdivided by command substitutions. Some syntax errors
can occur in the gap between two command substitutions. Make the caret point
to the start of that gap, instead of the token start.
When expanding command substitutions, we use a naïve way of detecting whether
the cmdsub has the optional leading dollar. We check if the last character was
a dollar, which breaks if it's an escaped dollar. We wrongly expand
\$(echo "") to the empty string. Fix this by checking if the dollar was escaped.
The parse_util_* functions have a bunch of output parameters. We should
return a parameter bag instead (I think I tried once and failed).
Given
set var a
echo "$var$(echo b)"
the double-quoted string is expanded right-to-left, so we construct an
intermediate "$varb". Since the variable "varb" is undefined, this wrongly
expands to the empty string (should be "ab"). Fix this by isolating the
expanded command substitution internally. We do the same when handling
unquoted command substitutions.
Fixes#8849
Static destructors cause the destructor for a global object to run when
the program exits. They are bad because:
1. Registering them takes time and memory at startup
2. Running them takes time at shutdown and also they may have weird
interactions.
This shaves about 12k off of the binary size.
Unfortunately gcc does not support this flag.
The read test is now failing on GitHub actions even though it passes on
my Mac. It may be due to differences in dd between these two
environments. Stop using dd and just use head.
The read.fish check has a test where it limits the amount of data passed to
`read` to 8192 bytes, and verifies that fish reads exactly that amount.
This check occasionally fails on the OBS builds; it's very hard to repro a
failure locally, but I finally did it.
The amount of data written is limited via `yes` and `dd`:
yes $line | dd bs=1024 count=(math "$fish_read_limit / 1024")
The bug is that `dd` outputs a fixed number of "blocks" where a block
corresponds to a single read. As `yes` and `dd` are running concurrently,
it may happen that `dd` performs a short read; this then counts as a single
block. So `dd` may output less than the desired amount of data.
This can be verified by removing the 2>/dev/null redirection; on a
successful run dd reports `8+0 records out`, on a failed run it reports
`7+1 records out` because one of the records was short.
Fix this by using `fullblock` so that dd will no longer count a short read
as a single block. `head` would probably be a simpler tool to use but we'll
do this for now.
Happily it's not a fish bug. No need to relnote it.
1. Bravely use a real enum for has_arg, despite the warnings.
2. Use some C++11 initializers so we don't have to pass an int for this
parameter.
No functional change expected here.
git.fish loads git-foo.fish completions.
As reported in #8831, this can be slow when the user has run something like
complete git-foo -w 'git diff'
because git.fish runs 'complete -C "git-autofixup "' at load time.
Commit 09161761c (Complete custom "git-foo" commands from "git foo",
2021-01-24) did that to avoid adding filename completions for "git foo".
Drop that check.
This means that users who don't want filename completion for "git foo",
need to define at least one custom completion for "git-foo", like
complete git-foo -f
If the history file is larger than 4GB on a 32 bit system, fish will
refuse to read it. However the check was incorrect because it cast the
file size to size_t, which may be 32 bit. Switch to using uint64.
fd_monitor is used when an external command pipes into a buffer, e.g. for
command substitutions. It monitors the read end of the external command's
pipe in the background, and fills the buffer as data arrives. fd_monitor is
multiplexed, so multiple buffers can be monitored at once by a single
thread.
It may happen that there's no active buffer fill; in this case fd_monitor
wants to keep its thread alive for a little bit in case a new one arrives.
This is useful for e.g. handling loops where you run the same command
multiple times.
However there was a bug due to a refactoring which caused fd_monitor to
exit too aggressively. This didn't affect correctness but it meant more
thread creation and teardown.
Fix this; this improves the aliases.fish benchmark by about 20 msec.
No need to changelog this IMO.
This was already apparently supposed to work, but didn't because we
just overrode errno again.
This now means that, if a correctly named candidate exists, we don't
start the command-not-found handler.
See #8804
-d has been removed in FreeBSD 13 & monterey
-t has also been removed from date(1)
-n has been "Obsolete flag, accepted and ignored for compatibility",
for a while, leave it out.
-R added for RFC 2822
-I added for ISO 8601
Some description changes
The tmp and prompt variables collide with variables used as arguments.
Just avoid them entirely, at the cost of making the internals of the
functions somewhat more complicated.
Closes#8836.
This used to call exec_subshell, which has two issues:
1. It creates a command substitution block which shows up in a stack
trace
2. It does much more work than necessary
This removes a useless "in command substitution" from an error message
in an autoloaded file, and it speeds up autoloading a bit (not
measurable in actual benchmarks, but microbenchmarks are 2x).
Otherwise this was 100% monospace.
But since we have a specific list of fonts that we have checked, let's
use the same list instead of just adding "Helvetica" again.
This is a less-intrusive version of 95845b1, and only disables the
search for frameworks for libintil (sometimes shipped with Mono, but not
usable for compilation).
Closes#5244.
These printed an error on load if networkmanager isn't running.
Since at that point it's not useful to complete anything, just try the
first call and if that fails exit.
We need special handling when reporting backtraces for commands run
during startup, i.e. config.fish. Previously we had a global variable;
make it local to the parser to eliminate a global.
No functional change here.
Cancellation groups were meant to reflect the following idea: if you ran a
simple block:
begin
cmd1
cmd2
end
then under job control, cmd1 and cmd2 would get separate groups; however if
either exits due to SIGINT or SIGQUIT we also want to propagate that to the
outer block. So the outermost block and its interior jobs would share a
cancellation group. However this is more complex than necessary; it's
sufficient for the execution context to just store an int internally.
This ought not to affect anything user-visible.
Currently, when a variable like $fish_color_command is set but empty:
set -g fish_color_command
what happens is that highlight parses it and ends up with a "normal"
color.
Change it so instead it sees that the variable is empty and goes
on to check the fallback variable, e.g. fish_color_normal.
That makes it easier to make themes that override variables.
This means that older themes that expect an empty variable to be
"normal" need to be updated to set it to "normal".
Following from this, we could make writing .theme files easier by no
longer requiring them to list all variables with specific values.
Either the theme reader could be updated to implicitly set known color
variables to empty, or the themes could feature empty values.
See #8787.
fish reads the tty modes at startup, and tries to restore them to the
original values on exit, to be polite. However this causes problems when
fish is run in a pipeline with another process which also messes with the
tty modes. Example:
fish -c 'echo foo' | vim -
Here vim's manipulation of the tty would race with fish, and often vim
would end up with broken modes.
Only restore the tty if we are interactive. Fixes#8705.
This is a big cleanup to how tty transfer works. Recall that when job
control is active, we transfer the tty to jobs via tcsetpgrp().
Previously, transferring was done "as needed" in continue_job. That is, if
we are running a job, and the job wants the terminal and does not have it,
we will transfer the tty at that point.
This got pretty weird when running mixed pipelines. For example:
cmd1 | func1 | cmd2
Here we would run `func1` before calling continue_job. Thus the tty
would be transferred by the nested function invocation, and also restored
by that invocation, potentially racing with tty manipulation from cmd1 or
cmd2.
In the new model, migrate the tty transfer responsibility outside of
continue_job. The caller of continue_job is then responsible for setting up
the tty. There's two places where this gets done:
1. In `exec_job`, where we run a job for the first time.
2. In `builtin_fg` where we continue a stopped job in the foreground.
Fixes#8699
This is a cleanup of job groups, rationalizing a bunch of stuff. Some
notable changes (none user-visible hopefully):
1. Previously, if a job group wanted a pgid, then we would assign it to the
first process to run in the job group. Now we deliberately mark which
process will own the pgroup, via a new `leads_pgrp` flag in process_t. This
eliminates a source of ambiguity.
2. Previously, if a job were run inside fish's pgroup, we would set fish's
pgroup as the group of the job. But this meant we had to check if the job
had fish's pgroup in lots of places, for example when calling tcsetpgrp.
Now a job group only has a pgrp if that pgrp is external (i.e. the job is
under job control).
* Turn on default bindings for --no-config mode
The fallback bindings are super awkward to use.
This was called out specifically in #7921, I'm going for the targeted
fix for now.
* Only change keybindings when interactive
That's also when we'd source them normally.
This tried migrating old abbreviations *twice* - once from the 2.3
scheme to the 2.4 one, and once from that to the 3.0 scheme.
Since this is purely for upgrading from fishes < 3.0, and basically
untested, let's remove it.
If anyone does that upgrade, they'll simply have to reexecute the abbrs.
These were changed in fish 3.0 in December 2018.
This means upgrading from fish 2.7.1 or earlier to the next fish
version will require users to set their universal variable again.
Because we reload changed function files, a common issue on upgrading
to 3.4.0 is that fish_title causes errors.
So we simply use the oldschool syntax.
This just defines a constant to whichever tparm implementation we're
using (either the actual, working one the system provides, or our
kludge to paper over Solaris' inadequacies).
This means that there won't be so much ping-ponging of what "tparm"
stands for. "tparm" is the system's function. Only we don't use it,
just like we don't use wcstod directly.
Fixes#8780
* New -n flag for string join command.
This is an argument that excludes empty result items. Fixes#8351
* New documentation for string-join.
The new argument --no-empty was added at string-join manpage.
* New completions for the new -n flag for string join.
* Remove the documentation of the new -n flag of string join0
The reason to remove this new argument in the join0 is that this flag basically doesn't make any difference in the join0.
* Refactor the validation for the string join.
The string join command was using the length of the argument, this commit changes the validation to use the empty function.
* Revert #4b56ab452
The reason for the revert is thath the build broke on the ubuntu in the Github actions.
* Revert #e72e239a1
The reason the compilation on GitHub broke is that the test was weird, it didn't even run it, Common CI systems are typically very very resource-constrained.
* Resolve conflicts in the string-join.rst.
* Resolve conflicts in the "string-join.rst".
commit #1242d0fd7 not fixed all conflicts.
This is supposed to detect color escape sequences, to figure out how
long an escape sequence is, for use in width calculations.
However, the typical color sequences are already taken care of by
is_csi_style_escape_seq because they look like a csi sequence starting
with `\e[` and ending in `m`.
In the entire terminfo database shipped with ncurses 6.3, these are
the terminals that have non-csi color sequences:
at-color
atari-color
atari_st-color
d220-dg
d230-dg
d230c-dg
d430-dg
d430-unix
d430-unix-25
d430-unix-s
d430-unix-sr
d430-unix-w
d430c-dg
d430c-unix
d430c-unix-25
d430c-unix-s
d430c-unix-sr
d430c-unix-w
d470-dg
d470c-dg
dg+fixed
dgmode+color
dgmode+color8
dgunix+fixed
emu
fbterm
i3164
ibm3164
linux-m1b
linux-m2
minitel1
minitel1b
putty-m1b
putty-m2
st52-color
tt52
tw52
tw52-color
xterm-8bit
Most of these were discontinued in the 90s and their manufacturers no
longer exist (like Data General, which went defunct in 1999). The last one is a special mode for xterm that is
fundamentally UTF-8 incompatible because it encodes a CSI as \X9b.
The linux/putty m1b and m2 entries (also for minitel) don't support
color to begin with and the sequences they have in their terminfo
entries are control characters anyway, so the calculation would still
add up.
In turn, what we gain from this is much faster width calculations with
unrecognized escapes -
e.g. `string length -V \efoo` is sped up by a factor of 20.
An alternative would be to skip this if max_colors is > 16 as that is
the most any of these entries can do. The runtime scales linearly with
the number of colors so on those systems it would be reasonably quick anyway.
But given just *how* outdated these are I believe it is okay to just
remove support outright. I do not believe anyone has ever run fish on
any of these.
* Implement fish_wcstod_underscores
* Add fish_wcstod_underscores unit tests
* Switch to using fish_wcstod_underscores in tinyexpr
* Add tests for math builtin underscore separator functionality
* Add documentation for underscore separators for math builtin
* Add a changelog entry for underscore numeric separators
We can't always read in chunks because we often can't bear to
overread:
```fish
echo foo\nbar | begin
read -l foo
read -l bar
end
```
needs to have the first read read `foo` and the second read `bar`. So
here we can only read one byte at a time.
However, when we are directly redirected:
```fish
echo foo | read foo
```
we can, because the data is only for us anyway. The stream will be
closed after, so anything not read just goes away. Nobody else is
there to read.
This dramatically speeds up `read` of long lines through a pipe. How
much depends on the length of the line.
With lines of 5000 characters it's about 15x, with lines of 50
characters about 2x, lines of 5 characters about 1.07x.
See #8542.
Both constant values and functions are represented as `te_fun_t`.
This struct defines `operator()` which evaluates the function with the
given arguments.
A command like "printf nonewline | sed s/x/y/" does not print a
concluding newline, whereas "printf nnl | string replace x y" does.
This is an edge case -- usually the user input does have a newline at
the end -- but it seems still better for this command to just forward
the user's data.
Teach most string subcommands to check if stdin is missing the trailing
newline, and stop adding one in that case.
This does not apply when input is read from commandline arguments.
* Most subcommands stop adding the final newline, because they don't
really care about newlines, so besides their normal processing,
they just want to preserve user input. They are:
* string collect
* string escape/unescape
* string join¹
* string lower/upper
* string pad
* string replace
* string repeat
* string sub
* string trim
* string match keeps adding the newline, following "grep". Additionally,
for string match --regex, it's important to output capture groups
separated by newlines, resulting in multiple output lines for an
input line. So it is not obvious where to leave out the newline.
* string split/split0 keep adding the newline for the same reason --
they are meant to output multiple elements for a single input line.
¹) string join0 is not changed because it already printed a trailing
zero byte instead of the trailing newline. This is consistent
with other tools like "find -print0".
Closes#3847
2021-11-27 19:11:24 +01:00
793 changed files with 532702 additions and 344731 deletions
-``abbr --erase`` now also erases the universal variables used by the old abbr function. That means::
abbr --erase (abbr --list)
can now be used to clean out all old abbreviations (:issue:`9468`).
-``abbr --add --universal`` now warns about --universal being non-functional, to make it easier to detect old-style ``abbr`` calls (:issue:`9475`).
-``functions --handlers-type caller-exit`` once again lists functions defined as ``function --on-job-exit caller``, rather than them being listed by ``functions --handlers-type process-exit``.
Deprecations and removed features
---------------------------------
Scripting improvements
----------------------
-``abbr --list`` no longer escapes the abbr name, which is necessary to be able to pass it to ``abbr --erase`` (:issue:`9470`).
-``read`` will now print an error if told to set a read-only variable instead of silently doing nothing (:issue:`9346`).
-``functions`` and ``type`` now show where a function was copied and where it originally was instead of saying ``Defined interactively``.
- Stack trace now shows line numbers for copied functions.
Interactive improvements
------------------------
- Using ``fish_vi_key_bindings`` in combination with fish's ``--no-config`` mode works without locking up the shell (:issue:`9443`).
- The history pager now uses more screen space, usually half the screen (:issue:`9458`).
- The history pager now shows fuzzy (subsequence) matches in the absence of exact substring matches (:issue:`9476`).
- Variables that were set while the locale was C (i.e. ASCII) will now properly be encoded if the locale is switched (:issue:`2613`, :issue:`9473`).
- Escape during history search restores the original commandline again (regressed in 3.6.0).
- Using ``--help`` on builtins now respects the $MANPAGER variable in preference to $PAGER (:issue:`9488`).
- Command-specific tab completions may now offer results whose first character is a period. For example, it is now possible to tab-complete ``git add`` for files with leading periods. The default file completions hide these files, unless the token itself has a leading period (:issue:`3707`).
New or improved bindings
^^^^^^^^^^^^^^^^^^^^^^^^
Improved prompts
^^^^^^^^^^^^^^^^
Completions
^^^^^^^^^^^
- Added completions for:
-``otool``
-``mix phx``
-``neovim``
-``stow``
-``trash`` and helper utilities ``trash-empty``, ``trash-list``, ``trash-put``, ``trash-restore``
-``apkanalyzer``
- git's completion for ``git-foo``-style commands was fixed (:issue:`9457`)
- File completion now offers ``../`` and ``./`` again (:issue:`9477`)
Improved terminal support
^^^^^^^^^^^^^^^^^^^^^^^^^
Other improvements
------------------
For distributors
----------------
-*Placeholder to fix Sphinx warning*
--------------
fish 3.6.0 (released January 7, 2023)
=====================================
Notable improvements and fixes
------------------------------
- By default, :kbd:`Control-R` now opens the command history in the pager (:issue:`602`). This is fully searchable and syntax-highlighted, as an alternative to the incremental search seen in other shells. The new special input function ``history-pager`` has been added for custom bindings.
- Abbrevations are more flexible (:issue:`9313`, :issue:`5003`, :issue:`2287`):
- They may optionally replace tokens anywhere on the command line, instead of only commands
- Matching tokens may be described using a regular expression instead of a literal word
- The replacement text may be produced by a fish function, instead of a literal word
- They may position the cursor anywhere in the expansion, instead of at the end
This expands ``..`` to ``cd ../``, ``...`` to ``cd ../../`` and ``....`` to ``cd ../../../`` and so on.
Or::
function last_history_item; echo $history[1]; end
abbr -a !! --position anywhere --function last_history_item
which expands ``!!`` to the last history item, anywhere on the command line, mimicking other shells' history expansion.
See :ref:`the documentation <cmd-abbr>` for more.
-``path`` gained a new ``mtime`` subcommand to print the modification time stamp for files. For example, this can be used to handle cache file ages (:issue:`9057`)::
> touch foo
> sleep 10
> path mtime --relative foo
10
-``string`` gained a new ``shorten`` subcommand to shorten strings to a given visible width (:issue:`9156`)::
> string shorten --max 10 "Hello this is a long string"
Hello thi…
-``test`` (aka ``[``) gained ``-ot`` (older than) and ``-nt`` (newer than) operators to compare file modification times, and ``-ef`` to compare whether the arguments are the same file (:issue:`3589`).
- fish will now mark the extent of many errors with a squiggly line, instead of just a caret (``^``) at the beginning (:issue:`9130`). For example::
- A new function, ``fish_delta``, shows changes that have been made in fish's configuration from the defaults (:issue:`9255`).
-``set --erase`` can now be used with multiple scopes at once, like ``set -efglU foo`` (:issue:`7711`, :issue:`9280`).
-``status`` gained a new subcommand, ``current-commandline``, which retrieves the entirety of the currently-executing command line when called from a function during execution. This allows easier job introspection (:issue:`8905`, :issue:`9296`).
Deprecations and removed features
---------------------------------
- The ``\x`` and ``\X`` escape syntax is now equivalent. ``\xAB`` previously behaved the same as ``\XAB``, except that it would error if the value "AB" was larger than "7f" (127 in decimal, the highest ASCII value) (:issue:`9247`, :issue:`9245`, :issue:`1352`).
- The ``fish_git_prompt`` will now only turn on features if the appropriate variable has been set to a true value (of "1", "yes" or "true") instead of just checking if it is defined. This allows specifically turning features *off* without having to erase variables, such as via universal variables. If you have defined a variable to a different value and expect it to count as true, you need to change it (:issue:`9274`).
For example, ``set -g __fish_git_prompt_show_informative_status 0`` previously would have enabled informative status (because any value would have done so), but now it turns it off.
- Abbreviations are no longer stored in universal variables. Existing universal abbreviations are still imported, but new abbreviations should be added to ``config.fish``.
- The short option ``-r`` for abbreviations has changed from ``rename`` to ``regex``, for consistency with ``string``.
Scripting improvements
----------------------
-``argparse`` can now be used without option specifications, to allow using ``--min-args``, ``--max-args`` or for commands that take no options (but might in future) (:issue:`9006`)::
function my_copy
argparse --min-args 2 -- $argv
or return
cp $argv
end
-``set --show`` now shows when a variable was inherited from fish's parent process, which should help with debugging (:issue:`9029`)::
> set --show XDG_DATA_DIRS
$XDG_DATA_DIRS: set in global scope, exported, a path variable with 4 elements
$XDG_DATA_DIRS: originally inherited as |/home/alfa/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/|
- The read limit is now restored to the default when :envvar:`fish_read_limit` is unset (:issue:`9129`).
-``math`` produces an error for division-by-zero, as well as augmenting some errors with their extent (:issue:`9190`). This changes behavior in some limited cases, such as::
math min 1 / 0, 5
which would previously print "5" (because in floating point division "1 / 0" yields infinite, and 5 is smaller than infinite) but will now return an error.
-``fish_clipboard_copy`` and ``fish_clipboard_paste`` can now be used in pipes (:issue:`9271`)::
git rev-list 3.5.1 | fish_clipboard_copy
fish_clipboard_paste | string join + | math
-``status fish-path`` returns a fully-normalised path, particularly noticeable on NetBSD (:issue:`9085`).
Interactive improvements
------------------------
- If the terminal definition for :envvar:`TERM` can't be found, fish now tries using the "xterm-256color" and "xterm" definitions before "ansi" and "dumb". As the majority of terminal emulators in common use are now more or less xterm-compatible (often even explicitly claiming the xterm-256color entry), this should often result in a fully or almost fully usable terminal (:issue:`9026`).
- A new variable, :envvar:`fish_cursor_selection_mode`, can be used to configure whether the command line selection includes the character under the cursor (``inclusive``) or not (``exclusive``). The new default is ``exclusive``; use ``set fish_cursor_selection_mode inclusive`` to get the previous behavior back (:issue:`7762`).
- fish's completion pager now fills half the terminal on first tab press instead of only 4 rows, which should make results visible more often and save key presses, without constantly snapping fish to the top of the terminal (:issue:`9105`, :issue:`2698`).
- The ``complete-and-search`` binding, used with :kbd:`Shift-Tab` by default, selects the first item in the results immediately (:issue:`9080`).
-``bind`` output is now syntax-highlighted when used interacively.
-:kbd:`Alt-H` (the default ``__fish_man_page`` binding) does a better job of showing the manual page of the command under cursor (:issue:`9020`).
- If :envvar:`fish_color_valid_path` contains an actual color instead of just modifiers, those will be used for valid paths even if the underlying color isn't "normal" (:issue:`9159`).
- The key combination for the QUIT terminal sequence, often :kbd:`Control-Backslash` (``\x1c``), can now be sused as a binding (:issue:`9234`).
- fish's vi mode uses normal xterm-style sequences to signal cursor change, instead of using the iTerm's proprietary escape sequences. This allows for a blinking cursor and makes it work in complicated scenarios with nested terminals. (:issue:`3741`, :issue:`9172`)
- When running fish on a remote system (such as inside SSH or a container), :kbd:`Control-X` now copies to the local client system's clipboard if the terminal supports OSC 52.
-``commandline`` gained two new options, ``--selection-start`` and ``--selection-end``, to set the start/end of the current selection (:issue:`9197`, :issue:`9215`).
- fish's builtins now handle keyboard interrupts (:kbd:`Control-C`) correctly (:issue:`9266`).
Completions
^^^^^^^^^^^
- Added completions for:
-``ark``
-``asciinema`` (:issue:`9257`)
-``clojure`` (:issue:`9272`)
-``csh``
-``direnv`` (:issue:`9268`)
-``dive`` (:issue:`9082`)
-``dolphin``
-``dua`` (:issue:`9277`)
-``efivar`` (:issue:`9318`)
-``eg``
-``es`` (:issue:`9388`)
-``firefox-developer-edition`` and ``firefox`` (:issue:`9090`)
-``fortune`` (:issue:`9177`)
-``kb``
-``kind`` (:issue:`9110`)
-``konsole``
-``ksh``
-``loadkeys`` (:issue:`9312`)
-``okular``
-``op`` (:issue:`9300`)
-``ouch`` (:issue:`9405`)
-``pix``
-``readelf`` (:issue:`8746`, :issue:`9386`)
-``qshell``
-``rc``
-``sad`` (:issue:`9145`)
-``tcsh``
-``toot``
-``tox`` (:issue:`9078`)
-``wish``
-``xed``
-``xonsh`` (:issue:`9389`)
-``xplayer``
-``xreader``
-``xviewer``
-``yash`` (:issue:`9391`)
-``zig`` (:issue:`9083`)
- Improvements to many completions, including making ``cd`` completion much faster (:issue:`9220`).
- Completion of tilde (``~``) works properly even when the file name contains an escaped character (:issue:`9073`).
- fish no longer loads completions if the command is used via a relative path and is not in :envvar:`PATH` (:issue:`9133`).
- fish no longer completes inside of comments (:issue:`9320`).
Improved terminal support
^^^^^^^^^^^^^^^^^^^^^^^^^
- Opening ``help`` on WSL now uses PowerShell to open the browser if available, removing some awkward UNC path errors (:issue:`9119`).
Other improvements
------------------
- The Web-based configuration tool now works on systems with IPv6 disabled (:issue:`3857`).
- Aliases can ignore arguments by ending them with ``#`` (:issue:`9199`).
-``string`` is now faster when reading large strings from stdin (:issue:`9139`).
-``string repeat`` uses less memory and is faster. (:issue:`9124`)
- Builtins are much faster when writing to a pipe or file. (:issue:`9229`).
- Performance improvements to highlighting (:issue:`9180`) should make using fish more pleasant on slow systems.
- On 32-bit systems, globs like ``*`` will no longer fail to return some files, as large file support has been enabled.
Fixed bugs
----------
- The history search text for a token search is now highlighted correctly if the line contains multiple instances of that text (:issue:`9066`).
-``process-exit`` and ``job-exit`` events are now generated for all background jobs, including those launched from event handlers (:issue:`9096`).
- A crash when completing a token that contained both a potential glob and a quoted variable expansion was fixed (:issue:`9137`).
-``prompt_pwd`` no longer accidentally overwrites a global or universal ``$fish_prompt_pwd_full_dirs`` when called with the ``-d`` or ``--full-length-dirs`` option (:issue:`9123`).
- A bug which caused fish to freeze or exit after running a command which does not preserve the foreground process group was fixed (:issue:`9181`).
- The "Disco" sample prompt no longer prints an error in some working directories (:issue:`9164`). If you saved this prompt, you should run ``fish_config prompt save disco`` again.
- fish launches external commands via the given path again, rather than always using an absolute path. This behaviour was inadvertently changed in 3.5.0 and is visible, for example, when launching a bash script which checks ``$0`` (:issue:`9143`).
-``printf`` no longer tries to interpret the first argument as an option (:issue:`9132`).
- Interactive ``read`` in scripts will now have the correct keybindings again (:issue:`9227`).
- A possible stack overflow when recursively evaluating substitutions has been fixed (:issue:`9302`).
- A crash with relative $CDPATH has been fixed (:issue:`9407`).
-``printf`` now properly fills extra ``%d`` specifiers with 0 even on macOS and BSD (:issue:`9321`).
-``fish_key_reader`` now correctly exits when receiving a SIGHUP (like after closing the terminal) (:issue:`9309`).
-``fish_config theme save`` now works as documented instead of erroring out (:issue:`9088`, :issue:`9273`).
- fish no longer triggers prompts to install command line tools when first run on macOS (:issue:`9343`).
-``fish_git_prompt`` now quietly fails on macOS if the xcrun cache is not yet populated (:issue:`6625`), working around a potential hang.
For distributors
----------------
- The vendored PCRE2 sources have been removed. It is recommended to declare PCRE2 as a dependency when packaging fish. If the CMake variable FISH_USE_SYSTEM_PCRE2 is false, fish will now download and build PCRE2 from the official repo (:issue:`8355`, :issue:`8363`). Note this variable defaults to true if PCRE2 is found installed on the system.
--------------
fish 3.5.1 (released July 20, 2022)
===================================
This release of fish introduces the following small enhancements:
- Cursor shaping for Vi mode is enabled by default in tmux, and will be used if the outer terminal is capable (:issue:`8981`).
-``printf`` returns a better error when used with arguments interpreted as octal numbers (:issue:`9035`).
-``history merge`` when in private mode is now an error, rather than wiping out other sessions' history (:issue:`9050`).
- The error message when launching a command that is built for the wrong architecture on macOS is more helpful (:issue:`9052`).
- Added completions for:
-``choose`` (:issue:`9065`)
-``expect`` (:issue:`9060`)
-``navi`` (:issue:`9064`)
-``qdbus`` (:issue:`9031`)
-``reflector`` (:issue:`9027`)
- Improvements to some completions.
This release also fixes a number of problems identified in fish 3.5.0.
- Completing ``git blame`` or ``git -C`` works correctly (:issue:`9053`).
- On terminals that emit a ``CSI u`` sequence for :kbd:`Shift-Space`, fish inserts a space instead of printing an error. (:issue:`9054`).
-``status fish-path`` on Linux-based platforms could print the path with a " (deleted)" suffix (such as ``/usr/bin/fish (deleted)``), which is now removed (:issue:`9019`).
- Cancelling an initial command (from fish's ``--init-command`` option) with :kbd:`Control-C` no longer prevents configuration scripts from running (:issue:`9024`).
- The job summary contained extra blank lines if the prompt used multiple lines, which is now fixed (:issue:`9044`).
- Using special input functions in bindings, in combination with ``and``/``or`` conditionals, no longer crashes (:issue:`9051`).
--------------
fish 3.5.0 (released June 16, 2022)
===================================
Notable improvements and fixes
------------------------------
- A new ``path`` builtin command to filter and transform paths (:issue:`7659`, :issue:`8958`). For example, to list all the separate extensions used on files in /usr/share/man (after removing one extension, commonly a ".gz")::
- Tab (or any key bound to ``complete``) now expands wildcards instead of invoking completions, if there is a wildcard in the path component under the cursor (:issue:`954`, :issue:`8593`).
- Scripts can now catch and handle the SIGINT and SIGTERM signals, either via ``function --on-signal`` or with ``trap`` (:issue:`6649`).
Deprecations and removed features
---------------------------------
- The ``stderr-nocaret`` feature flag, introduced in fish 3.0 and enabled by default in fish 3.1, has been made read-only.
That means it is no longer possible to disable it, and code supporting the ``^`` redirection has been removed (:issue:`8857`, :issue:`8865`).
To recap: fish used to support ``^`` to redirect stderr, so you could use commands like::
test "$foo" -gt 8 ^/dev/null
to ignore error messages. This made the ``^`` symbol require escaping and quoting, and was a bit of a weird shortcut considering ``2>`` already worked, which is only one character longer.
So the above can simply become::
test "$foo" -gt 8 2>/dev/null
- The following feature flags have been enabled by default:
-``regex-easyesc``, which makes ``string replace -r`` not do a superfluous round of unescaping in the replacement expression.
That means e.g. to escape any "a" or "b" in an argument you can use ``string replace -ra '([ab])' '\\\\$1' foobar`` instead of needing 8 backslashes.
This only affects the *replacement* expression, not the *match* expression (the ``'([ab])'`` part in the example).
A survey of plugins on GitHub did not turn up any affected code, so we do not expect this to affect many users.
This flag was introduced in fish 3.1.
-``ampersand-nobg-in-token``, which means that ``&`` will not create a background job if it occurs in the middle of a word. For example, ``echo foo&bar`` will print "foo&bar" instead of running ``echo foo`` in the background and then starting ``bar`` as a second job.
Reformatting with ``fish_indent`` would already introduce spaces, turning ``echo foo&bar`` into ``echo foo & bar``.
This flag was introduced in fish 3.4.
To turn off these flags, add ``no-regex-easyesc`` or ``no-ampersand-nobg-in-token`` to :envvar:`fish_features` and restart fish::
set -Ua fish_features no-regex-easyesc
Like ``stderr-nocaret``, they will eventually be made read-only.
- Most ``string`` subcommands no longer append a newline to their input if the input didn't have one (:issue:`8473`, :issue:`3847`)
- Fish's escape sequence removal (like for ``string length --visible`` or to figure out how wide the prompt is) no longer has special support for non-standard color sequences like from Data General terminals, e.g. the Data General Dasher D220 from 1984. This removes a bunch of work in the common case, allowing ``string length --visible`` to be much faster with unknown escape sequences. We don't expect anyone to have ever used fish with such a terminal (:issue:`8769`).
- Code to upgrade universal variables from fish before 3.0 has been removed. Users who upgrade directly from fish versions 2.7.1 or before will have to set their universal variables & abbreviations again. (:issue:`8781`)
- The meaning of an empty color variable has changed (:issue:`8793`). Previously, when a variable was set but empty, it would be interpreted as the "normal" color. Now, empty color variables cause the same effect as unset variables - the general highlighting variable for that type is used instead. For example::
set -g fish_color_command blue
set -g fish_color_keyword
would previously make keywords "normal" (usually white in a dark terminal). Now it'll make them blue. To achieve the previous behavior, use the normal color explicitly: ``set -g fish_color_keyword normal``.
This makes it easier to make self-contained color schemes that don't accidentally use color that was set before.
``fish_config`` has been adjusted to set known color variables that a theme doesn't explicitly set to empty.
-``eval`` is now a reserved keyword, so it can't be used as a function name. This follows ``set`` and ``read``, and is necessary because it can't be cleanly shadowed by a function - at the very least ``eval set -l argv foo`` breaks. Fish will ignore autoload files for it, so left over ``eval.fish`` from previous fish versions won't be loaded.
- The git prompt in informative mode now defaults to skipping counting untracked files, as this was extremely slow. To turn it on, set :envvar:`__fish_git_prompt_showuntrackedfiles` or set the git config value "bash.showuntrackedfiles" to ``true`` explicitly (which can be done for individual repositories). The "informative+vcs" sample prompt already skipped display of untracked files, but didn't do so in a way that skipped the computation, so it should be quite a bit faster in many cases (:issue:`8980`).
- The ``__terlar_git_prompt`` function, used by the "Terlar" sample prompt, has been rebuilt as a configuration of the normal ``fish_git_prompt`` to ease maintenance, improve performance and add features (like reading per-repo git configuration). Some slight changes remain; users who absolutely must have the same behavior are encouraged to copy the old function (:issue:`9011`, :issue:`7918`, :issue:`8979`).
Scripting improvements
----------------------
- Quoted command substitution that directly follow a variable expansion (like ``echo "$var$(echo x)"``) no longer affect the variable expansion (:issue:`8849`).
- Fish now correctly expands command substitutions that are preceded by an escaped dollar (like ``echo \$(echo)``). This regressed in version 3.4.0.
-``math`` can now handle underscores (``_``) as visual separators in numbers (:issue:`8611`, :issue:`8496`)::
math 5 + 2_123_252
-``math``'s ``min`` and ``max`` functions now take a variable number of arguments instead of always requiring 2 (:issue:`8644`, :issue:`8646`)::
> math min 8,2,4
2
-``read`` is now faster as the last process in a pipeline (:issue:`8552`).
-``string join`` gained a new ``--no-empty`` flag to skip empty arguments (:issue:`8774`, :issue:`8351`).
-``read`` now only triggers the ``fish_read`` event, not the ``fish_prompt`` event (:issue:`8797`). It was supposed to work this way in fish 3.2.0 and later, but both events were emitted.
- The TTY modes are no longer restored when non-interactive shells exit. This fixes wrong tty modes in pipelines with interactive commands. (:issue:`8705`).
- Some functions shipped with fish printed error messages to standard output, but they now they rightly go to standard error (:issue:`8855`).
-``jobs`` now correctly reports CPU usage as a percentage, instead of as a number of clock ticks (:issue:`8919`).
-``process-exit`` events now fire when the process exits even if the job has not yet exited, fixing a regression in 3.4.1 (:issue:`8914`).
Interactive improvements
------------------------
- Fish now reports a special error if a command wasn't found and there is a non-executable file by that name in :envvar:`PATH` (:issue:`8804`).
-``less`` and other interactive commands would occasionally be stopped when run in a pipeline with fish functions; this has been fixed (:issue:`8699`).
- Case-changing autosuggestions generated mid-token now correctly append only the suffix, instead of duplicating the token (:issue:`8820`).
-``ulimit`` learned a number of new options for the resource limits available on Linux, FreeBSD ande NetBSD, and returns a specific warning if the limit specified is not available on the active operating system (:issue:`8823`, :issue:`8786`).
- The ``vared`` command can now successfully edit variables named "tmp" or "prompt" (:issue:`8836`, :issue:`8837`).
-``time`` now emits an error if used after the first command in a pipeline (:issue:`8841`).
-``fish_add_path`` now prints a message for skipped non-existent paths when using the ``-v`` flag (:issue:`8884`).
- Since fish 3.2.0, pressing :kbd:`Control-D` while a command is running would end up inserting a space into the next commandline, which has been fixed (:issue:`8871`).
- A bug that caused multi-line prompts to be moved down a line when pasting or switching modes has been fixed (:issue:`3481`).
- The Web-based configuration system no longer strips too many quotes in the abbreviation display (:issue:`8917`, :issue:`8918`).
- Fish started with ``--no-config`` will now use the default keybindings (:issue:`8493`)
- When fish inherits a :envvar:`USER` environment variable value that doesn't correspond to the current effective user ID, it will now correct it in all cases (:issue:`8879`, :issue:`8583`).
- Fish sets a new :envvar:`EUID` variable containing the current effective user id (:issue:`8866`).
-``history search`` no longer interprets the search term as an option (:issue:`8853`)
- The status message when a job terminates should no longer be erased by a multiline prompt (:issue:`8817`)
New or improved bindings
^^^^^^^^^^^^^^^^^^^^^^^^
- The :kbd:`Alt-S` binding will now insert ``doas`` instead of ``sudo`` if necessary (:issue:`8942`).
- The ``kill-whole-line`` special input function now kills the newline preceeding the last line. This makes ``dd`` in vi-mode clear the last line properly.
- The new ``kill-inner-line`` special input function kills the line without any newlines, allowing ``cc`` in vi-mode to clear the line while preserving newlines (:issue:`8983`).
- On terminals that emit special sequences for these combinations, :kbd:`Shift-Space` is bound like :kbd:`Space`, and :kbd:`Ctrl-Return` is bound like :kbd:`Return` (:issue:`8874`).
Improved prompts
^^^^^^^^^^^^^^^^
- A new ``Astronaut`` prompt (:issue:`8775`), a multi-line prompt using plain text reminiscent of the Starship.rs prompt.
Completions
^^^^^^^^^^^
- Added completions for:
-``archlinux-java`` (:issue:`8911`)
-``apk`` (:issue:`8951`)
-``brightnessctl`` (:issue:`8758`)
-``efibootmgr`` (:issue:`9010`)
-``fastboot`` (:issue:`8904`)
-``optimus-manager`` (:issue:`8913`)
-``rclone`` (:issue:`8819`)
-``sops`` (:issue:`8821`)
-``tuned-adm`` (:issue:`8760`)
-``wg-quick`` (:issue:`8687`)
-``complete`` can now be given multiple ``--condition`` options. They will be attempted in the order they were given, and only if all succeed will the completion be made available (as if they were connected with ``&&``). This helps with caching - fish's complete system stores the return value of each condition as long as the commandline doesn't change, so this can reduce the number of conditions that need to be evaluated (:issue:`8536`, :issue:`8967`).
Improved terminal support
^^^^^^^^^^^^^^^^^^^^^^^^^
- Working directory reporting is enabled for kitty (:issue:`8806`).
- Changing the cursor shape is now enabled by default in iTerm2 (:issue:`3696`).
For distributors
----------------
- libatomic is now correctly detected as necessary when building on RISC-V (:issue:`8850`, :issue:`8851`).
- In some cases, the build process found the wrong libintl on macOS. This has been corrected (:issue:`5244`).
- The paths for completions, functions, and configuration snippets now include
subdirectories ``fish/vendor_completions.d``, ``fish/vendor_functions.d``, and
``fish/vendor_conf.d`` (respectively) within ``XDG_DATA_HOME`` (or ``~/.local/share``
if not defined) (:issue:`8887`, :issue:`7816`).
--------------
fish 3.4.1 (released March 25, 2022)
====================================
@@ -1749,6 +2189,7 @@ Interactive improvements
key both on its own and as part of a control sequence, was applied to
all control characters; this has been reduced to just the escape key.
- Completing a function shows the description properly (:issue:`5206`).
-`commandline` can now be used to set the commandline for the next command, restoring a behavior in 3.4.1 (:issue:`8807`).
- Added completions for
-``ansible``, including ``ansible-galaxy``, ``ansible-playbook``
- Be conservative in what you need (``C++11``, few dependencies)
- Use automated tools to help you (including ``make test``, ``build_tools/style.fish`` and ``make lint``)
General
-------
Contributing completions
------------------------
Completion scripts are the most common contribution to fish, and they are very welcome.
In general, we'll take all well-written completion scripts for a command that is publically available.
This means no private tools or personal scripts, and we do reserve the right to reject for other reasons.
Before you try to contribute them to fish, consider if the authors of the tool you are completing want to maintain the script instead.
Often that makes more sense, specifically because they can add new options to the script immediately once they add them,
and don't have to maintain one completion script for multiple versions. If the authors no longer wish to maintain the script,
they can of course always contact the fish maintainers to hand it over, preferably by opening a PR.
This isn't a requirement - if the authors don't want to maintain it, or you simply don't want to contact them,
you can contribute your script to fish.
Completion scripts should
1. Use as few dependencies as possible - try to use fish's builtins like ``string`` instead of ``grep`` and ``awk``,
use ``python`` to read json instead of ``jq`` (because it's already a soft dependency for fish's tools)
2. If it uses a common unix tool, use posix-compatible invocations - ideally it would work on GNU/Linux, macOS, the BSDs and other systems
3. Option and argument descriptions should be kept short.
The shorter the description, the more likely it is that fish can use more columns.
4. Function names should start with ``__fish``, and functions should be kept in the completion file unless they're used elsewhere.
5. Run ``fish_indent`` on your script.
6. Try not to use minor convenience features right after they are available in fish - we do try to keep completion scripts backportable.
If something has a real impact on the correctness or performance, feel free to use it,
but if it is just a shortcut, please leave it.
Put your completion script into share/completions/name-of-command.fish. If you have multiple commands, you need multiple files.
If you want to add tests, you probably want to add a littlecheck test. See below for details.
Contributing to fish's C++ core
-------------------------------
Fish uses C++11. Newer C++ features should not be used to make it possible to use on older systems.
@@ -21,37 +53,23 @@ Don't introduce new dependencies unless absolutely necessary, and if you do,
please make it optional with graceful failure if possible.
Add any new dependencies to the README.rst under the *Running* and/or *Building* sections.
This also goes for completion scripts and functions - if at all possible, they should only use
POSIX-compatible invocations of any tools, and no superfluous dependencies.
Linters
-------
E.g. some completions deal with JSON data. In those it's preferable to use python to handle it,
as opposed to ``jq``, because fish already optionally uses python elsewhere. (It also happens to be quite a bit *faster*)
Lint Free Code
--------------
Automated analysis tools like cppcheck and oclint can point out
Automated analysis tools like cppcheck can point out
potential bugs or code that is extremely hard to understand. They also
help ensure the code has a consistent style and that it avoids patterns
that tend to confuse people.
To make linting the code easy there are two make targets: ``lint`` and
``lint-all``. The latter does exactly what the name implies. The former
will lint any modified but not committed ``*.cpp`` files. If there is no
uncommitted work it will lint the files in the most recent commit.
To make linting the code easy there are two make targets: ``lint``,
to lint any modified but not committed ``*.cpp`` files, and
``lint-all`` to lint all files.
Fish has custom cppcheck rules in the file ``.cppcheck.rule``. These
help catch mistakes such as using ``wcwidth()`` rather than
``fish_wcwidth()``. Please add a new rule if you find similar mistakes
being made.
Dealing With Lint Warnings
~~~~~~~~~~~~~~~~~~~~~~~~~~
You are strongly encouraged to address a lint warning by refactoring the
code, changing variable names, or whatever action is implied by the
warning.
Suppressing Lint Warnings
~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -73,24 +91,20 @@ following:
[src/complete.cpp:1727]: warning (nullPointerRedundantCheck): Either the condition 'cmd_node' is redundant or there is possible null pointer dereference: cmd_node.
Suppressing oclint warnings is more complicated to describe so I’ll
``abbr`` manages abbreviations - user-defined words that are replaced with longer phrases after they are entered.
``abbr`` manages abbreviations - user-defined words that are replaced with longer phrases when entered.
..note::
Only typed-in commands use abbreviations. Abbreviations are not expanded in scripts.
For example, a frequently-run command like ``git checkout`` can be abbreviated to ``gco``.
After entering ``gco`` and pressing :kbd:`Space` or :kbd:`Enter`, the full text ``git checkout`` will appear in the command line.
To avoid expanding something that looks like an abbreviation, the default :kbd:`Control`\ +\ :kbd:`Space` binding inserts a space without expanding.
Options
-------
An abbreviation may match a literal word, or it may match a pattern given by a regular expression. When an abbreviation matches a word, that word is replaced by new text, called its *expansion*. This expansion may be a fixed new phrase, or it can be dynamically created via a fish function. This expansion occurs after pressing space or enter.
The following options are available:
Combining these features, it is possible to create custom syntaxes, where a regular expression recognizes matching tokens, and the expansion function interprets them. See the `Examples`_ section.
**-a***WORD**EXPANSION* or **--add***WORD**EXPANSION*
Adds a new abbreviation, causing *WORD* to be expanded to *EXPANSION*
..versionchanged:: 3.6.0
Previous versions of this allowed saving abbreviations in universal variables.
That's no longer possible. Existing variables will still be imported and ``abbr --erase`` will also erase the variables.
We recommend adding abbreviations to :ref:`config.fish <configuration>` by just adding the ``abbr --add`` command.
When you run ``abbr``, you will see output like this
**-r***OLD_WORD**NEW_WORD* or **--rename***OLD_WORD**NEW_WORD*
Renames an abbreviation, from *OLD_WORD* to *NEW_WORD*
::
**-s** or **--show**
Show all abbreviations in a manner suitable for import and export
> abbr
abbr -a -- foo bar # imported from a universal variable, see `help abbr`
**-l** or **--list**
Lists all abbreviated words
In that case you should take the part before the ``#`` comment and save it in :ref:`config.fish <configuration>`,
then you can run ``abbr --erase`` to remove the universal variable::
**-e***WORD* or **--erase***WORD* ...
Erase the given abbreviations
> abbr >> ~/.config/fish/config.fish
> abbr --erase (abbr --list)
**-q** or **--query**
Return 0 (true) if one of the *WORD* is an abbreviation.
"add" subcommand
--------------------
**-h** or **--help**
Displays help about using this command.
..synopsis::
In addition, when adding or renaming abbreviations, one of the following **SCOPE** options can be used:
``abbr --add`` creates a new abbreviation. With no other options, the string **NAME** is replaced by **EXPANSION**.
**-U** or **--universal**
Use a universal variable (default)
With **--position command**, the abbreviation will only expand when it is positioned as a command, not as an argument to another command. With **--position anywhere** the abbreviation may expand anywhere in the command line. The default is **command**.
With **--regex**, the abbreviation matches using the regular expression given by **PATTERN**, instead of the literal **NAME**. The pattern is interpreted using PCRE2 syntax and must match the entire token. If multiple abbreviations match the same token, the last abbreviation added is used.
With **--set-cursor=MARKER**, the cursor is moved to the first occurrence of **MARKER** in the expansion. The **MARKER** value is erased. The **MARKER** may be omitted (i.e. simply ``--set-cursor``), in which case it defaults to ``%``.
With **-f FUNCTION** or **--function FUNCTION**, **FUNCTION** is treated as the name of a fish function instead of a literal replacement. When the abbreviation matches, the function will be called with the matching token as an argument. If the function's exit status is 0 (success), the token will be replaced by the function's output; otherwise the token will be left unchanged. No **EXPANSION** may be given separately.
See the "Internals" section for more on them.
Examples
--------
########
::
abbr -a -g gco git checkout
abbr --add gco git checkout
Add a new abbreviation where ``gco`` will be replaced with ``git checkout`` global to the current shell.
This abbreviation will not be automatically visible to other shells unless the same command is run in those shells (such as when executing the commands in config.fish).
Add a new abbreviation where ``gco`` will be replaced with ``git checkout``.
::
abbr -a -U l less
abbr -a --position anywhere -- -C --color
Add a new abbreviation where ``l`` will be replaced with ``less`` universal to all shells.
Note that you omit the **-U** since it is the default.
Add a new abbreviation where ``-C`` will be replaced with ``--color``. The ``--`` allows ``-C`` to be treated as the name of the abbreviation, instead of an option.
::
abbr -r gco gch
abbr -a L --position anywhere --set-cursor "% | less"
Add a new abbreviation where ``L`` will be replaced with ``| less``, placing the cursor before the pipe.
Renames an existing abbreviation from ``gco`` to ``gch``.
::
abbr -e gco
function last_history_item
echo $history[1]
end
abbr -a !! --position anywhere --function last_history_item
Erase the ``gco`` abbreviation.
This first creates a function ``last_history_item`` which outputs the last entered command. It then adds an abbreviation which replaces ``!!`` with the result of calling this function. Taken together, this is similar to the ``!!`` history expansion feature of bash.
::
ssh another_host abbr -s | source
function vim_edit
echo vim $argv
end
abbr -a vim_edit_texts --position command --regex ".+\.txt" --function vim_edit
Import the abbreviations defined on another_host over SSH.
This first creates a function ``vim_edit`` which prepends ``vim`` before its argument. It then adds an abbreviation which matches commands ending in ``.txt``, and replaces the command with the result of calling this function. This allows text files to be "executed" as a command to open them in vim, similar to the "suffix alias" feature in zsh.
Internals
---------
Each abbreviation is stored in its own global or universal variable.
The name consists of the prefix ``_fish_abbr_`` followed by the WORD after being transformed by ``string escape style=var``.
The WORD cannot contain a space but all other characters are legal.
::
abbr 4DIRS --set-cursor=! "$(string join \n -- 'for dir in */' 'cd $dir' '!' 'cd ..' 'end')"
This creates an abbreviation "4DIRS" which expands to a multi-line loop "template." The template enters each directory and then leaves it. The cursor is positioned ready to enter the command to run in each directory, at the location of the ``!``, which is itself erased.
Other subcommands
--------------------
::
abbr --rename OLD_NAME NEW_NAME
Renames an abbreviation, from *OLD_NAME* to *NEW_NAME*
::
abbr [-s | --show]
Show all abbreviations in a manner suitable for import and export
::
abbr [-l | --list]
Prints the names of all abbreviation
::
abbr [-e | --erase] NAME
Erases the abbreviation with the given name
::
abbr -q or --query [NAME...]
Return 0 (true) if one of the *NAME* is an abbreviation.
::
abbr -h or --help
Displays help for the `abbr` command.
Abbreviations created with the **--universal** flag will be visible to other fish sessions, whilst **--global** will be limited to the current session.
``alias`` is a simple wrapper for the ``function`` builtin, which creates a function wrapping a command. It has similar syntax to POSIX shell ``alias``. For other uses, it is recommended to define a :ref:`function <cmd-function>`.
``alias`` is a simple wrapper for the ``function`` builtin, which creates a function wrapping a command. It has similar syntax to POSIX shell ``alias``. For other uses, it is recommended to define a :doc:`function <function>`.
If you want to ease your interactive use, to save typing, consider using an :doc:`abbreviation <abbr>` instead.
``fish`` marks functions that have been created by ``alias`` by including the command used to create them in the function description. You can list ``alias``-created functions by running ``alias`` without arguments. They must be erased using ``functions -e``.
@@ -31,7 +33,7 @@ The following options are available:
Displays help about using this command.
**-s** or **--save**
Saves the function created by the alias into your fish configuration directory using :ref:`funcsave <cmd-funcsave>`.
Saves the function created by the alias into your fish configuration directory using :doc:`funcsave <funcsave>`.
Example
-------
@@ -55,6 +57,6 @@ The following code will create ``rmi``, which runs ``rm`` with additional argume
See more
--------
1. The :ref:`function <cmd-function>` command this builds on.
1. The :doc:`function <function>` command this builds on.
``and`` is used to execute a command if the previous command was successful (returned a status of 0).
``and`` statements may be used as part of the condition in an :ref:`while <cmd-while>` or :ref:`if <cmd-if>` block.
``and`` statements may be used as part of the condition in an :doc:`while <while>` or :doc:`if <if>` block.
``and`` does not change the current exit status itself, but the command it runs most likely will. The exit status of the last foreground command to exit can always be accessed using the :ref:`$status <variables-status>` variable.
@@ -33,5 +33,5 @@ The following code runs the ``make`` command to build a program. If the build su
@@ -64,10 +64,11 @@ If ``$argv`` is empty then there is nothing to parse and ``argparse`` returns ze
The ``or return`` means that the function returns ``argparse``'s status if it failed, so if it goes on ``argparse`` succeeded.
The ``--`` argument is required. You do not have to include any arguments after the ``--`` but you must include the ``--``. For example, this is acceptable::
The ``--`` argument is required. You do not have to include any option specifications or arguments after the ``--`` but you must include the ``--``. For example, this is acceptable::
set -l argv
set -l argv foo
argparse 'h/help' 'n/name' -- $argv
argparse --min-args=1 -- $argv
But this is not::
@@ -97,7 +98,7 @@ Each option specification consists of:
- Optionally a ``!`` followed by fish script to validate the value. Typically this will be a function to run. If the exit status is zero the value for the flag is valid. If non-zero the value is invalid. Any error messages should be written to stdout (not stderr). See the section on :ref:`Flag Value Validation <flag-value-validation>` for more information.
See the :ref:`fish_opt <cmd-fish_opt>` command for a friendlier but more verbose way to create option specifications.
See the :doc:`fish_opt <fish_opt>` command for a friendlier but more verbose way to create option specifications.
If a flag is not seen when parsing the arguments then the corresponding _flag_X var(s) will not be set.
@@ -162,14 +163,25 @@ The script should write any error messages to stdout, not stderr. It should retu
Fish ships with a ``_validate_int`` function that accepts a ``--min`` and ``--max`` flag. Let's say your command accepts a ``-m`` or ``--max`` flag and the minimum allowable value is zero and the maximum is 5. You would define the option like this: ``m/max=!_validate_int --min 0 --max 5``. The default if you just call ``_validate_int`` without those flags is to simply check that the value is a valid integer with no limits on the min or max value allowed.
-``h/help`` means that both ``-h`` and ``--help`` are valid. The flag is a boolean and can be used more than once. If either flag is used then ``_flag_h`` and ``_flag_help`` will be set to the count of how many times either flag was seen.
-``h/help`` means that both ``-h`` and ``--help`` are valid. The flag is a boolean and can be used more than once. If either flag is used then ``_flag_h`` and ``_flag_help`` will be set to however either flag was seen, as many times as it was seen. So it could be set to ``-h``, ``-h`` and ``--help``, and ``count $_flag_h`` would yield "3".
-``help`` means that only ``--help`` is valid. The flag is a boolean and can be used more than once. If it is used then ``_flag_help`` will be set to the count of how many times the long flag was seen. Also ``h-help`` (with an arbitrary short letter) for backwards compatibility.
-``help`` means that only ``--help`` is valid. The flag is a boolean and can be used more than once. If it is used then ``_flag_help`` will be set as above. Also ``h-help`` (with an arbitrary short letter) for backwards compatibility.
-``longonly=`` is a flag ``--longonly`` that requires an option, there is no short flag or even short flag variable.
@@ -179,7 +191,7 @@ Some *OPTION_SPEC* examples:
-``name=+`` means that only ``--name`` is valid. It requires a value and can be used more than once. If the flag is seen then ``_flag_name`` will be set with the values associated with each occurrence.
-``x`` means that only ``-x`` is valid. It is a boolean that can be used more than once. If it is seen then ``_flag_x`` will be set to the count of how many times the flag was seen.
-``x`` means that only ``-x`` is valid. It is a boolean that can be used more than once. If it is seen then ``_flag_x`` will be set as above.
-``x=``, ``x=?``, and ``x=+`` are similar to the n/name examples above but there is no long flag alternative to the short flag ``-x``.
A background job is executed simultaneously with fish, and does not have access to the keyboard. If no job is specified, the last job to be used is put in the background. If ``PID`` is specified, the jobs containing the specified process IDs are put in the background.
For compatibility with other shells, job expansion syntax is supported for ``bg``. A PID of the format ``%1`` will be interpreted as the PID of job 1. Job numbers can be seen in the output of :ref:`jobs <cmd-jobs>`.
For compatibility with other shells, job expansion syntax is supported for ``bg``. A PID of the format ``%1`` will be interpreted as the PID of job 1. Job numbers can be seen in the output of :doc:`jobs <jobs>`.
When at least one of the arguments isn't a valid job specifier,
``bg`` will print an error without backgrounding anything.
@@ -27,21 +27,21 @@ The generic key binding that matches if no other binding does can be set by spec
If the ``-k`` switch is used, the name of a key (such as 'down', 'up' or 'backspace') is used instead of a sequence. The names used are the same as the corresponding curses variables, but without the 'key\_' prefix. (See ``terminfo(5)`` for more information, or use ``bind --key-names`` for a list of all available named keys). Normally this will print an error if the current ``$TERM`` entry doesn't have a given key, unless the ``-s`` switch is given.
To find out what sequence a key combination sends, you can use :ref:`fish_key_reader <cmd-fish_key_reader>`.
To find out what sequence a key combination sends, you can use :doc:`fish_key_reader <fish_key_reader>`.
``COMMAND`` can be any fish command, but it can also be one of a set of special input functions. These include functions for moving the cursor, operating on the kill-ring, performing tab completion, etc. Use ``bind --function-names`` for a complete list of these input functions.
When ``COMMAND`` is a shellscript command, it is a good practice to put the actual code into a :ref:`function <syntax-function>` and simply bind to the function name. This way it becomes significantly easier to test the function while editing, and the result is usually more readable as well.
If a script produces output, it should finish by calling ``commandline -f repaint`` to tell fish that a repaint is in order.
Note that special input functions cannot be combined with ordinary shell script commands. The commands must be entirely a sequence of special input functions (from ``bind -f``) or all shell script commands (i.e., valid fish script).
..note::
Special input functions cannot be combined with ordinary shell script commands. The commands must be entirely a sequence of special input functions (from ``bind -f``) or all shell script commands (i.e., valid fish script). To run special input functions from regular fish script, use ``commandline -f`` (see also :doc:`commandline <commandline>`). If a script produces output, it should finish by calling ``commandline -f repaint`` to tell fish that a repaint is in order.
If no ``SEQUENCE`` is provided, all bindings (or just the bindings in the given ``MODE``) are printed. If ``SEQUENCE`` is provided but no ``COMMAND``, just the binding matching that sequence is printed.
To save custom keybindings, put the ``bind`` statements into :ref:`config.fish <configuration>`. Alternatively, fish also automatically executes a function called ``fish_user_key_bindings`` if it exists.
To save custom keybindings, put the ``bind`` statements into :ref:`config.fish <configuration>`. Alternatively, fish also automatically executes a function called ``fish_user_key_bindings`` if it exists.
Key bindings may use "modes", which mimics Vi's modal input behavior. The default mode is "default", and every bind applies to a single mode. The mode can be viewed/changed with the ``$fish_bind_mode`` variable.
Key bindings may use "modes", which mimics Vi's modal input behavior. The default mode is "default". Every key binding applies to a single mode; you can specify which one with ``-M MODE``. If the key binding should change the mode, you can specify the new mode with ``-m NEW_MODE``. The mode can be viewed and changed via the ``$fish_bind_mode`` variable. If you want to change the mode from inside a fish function, use ``set fish_bind_mode MODE``.
Options
-------
@@ -81,6 +81,9 @@ The following options are available:
All invocations except for inserting new bindings can operate on both levels at the same time (if both **--preset** and **--user** are given).
**--preset** should only be used in full binding sets (like when working on ``fish_vi_key_bindings``).
**-s** or **--silent**
Silences some of the error messages, including for unknown key names and unbound sequences.
**-h** or **--help**
Displays help about using this command.
@@ -193,6 +196,9 @@ The following special input functions are available:
move one word to the right; or if at the end of the commandline, accept one word
from the current autosuggestion.
``history-pager``
invoke the searchable pager on history (incremental search); or if the history pager is already active, search further backwards in time.
``history-search-backward``
search the history for the previous match
@@ -230,7 +236,10 @@ The following special input functions are available:
move the selected text to the killring
``kill-whole-line``
move the line to the killring
move the line (including the following newline) to the killring. If the line is the last line, its preceeding newline is also removed
``kill-inner-line``
move the line (without the following newline) to the killring
``kill-word``
move the next word to the killring
@@ -240,10 +249,10 @@ The following special input functions are available:
or if at the end of the commandline, accept one word from the current autosuggestion.
``or``
only execute the next function if the previous succeeded (note: only some functions report success)
only execute the next function if the previous did not succeed (note: only some functions report failure)
``pager-toggle-search``
toggles the search field if the completions pager is visible.
toggles the search field if the completions pager is visible; or if used after ``history-pager``, search forwards in time.
``prevd-or-backward-word``
if the commandline is empty, then move backward in the directory history, otherwise move one word to the left
@@ -252,7 +261,7 @@ The following special input functions are available:
reexecutes the prompt functions and redraws the prompt (also ``force-repaint`` for backwards-compatibility)
``repaint-mode``
reexecutes the :ref:`fish_mode_prompt <cmd-fish_mode_prompt>` and redraws the prompt. This is useful for vi-mode. If no ``fish_mode_prompt`` exists or it prints nothing, it acts like a normal repaint.
reexecutes the :doc:`fish_mode_prompt <fish_mode_prompt>` and redraws the prompt. This is useful for vi-mode. If no ``fish_mode_prompt`` exists or it prints nothing, it acts like a normal repaint.
``self-insert``
inserts the matching sequence into the command line
``break`` halts a currently running loop (*LOOP_CONSTRUCT*), such as a :ref:`switch <cmd-switch>`, :ref:`for <cmd-for>` or :ref:`while <cmd-while>` loop. It is usually added inside of a conditional block such as an :ref:`if <cmd-if>` block.
``break`` halts a currently running loop (*LOOP_CONSTRUCT*), such as a :doc:`for <for>` or :doc:`while <while>` loop. It is usually added inside of a conditional block such as an :doc:`if <if>` block.
There are no parameters for ``break``.
@@ -37,4 +37,4 @@ The following code searches all .c files for "smurf", and halts at the first occ
See Also
--------
- the :ref:`continue <cmd-continue>` command, to skip the remainder of the current iteration of the current inner loop
- the :doc:`continue <continue>` command, to skip the remainder of the current iteration of the current inner loop
@@ -22,7 +22,7 @@ It is recommended to keep **.** as the first element of :envvar:`CDPATH`, or :en
Fish will also try to change directory if given a command that looks like a directory (starting with **.**, **/** or **~**, or ending with **/**), without explicitly requiring **cd**.
Fish also ships a wrapper function around the builtin **cd** that understands ``cd -`` as changing to the previous directory.
See also :ref:`prevd <cmd-prevd>`.
See also :doc:`prevd <prevd>`.
This wrapper function maintains a history of the 25 most recently visited directories in the ``$dirprev`` and ``$dirnext`` global variables.
If you make those universal variables your **cd** history is shared among all fish instances.
@@ -26,10 +26,16 @@ The following options are available:
If no argument is given, the current cursor position is printed, otherwise the argument is interpreted as the new cursor position.
If one of the options **-j**, **-p** or **-t** is given, the position is relative to the respective substring instead of the entire command line buffer.
**-B** or **--selection-start**
Get current position of the selection start in the buffer.
**-E** or **--selection-end**
Get current position of the selection end in the buffer.
**-f** or **--function**
Causes any additional arguments to be interpreted as input functions, and puts them into the queue, so that they will be read before any additional actual key presses are.
This option cannot be combined with any other option.
See :ref:`bind <cmd-bind>` for a list of input functions.
See :doc:`bind <bind>` for a list of input functions.
@@ -34,10 +34,10 @@ The following options are available:
Adds a short option to the completions list.
**-l** or **--long-option***LONG_OPTION*
Adds a GNUstyle long option to the completions list.
Adds a GNU-style long option to the completions list.
**-o** or **--old-option***LONG_OPTION*
Adds an oldstyle long option to the completions list (see below for details).
**-o** or **--old-option***OPTION*
Adds an old-style short or long option (see below for details).
**-a** or **--arguments***ARGUMENTS*
Adds the specified option arguments to the completions list.
@@ -61,7 +61,7 @@ The following options are available:
Causes the specified command to inherit completions from *WRAPPED_COMMAND* (see below for details).
**-n** or **--condition***CONDITION*
This completion should only be used if the *CONDITION* (a shell command) returns 0. This makes it possible to specify completions that should only be used in some cases.
This completion should only be used if the *CONDITION* (a shell command) returns 0. This makes it possible to specify completions that should only be used in some cases. If multiple conditions are specified, fish will try them in the order they are specified until one fails or all succeeded.
**-C** or **--do-complete***STRING*
Makes ``complete`` try to find all possible completions for the specified string. If there is no *STRING*, the current commandline is used instead.
@@ -76,9 +76,9 @@ Command specific tab-completions in ``fish`` are based on the notion of options
- Short options, like ``-a``. Short options are a single character long, are preceded by a single hyphen and can be grouped together (like ``-la``, which is equivalent to ``-l -a``). Option arguments may be specified by appending the option with the value (``-w32``), or, if ``--require-parameter`` is given, in the following parameter (``-w 32``).
- Oldstyle long options, like ``-Wall`` or ``-name``. Oldstyle long options can be more than one character long, are preceded by a single hyphen and may not be grouped together. Option arguments are specified in the following parameter (``-ao null``) or after a ``=`` (``-ao=null``).
- Old-style options, long like ``-Wall`` or ``-name`` or even short like ``-a``. Old-style options can be more than one character long, are preceded by a single hyphen and may not be grouped together. Option arguments are specified by default following a space (``-foo null``) or after ``=`` (``-foo=null``).
- GNUstyle long options, like ``--colors``. GNUstyle long options can be more than one character long, are preceded by two hyphens, and can't be grouped together. Option arguments may be specified after a ``=`` (``--quoting-style=shell``), or, if ``--require-parameter`` is given, in the following parameter (``--quoting-style shell``).
- GNU-style long options, like ``--colors``. GNU-style long options can be more than one character long, are preceded by two hyphens, and can't be grouped together. Option arguments may be specified after a ``=`` (``--quoting-style=shell``), or, if ``--require-parameter`` is given, in the following parameter (``--quoting-style shell``).
Multiple commands and paths can be given in one call to define the same completions for multiple commands.
@@ -86,7 +86,7 @@ Multiple command switches and wrapped commands can also be given to define multi
Invoking ``complete`` multiple times for the same command adds the new definitions on top of any existing completions defined for the command.
When ``-a`` or ``--arguments`` is specified in conjunction with long, short, or oldstyle options, the specified arguments are only completed as arguments for any of the specified options. If ``-a`` or ``--arguments`` is specified without any long, short, or oldstyle options, the specified arguments are used when completing non-option arguments to the command (except when completing an option argument that was specified with ``-r`` or ``--require-parameter``).
When ``-a`` or ``--arguments`` is specified in conjunction with long, short, or old-style options, the specified arguments are only completed as arguments for any of the specified options. If ``-a`` or ``--arguments`` is specified without any long, short, or old-style options, the specified arguments are used when completing non-option arguments to the command (except when completing an option argument that was specified with ``-r`` or ``--require-parameter``).
Command substitutions found in ``ARGUMENTS`` should return a newline-separated list of arguments, and each argument may optionally have a tab character followed by the argument description. Description given this way override a description given with ``-d`` or ``--description``.
@@ -101,14 +101,14 @@ When ``complete`` is called without anything that would define or erase completi
Examples
--------
The shortstyle option ``-o`` for the ``gcc`` command needs a file argument:
The short-style option ``-o`` for the ``gcc`` command needs a file argument:
::
complete -c gcc -s o -r
The shortstyle option ``-d`` for the ``grep`` command requires one of ``read``, ``skip`` or ``recurse``:
The short-style option ``-d`` for the ``grep`` command requires one of ``read``, ``skip`` or ``recurse``:
::
@@ -148,4 +148,6 @@ Now hub inherits all of the completions from git. Note this can also be specifie
complete -c git
Show all completions for ``git``.
Shows all completions for ``git``.
Any command ``foo`` that doesn't support grouping multiple short options in one string (not supporting ``-xf`` as short for ``-x -f``) or a short option and its value in one string (not supporting ``-d9`` instead of ``-d 9``) should be specified as a single-character old-style option instead of as a short-style option; for example, ``complete -c foo -o s; complete -c foo -o v`` would never suggest ``foo -ov`` but rather ``foo -o -v``.
``continue`` skips the remainder of the current iteration of the current inner loop, such as a :ref:`for <cmd-for>` loop or a :ref:`while <cmd-while>` loop. It is usually added inside of a conditional block such as an :ref:`if <cmd-if>` statement or a :ref:`switch <cmd-switch>` statement.
``continue`` skips the remainder of the current iteration of the current inner loop, such as a :doc:`for <for>` loop or a :doc:`while <while>` loop. It is usually added inside of a conditional block such as an :doc:`if <if>` statement or a :doc:`switch <switch>` statement.
Example
-------
@@ -35,4 +35,4 @@ The following code removes all tmp files that do not contain the word smurf.
See Also
--------
- the :ref:`break <cmd-break>` command, to stop the current inner loop
- the :doc:`break <break>` command, to stop the current inner loop
Note that the :ref:`cd <cmd-cd>` command limits directory history to the 25 most recently visited directories. The history is stored in the ``$dirprev`` and ``$dirnext`` variables.
Note that the :doc:`cd <cd>` command limits directory history to the 25 most recently visited directories. The history is stored in the ``$dirprev`` and ``$dirnext`` variables.
See Also
--------
- the :ref:`cdh <cmd-cdh>` command to display a prompt to quickly navigate the history
- the :ref:`prevd <cmd-prevd>` command to move backward
- the :ref:`nextd <cmd-nextd>` command to move forward
- the :doc:`cdh <cdh>` command to display a prompt to quickly navigate the history
- the :doc:`prevd <prevd>` command to move backward
- the :doc:`nextd <nextd>` command to move forward
Jobs in the list of jobs are sent a hang-up signal when fish terminates, which usually causes the job to terminate; ``disown`` allows these processes to continue regardless.
If no process is specified, the most recently-used job is removed (like :ref:`bg <cmd-bg>` and :ref:`fg <cmd-fg>`). If one or more PIDs are specified, jobs with the specified process IDs are removed from the job list. Invalid jobs are ignored and a warning is printed.
If no process is specified, the most recently-used job is removed (like :doc:`bg <bg>` and :doc:`fg <fg>`). If one or more PIDs are specified, jobs with the specified process IDs are removed from the job list. Invalid jobs are ignored and a warning is printed.
If a job is stopped, it is sent a signal to continue running, and a warning is printed. It is not possible to use the :ref:`bg <cmd-bg>` builtin to continue a job once it has been disowned.
If a job is stopped, it is sent a signal to continue running, and a warning is printed. It is not possible to use the :doc:`bg <bg>` builtin to continue a job once it has been disowned.
``disown`` returns 0 if all specified jobs were disowned successfully, and 1 if any problems were encountered.
@@ -30,4 +30,4 @@ Example
``firefox &; disown`` will start the Firefox web browser in the background and remove it from the job list, meaning it will not be closed when the fish process is closed.
``disown (jobs -p)`` removes all :ref:`jobs <cmd-jobs>` from the job list without terminating them.
``disown (jobs -p)`` removes all :doc:`jobs <jobs>` from the job list without terminating them.
**exit** is a special builtin that causes the shell to exit. Either 255 or the *CODE* supplied is used, whichever is lesser.
Otherwise, the exit status will be that of the last command executed.
If exit is called while sourcing a file (using the :ref:`source <cmd-source>` builtin) the rest of the file will be skipped, but the shell itself will not exit.
If exit is called while sourcing a file (using the :doc:`source <source>` builtin) the rest of the file will be skipped, but the shell itself will not exit.
The **--help** or **-h** option displays help about using this command.
:program:`fish_add_path` is a simple way to add more components to fish's :envvar:`PATH`. It does this by adding the components either to $fish_user_paths or directly to $PATH (if the ``--path`` switch is given).
:program:`fish_add_path` is a simple way to add more components to fish's :envvar:`PATH`. It does this by adding the components either to $fish_user_paths or directly to :envvar:`PATH` (if the ``--path`` switch is given).
It is (by default) safe to use :program:`fish_add_path` in config.fish, or it can be used once, interactively, and the paths will stay in future because of :ref:`universal variables <variables-universal>`. This is a "do what I mean" style command, if you need more control, consider modifying the variable yourself.
Components are normalized by :ref:`realpath <cmd-realpath>`. Trailing slashes are ignored and relative paths are made absolute (but symlinks are not resolved). If a component already exists, it is not added again and stays in the same place unless the ``--move`` switch is given.
Components are normalized by :doc:`realpath <realpath>`. Trailing slashes are ignored and relative paths are made absolute (but symlinks are not resolved). If a component already exists, it is not added again and stays in the same place unless the ``--move`` switch is given.
Components are added in the order they are given, and they are prepended to the path unless ``--append`` is given (if $fish_user_paths is used, that means they are last in $fish_user_paths, which is itself prepended to $PATH, so they still stay ahead of the system paths).
Components are added in the order they are given, and they are prepended to the path unless ``--append`` is given (if $fish_user_paths is used, that means they are last in $fish_user_paths, which is itself prepended to :envvar:`PATH`, so they still stay ahead of the system paths).
If no component is new, the variable (:envvar:`fish_user_paths` or :envvar:`$PATH`) is not set again or otherwise modified, so variable handlers are not triggered.
If no component is new, the variable (:envvar:`fish_user_paths` or :envvar:`PATH`) is not set again or otherwise modified, so variable handlers are not triggered.
If a component is not an existing directory, ``fish_add_path`` ignores it.
@@ -50,7 +50,7 @@ Options
Move already-existing components to the place they would be added - by default they would be left in place and not added again.
**-v** or **--verbose**
Print the :ref:`set <cmd-set>` command used.
Print the :doc:`set <set>` command used.
**-n** or **--dry-run**
Print the ``set`` command that would be used without executing it.
``fish_breakpoint_prompt`` is the prompt function when asking for input in response to a :ref:`breakpoint <cmd-breakpoint>` command.
``fish_breakpoint_prompt`` is the prompt function when asking for input in response to a :doc:`breakpoint <breakpoint>` command.
The exit status of commands within ``fish_breakpoint_prompt`` will not modify the value of :ref:`$status <variables-status>` outside of the ``fish_breakpoint_prompt`` function.
The ``fish_clipboard_copy`` function copies text to the system clipboard.
If stdin is not a terminal (see :doc:`isatty <isatty>`), it will read all input from there and copy it. If it is, it will use the current commandline, or the current selection if there is one.
It is bound to :kbd:`Control`\ +\ :kbd:`X` by default.
``fish_clipboard_copy`` works by calling a system-specific backend. If it doesn't appear to work you may need to install yours.
Currently supported are:
-``pbcopy``
-``wl-copy`` using wayland
-``xsel`` and ``xclip`` for X11
-``clip.exe`` on Windows.
See also
--------
-:doc:`fish_clipboard_paste` which does the inverse.
The ``fish_clipboard_paste`` function copies text from the system clipboard.
If its stdout is not a terminal (see :doc:`isatty <isatty>`), it will output everything there, as-is, without any additional newlines. If it is, it will put the text in the commandline instead.
If it outputs to the commandline, it will automatically escape the output if the cursor is currently inside single-quotes so it is suitable for single-quotes (meaning it escapes ``'`` and ``\\``).
It is bound to :kbd:`Control`\ +\ :kbd:`V` by default.
``fish_clipboard_paste`` works by calling a system-specific backend. If it doesn't appear to work you may need to install yours.
Currently supported are:
-``pbpaste``
-``wl-paste`` using wayland
-``xsel`` and ``xclip`` for X11
-``powershell.exe`` on Windows (this backend has encoding limitations and uses windows line endings that ``fish_clipboard_paste`` undoes)
See also
--------
-:doc:`fish_clipboard_copy` which does the inverse.
@@ -27,7 +27,7 @@ Available subcommands for the ``prompt`` command:
-``choose`` loads a sample prompt in the current session.
-``list`` lists the names of the available sample prompts.
-``save`` saves the current prompt to a file (via :ref:`funcsave <cmd-funcsave>`).
-``save`` saves the current prompt to a file (via :doc:`funcsave <funcsave>`).
-``show`` shows what the given sample prompts (or all) would look like.
With the ``theme`` command ``fish_config`` can be used to view and choose a theme (meaning a color scheme) inside the terminal.
@@ -38,7 +38,7 @@ Available subcommands for the ``theme`` command:
-``demo`` displays some sample text in the current theme.
-``dump`` prints the current theme in a loadable format.
-``list`` lists the names of the available sample themes.
-``save`` saves the current prompt to :ref:`universal variables <variables-universal>`.
-``save`` saves the given theme to :ref:`universal variables <variables-universal>`.
-``show`` shows what the given sample theme (or all) would look like.
The themes are loaded from the theme directory shipped with fish or a ``themes`` directory in the fish configuration directory (typically ``~/.config/fish/themes``).
The ``fish_delta`` function tells you, at a glance, which of your functions and completions differ from the set that fish ships.
It does this by going through the relevant variables (:envvar:`fish_function_path` for functions and :envvar:`fish_complete_path` for completions) and comparing the files against fish's default directories.
If any names are given, it will only compare files by those names (plus a ".fish" extension).
By default, it will also use ``diff`` to display the difference between the files. If ``diff`` is unavailable, it will skip it, but in that case it also cannot figure out if the files really differ.
The exit status is 1 if there was a difference and 2 for other errors, otherwise 0.
Options
-------
The following options are available:
**-f** or **--no-functions**
Stops checking functions
**-c** or **--no-completions**
Stops checking completions
**-C** or **--no-config**
Stops checking configuration files like config.fish or snippets in the conf.d directories.
**-d** or **--no-diff**
Removes the diff display (this happens automatically if ``diff`` can't be found)
**-n** or **--new**
Also prints new files (i.e. those that can't be found in fish's default directories).
**-Vvalue** or **--vendor=value**
Determines how the vendor directories are counted. Valid values are:
- "default" - counts vendor files as belonging to the defaults. Any changes in other directories will be counted as changes over them. This is the default.
- "user" - counts vendor files as belonging to the user files. Any changes in them will be counted as new or changed files.
- "ignore" - ignores vendor directories. Files of the same name will be counted as "new" if no file of the same name in fish's default directories exists.
**-h** or **--help**
Prints ``fish_delta``'s help (this).
Example
-------
Running just::
fish_delta
will give you a list of all your changed functions and completions, including diffs (if you have the ``diff`` command).
The options are there to select which parts of the output you want. With ``--no-completions`` you can compare just functions, and with ``--no-diff`` you can turn off the ``diff`` display.
To only compare your ``fish_git_prompt``, you might use::
fish_delta --no-completions fish_git_prompt
which will only compare files called "fish_git_prompt.fish".
@@ -24,13 +24,18 @@ The ``fish_git_prompt`` function displays information about the current git repo
`Git <https://git-scm.com>`_ must be installed.
There are numerous customization options, which can be controlled with git options or fish variables. git options, where available, take precedence over the fish variable with the same function. git options can be set on a per-repository or global basis. git options can be set with the ``git config`` command, while fish variables can be set as usual with the :ref:`set <cmd-set>` command.
There are numerous customization options, which can be controlled with git options or fish variables. git options, where available, take precedence over the fish variable with the same function. git options can be set on a per-repository or global basis. git options can be set with the ``git config`` command, while fish variables can be set as usual with the :doc:`set <set>` command.
-``$__fish_git_prompt_show_informative_status`` or the git option ``bash.showInformativeStatus`` can be set to enable the "informative" display, which will show a large amount of information - the number of untracked files, dirty files, unpushed/unpulled commits, and more. In large repositories, this can take a lot of time, so it you may wish to disable it in these repositories with ``git config --local bash.showInformativeStatus false``. It also changes the characters the prompt uses to less plain ones (``✚`` instead of ``*`` for the dirty state for example) , and if you are only interested in that, set ``$__fish_git_prompt_use_informative_chars`` instead.
Boolean options (those which enable or disable something) understand "1", "yes" or "true" to mean true and every other value to mean false.
-``$__fish_git_prompt_showdirtystate`` or the git option ``bash.showDirtyState`` can be set to show if the repository is "dirty", i.e. has uncommitted changes.
-``$__fish_git_prompt_show_informative_status`` or the git option ``bash.showInformativeStatus`` can be set to 1, true or yes to enable the "informative" display, which will show a large amount of information - the number of dirty files, unpushed/unpulled commits, and more.
In large repositories, this can take a lot of time, so you may wish to disable it in these repositories with ``git config --local bash.showInformativeStatus false``. It also changes the characters the prompt uses to less plain ones (``✚`` instead of ``*`` for the dirty state for example) , and if you are only interested in that, set ``$__fish_git_prompt_use_informative_chars`` instead.
-``$__fish_git_prompt_showuntrackedfiles`` or the git option ``bash.showUntrackedFiles`` can be set to show if the repository has untracked files (that aren't ignored).
Because counting untracked files requires a lot of time, the number of untracked files is only shown if enabled via``$__fish_git_prompt_showuntrackedfiles`` or the git option ``bash.showUntrackedFiles``.
-``$__fish_git_prompt_showdirtystate`` or the git option ``bash.showDirtyState`` can be set to 1, true or yes to show if the repository is "dirty", i.e. has uncommitted changes.
-``$__fish_git_prompt_showuntrackedfiles`` or the git option ``bash.showUntrackedFiles`` can be set to 1, true or yes to show if the repository has untracked files (that aren't ignored).
-``$__fish_git_prompt_showupstream`` can be set to a list of values to determine how changes between HEAD and upstream are shown:
@@ -49,7 +54,7 @@ There are numerous customization options, which can be controlled with git optio
``none``
disables (useful with informative status)
-``$__fish_git_prompt_showstashstate`` can be set to display the state of the stash.
-``$__fish_git_prompt_showstashstate`` can be set to 1, true or yes to display the state of the stash.
-``$__fish_git_prompt_shorten_branch_len`` can be set to the number of characters that the branch name will be shortened to.
@@ -66,7 +71,7 @@ There are numerous customization options, which can be controlled with git optio
If none of these apply, the commit SHA shortened to 8 characters is used.
-``$__fish_git_prompt_showcolorhints`` can be set to enable coloring for the branch name and status symbols.
-``$__fish_git_prompt_showcolorhints`` can be set to 1, true or yes to enable coloring for the branch name and status symbols.
A number of variables set characters and color used as indicators. Many of these have a different default if used with informative status enabled, or ``$__fish_git_prompt_use_informative_chars`` set. The usual default is given first, then the informative default (if it is different). If no default for the colors is given, they default to ``$__fish_git_prompt_color``.
@@ -77,10 +82,8 @@ A number of variables set characters and color used as indicators. Many of these
-``$__fish_git_prompt_color_bare`` - the color to use for a bare repository - one without a working tree
-``$__fish_git_prompt_color_merging`` - the color when a merge/rebase/revert/bisect or cherry-pick is in progress
Some variables are only used in some modes, like when informative status is enabled:
-``$__fish_git_prompt_char_cleanstate`` (✔) - the character to be used when nothing else applies
-``$__fish_git_prompt_color_cleanstate``
-``$__fish_git_prompt_char_cleanstate`` (✔ in informative mode) - the character to be used when nothing else applies
-``$__fish_git_prompt_color_cleanstate`` (no default)
Variables used with ``showdirtystate``:
@@ -112,13 +115,15 @@ Variables used with ``showupstream`` (also implied by informative status):
Colors used with ``showcolorhints``:
-``$__fish_git_prompt_color_branch`` (green) - the color of the branch
-``$__fish_git_prompt_color_branch`` (green) - the color of the branch if nothing else applies
-``$__fish_git_prompt_color_branch_detached`` (red) the color of the branch if it's detached (e.g. a commit is checked out)
-``$__fish_git_prompt_color_branch_dirty`` (no default) the color of the branch if it's dirty and not detached
-``$__fish_git_prompt_color_branch_staged`` (no default) the color of the branch if it just has something staged and is otherwise clean
-``$__fish_git_prompt_color_flags`` (--bold blue) - the default color for dirty/staged/stashed/untracked state
Note that all colors can also have a corresponding ``_done`` color. For example, the contents of ``$__fish_git_prompt_color_upstream_done`` is printed right _after_ the upstream.
See also :ref:`fish_vcs_prompt <cmd-fish_vcs_prompt>`, which will call all supported version control prompt functions, including git, Mercurial and Subversion.
See also :doc:`fish_vcs_prompt <fish_vcs_prompt>`, which will call all supported version control prompt functions, including git, Mercurial and Subversion.
Finally, ``$fish_prompt_hg_status_order``, which can be used to change the order the status symbols appear in. It defaults to ``added modified copied deleted untracked unmerged``.
See also :ref:`fish_vcs_prompt <cmd-fish_vcs_prompt>`, which will call all supported version control prompt functions, including git, Mercurial and Subversion.
See also :doc:`fish_vcs_prompt <fish_vcs_prompt>`, which will call all supported version control prompt functions, including git, Mercurial and Subversion.
@@ -38,7 +38,7 @@ The following options are available:
Outputs HTML, which supports syntax highlighting if the appropriate CSS is defined. The CSS class names are the same as the variable names, such as ``fish_color_command``.
**-d** or **--debug=DEBUG_CATEGORIES**
Enable debug output and specify a pattern for matching debug categories. See :ref:`Debugging <debugging-fish>` in :ref:`fish <cmd-fish>` (1) for details.
Enable debug output and specify a pattern for matching debug categories. See :ref:`Debugging <debugging-fish>` in :doc:`fish <fish>` (1) for details.
**-o** or **--debug-output=DEBUG_FILE**
Specify a file path to receive the debug output, including categories and ``fish_trace``. The default is standard error.
:program:`fish_key_reader` is used to explain how you would bind a certain key sequence. By default, it prints the :ref:`bind <cmd-bind>` command for one key sequence read interactively over standard input.
:program:`fish_key_reader` is used to explain how you would bind a certain key sequence. By default, it prints the :doc:`bind <bind>` command for one key sequence read interactively over standard input.
If the character sequence matches a special key name (see ``bind --key-names``), both ``bind CHARS ...`` and ``bind -k KEYNAME ...`` usage will be shown. In verbose mode (enabled by passing ``--verbose``), additional details about the characters received, such as the delay between chars, are written to standard error.
@@ -29,7 +29,7 @@ You can also define an empty ``fish_mode_prompt`` function to remove the Vi mode
function fish_mode_prompt; end
funcsave fish_mode_prompt
``fish_mode_prompt`` will be executed when the vi mode changes. If it produces any output, it is displayed and used. If it does not, the other prompt functions (:ref:`fish_prompt <cmd-fish_prompt>` and :ref:`fish_right_prompt <cmd-fish_right_prompt>`) will be executed as well in case they contain a mode display.
``fish_mode_prompt`` will be executed when the vi mode changes. If it produces any output, it is displayed and used. If it does not, the other prompt functions (:doc:`fish_prompt <fish_prompt>` and :doc:`fish_right_prompt <fish_right_prompt>`) will be executed as well in case they contain a mode display.
This command provides a way to produce option specifications suitable for use with the :ref:`argparse <cmd-argparse>` command. You can, of course, write the option specifications by hand without using this command. But you might prefer to use this for the clarity it provides.
This command provides a way to produce option specifications suitable for use with the :doc:`argparse <argparse>` command. You can, of course, write the option specifications by hand without using this command. But you might prefer to use this for the clarity it provides.
See also :ref:`fish_vcs_prompt <cmd-fish_vcs_prompt>`, which will call all supported version control prompt functions, including git, Mercurial and Subversion.
See also :doc:`fish_vcs_prompt <fish_vcs_prompt>`, which will call all supported version control prompt functions, including git, Mercurial and Subversion.
@@ -23,13 +23,13 @@ The ``fish_vcs_prompt`` function displays information about the current version
It calls out to VCS-specific functions. The currently supported systems are:
-:ref:`fish_git_prompt <cmd-fish_git_prompt>`
-:ref:`fish_hg_prompt <cmd-fish_hg_prompt>`
-:ref:`fish_svn_prompt <cmd-fish_svn_prompt>`
-:doc:`fish_git_prompt <fish_git_prompt>`
-:doc:`fish_hg_prompt <fish_hg_prompt>`
-:doc:`fish_svn_prompt <fish_svn_prompt>`
If a VCS isn't installed, the respective function does nothing.
The Subversion prompt is disabled by default, because it's slow on large repositories. To enable it, modify ``fish_vcs_prompt`` to uncomment it. See :ref:`funced <cmd-funced>`.
The Subversion prompt is disabled by default, because it's slow on large repositories. To enable it, modify ``fish_vcs_prompt`` to uncomment it. See :doc:`funced <funced>`.
For more information, see the documentation for each of the functions above.
**for** is a loop construct. It will perform the commands specified by *COMMANDS* multiple times. On each iteration, the local variable specified by *VARNAME* is assigned a new value from *VALUES*. If *VALUES* is empty, *COMMANDS* will not be executed at all. The *VARNAME* is visible when the loop terminates and will contain the last value assigned to it. If *VARNAME* does not already exist it will be set in the local scope. For our purposes if the **for** block is inside a function there must be a local variable with the same name. If the **for** block is not nested inside a function then global and universal variables of the same name will be used if they exist.
Much like :ref:`set <cmd-set>`, **for** does not modify $status, but the evaluation of its subordinate commands can.
Much like :doc:`set <set>`, **for** does not modify $status, but the evaluation of its subordinate commands can.
The **-h** or **--help** option displays help about using this command.
``funcsave`` saves a function to a file in the fish configuration directory. This function will be :ref:`automatically loaded <syntax-function-autoloading>` by current and future fish sessions. This can be useful to commit functions created interactively for permanent use.
If you have erased a function using :ref:`functions <cmd-functions>`'s ``--erase`` option, ``funcsave`` will remove the saved function definition.
If you have erased a function using :doc:`functions <functions>`'s ``--erase`` option, ``funcsave`` will remove the saved function definition.
Because fish loads functions on-demand, saved functions cannot serve as :ref:`event handlers <event>` until they are run or otherwise sourced. To activate an event handler for every new shell, add the function to the :ref:`configuration file <configuration>` instead of using ``funcsave``.
This is often used after :ref:`funced <cmd-funced>`, which opens the function in ``$EDITOR`` or ``$VISUAL`` and loads it into the current session afterwards.
This is often used after :doc:`funced <funced>`, which opens the function in ``$EDITOR`` or ``$VISUAL`` and loads it into the current session afterwards.
@@ -21,19 +21,19 @@ A function is a list of commands that will be executed when the name of the func
The following options are available:
**-a***NAMES* or **--argument-names***NAMES*
Assigns the value of successive command-line arguments to the names given in *NAMES*.
Assigns the value of successive command-line arguments to the names given in *NAMES*. These are the same arguments given in :envvar:`argv`, and are still available there. See also :ref:`Argument Handling <variables-argv>`.
**-d***DESCRIPTION* or **--description***DESCRIPTION*
A description of what the function does, suitable as a completion description.
**-w***WRAPPED_COMMAND* or **--wraps***WRAPPED_COMMAND*
Inherit completions from the given *WRAPPED_COMMAND*. See the documentation for :ref:`complete <cmd-complete>` for more information.
Inherit completions from the given *WRAPPED_COMMAND*. See the documentation for :doc:`complete <complete>` for more information.
**-e***EVENT_NAME* or **--on-event***EVENT_NAME*
Run this function when the specified named event is emitted. Fish internally generates named events, for example,when showing the prompt. Custom events can be emitted using the :ref:`emit <cmd-emit>` command.
Run this function when the specified named event is emitted. Fish internally generates named events, for example,when showing the prompt. Custom events can be emitted using the :doc:`emit <emit>` command.
**-v***VARIABLE_NAME* or **--on-variable***VARIABLE_NAME*
Run this function when the variable *VARIABLE_NAME* changes value. Note that :program:`fish`` makes no guarantees on any particular timing or even that the function will be run for every single ``set``. Rather it will be run when the variable has been set at least once, possibly skipping some values or being run when the variable has been set to the same value (except for universal variables set in other shells - only changes in the value will be picked up for those).
Run this function when the variable *VARIABLE_NAME* changes value. Note that :program:`fish` makes no guarantees on any particular timing or even that the function will be run for every single ``set``. Rather it will be run when the variable has been set at least once, possibly skipping some values or being run when the variable has been set to the same value (except for universal variables set in other shells - only changes in the value will be picked up for those).
**-j***PID* or **--on-job-exit***PID*
Run this function when the job containing a child process with the given process identifier *PID* exits. Instead of a PID, the string 'caller' can be specified. This is only allowed when in a command substitution, and will result in the handler being triggered by the exit of the job which created this command substitution.
@@ -42,7 +42,7 @@ The following options are available:
Run this function when the fish child process with process ID PID exits. Instead of a PID, for backward compatibility, "``%self``" can be specified as an alias for ``$fish_pid``, and the function will be run when the current fish instance exits.
**-s***SIGSPEC* or **--on-signal***SIGSPEC*
Run this function when the signal ``SIGSPEC`` is delivered. ``SIGSPEC`` can be a signal number, or the signal name, such as ``SIGHUP`` (or just ``HUP``). Note that the signal must have been delivered to :program:`fish`; for example, :kbd:`Ctrl-C` sends ``SIGINT`` to the foreground process group, which will not be :program:`fish` if you are running another command at the time.
Run this function when the signal ``SIGSPEC`` is delivered. ``SIGSPEC`` can be a signal number, or the signal name, such as ``SIGHUP`` (or just ``HUP``). Note that the signal must have been delivered to :program:`fish`; for example, :kbd:`Ctrl-C` sends ``SIGINT`` to the foreground process group, which will not be :program:`fish` if you are running another command at the time. Observing a signal will prevent fish from exiting in response to that signal.
**-S** or **--no-scope-shadowing**
Allows the function to access the variables of calling functions. Normally, any variables inside the function that have the same name as variables from the calling function are "shadowed", and their contents are independent of the calling function.
@@ -52,21 +52,9 @@ The following options are available:
**-V** or **--inherit-variable NAME**
Snapshots the value of the variable ``NAME`` and defines a local variable with that same name and value when the function is defined. This is similar to a closure in other languages like Python but a bit different. Note the word "snapshot" in the first sentence. If you change the value of the variable after defining the function, even if you do so in the same scope (typically another function) the new value will not be used by the function you just created using this option. See the ``function notify`` example below for how this might be used.
If the user enters any additional arguments after the function, they are inserted into the environment :ref:`variable list <variables-lists>```$argv``. If the ``--argument-names`` option is provided, the arguments are also assigned to names specified in that option.
The event handler switches (``on-event``, ``on-variable``, ``on-job-exit``, ``on-process-exit`` and ``on-signal``) cause a function to run automatically at specific events. New named events for ``--on-event`` can be fired using the :doc:`emit <emit>` builtin. Fish already generates a few events, see :ref:`event` for more.
By using one of the event handler switches, a function can be made to run automatically at specific events. The user may generate new events using the :ref:`emit <cmd-emit>` builtin. Fish generates the following named events:
-``fish_prompt``, which is emitted whenever a new fish prompt is about to be displayed.
-``fish_preexec``, which is emitted right before executing an interactive command. The commandline is passed as the first parameter. Not emitted if command is empty.
-``fish_posterror``, which is emitted right after executing a command with syntax errors. The commandline is passed as the first parameter.
-``fish_postexec``, which is emitted right after executing an interactive command. The commandline is passed as the first parameter. Not emitted if command is empty.
-``fish_exit`` is emitted right before fish exits.
-``fish_cancel``, which is emitted when a commandline is cleared (used for terminal-shell integration).
Functions may not be named the same as a reserved keyword. These are elements of fish syntax or builtin commands which are essential for the operations of the shell. Current reserved words are ``[``, ``_``, ``and``, ``argparse``, ``begin``, ``break``, ``builtin``, ``case``, ``command``, ``continue``, ``else``, ``end``, ``eval``, ``exec``, ``for``, ``function``, ``if``, ``not``, ``or``, ``read``, ``return``, ``set``, ``status``, ``string``, ``switch``, ``test``, ``time``, and ``while``.
@@ -31,13 +31,13 @@ The following options are available:
Changes the description of this function.
**-e** or **--erase**
Causes the specified functions to be erased. This also means that it is prevented from autoloading in the current session. Use :ref:`funcsave <cmd-funcsave>` to remove the saved copy.
Causes the specified functions to be erased. This also means that it is prevented from autoloading in the current session. Use :doc:`funcsave <funcsave>` to remove the saved copy.
**-D** or **--details**
Reports the path name where the specified function is defined or could be autoloaded, ``stdin`` if the function was defined interactively or on the command line or by reading standard input, **-** if the function was created via :ref:`source <cmd-source>`, and ``n/a`` if the function isn't available. (Functions created via :ref:`alias <cmd-alias>` will return **-**, because ``alias`` uses ``source`` internally.) If the **--verbose** option is also specified then five lines are written:
Reports the path name where the specified function is defined or could be autoloaded, ``stdin`` if the function was defined interactively or on the command line or by reading standard input, **-** if the function was created via :doc:`source <source>`, and ``n/a`` if the function isn't available. (Functions created via :doc:`alias <alias>` will return **-**, because ``alias`` uses ``source`` internally. Copied functions will return where the function was copied.) If the **--verbose** option is also specified then five lines are written:
- the pathname as already described,
-``autoloaded``, ``not-autoloaded`` or ``n/a``,
- the pathname as already described,
- if the function was copied, the path name to where the function was originally defined, otherwise``autoloaded``, ``not-autoloaded`` or ``n/a``,
- the line number within the file or zero if not applicable,
-``scope-shadowing`` if the function shadows the vars in the calling function (the normal case if it wasn't defined with **--no-scope-shadowing**), else ``no-scope-shadowing``, or ``n/a`` if the function isn't defined,
- the function description minimally escaped so it is a single line, or ``n/a`` if the function isn't defined or has no description.
``if`` will execute the command ``CONDITION``. If the condition's exit status is 0, the commands ``COMMANDS_TRUE`` will execute. If the exit status is not 0 and :ref:`else <cmd-else>` is given, ``COMMANDS_FALSE`` will be executed.
``if`` will execute the command ``CONDITION``. If the condition's exit status is 0, the commands ``COMMANDS_TRUE`` will execute. If the exit status is not 0 and :doc:`else <else>` is given, ``COMMANDS_FALSE`` will be executed.
You can use :ref:`and <cmd-and>` or :ref:`or <cmd-or>` in the condition. See the second example below.
You can use :doc:`and <and>` or :doc:`or <or>` in the condition. See the second example below.
The exit status of the last foreground command to exit can always be accessed using the :ref:`$status <variables-status>` variable.
On systems that supports this feature, jobs will print the CPU usage of each job since the last command was executed. The CPU usage is expressed as a percentage of full CPU activity. Note that on multiprocessor systems, the total activity may be more than 100\%.
On systems that support this feature, jobs will print the CPU usage of each job since the last command was executed. The CPU usage is expressed as a percentage of full CPU activity. Note that on multiprocessor systems, the total activity may be more than 100\%.
Arguments of the form *PID* or *%JOBID* restrict the output to jobs with the selected process identifiers or job numbers respectively.
@@ -36,7 +36,7 @@ The following options are available:
**-s***N* or **--scale***N*
Sets the scale of the result.
``N`` must be an integer or the word "max" for the maximum scale.
A scale of zero causes results to be rounded down to the nearest integer.
A scale of zero causes results to be truncated, not rounded. Any non-integer component is thrown away.
So ``3/2`` returns ``1`` rather than ``2`` which ``1.5`` would normally round to.
This is for compatibility with ``bc`` which was the basis for this command prior to fish 3.0.0.
Scale values greater than zero causes the result to be rounded using the usual rules to the specified number of decimal places.
@@ -64,6 +64,8 @@ Syntax
For numbers, ``.`` is always the radix character regardless of locale - ``2.5``, not ``2,5``.
Scientific notation (``10e5``) and hexadecimal (``0xFF``) are also available.
``math`` allows you to use underscores as visual separators for digit grouping. For example, you can write ``1_000_000``, ``0x_89_AB_CD_EF``, and ``1.234_567_e89``.
Operators
---------
@@ -74,17 +76,15 @@ Operators
``-``
for subtraction
``*`` or ``x``
for multiplication
for multiplication. ``*`` is the glob character and needs to be quoted or escaped, ``x`` needs to be followed by whitespace or it looks like ``0x`` hexadecimal notation.
``/``
for division
(Note that ``*`` is the glob character and needs to be quoted or escaped, ``x`` needs to be followed by whitespace or it looks like ``0x`` hexadecimal notation.)
``^``
for exponentiation
``%``
for modulo
``(`` or ``)``
for grouping.
(These need to be quoted or escaped because ``()`` denotes a command substitution.)
for grouping. These need to be quoted or escaped because ``()`` denotes a command substitution.
They are all used in an infix manner - ``5 + 2``, not ``+ 5 2``.
@@ -120,9 +120,23 @@ Functions
arc tangent of two variables
``bitand``, ``bitor`` and ``bitxor``
perform bitwise operations.
These will throw away any non-integer parts andd interpret the rest as an int.
These will throw away any non-integer parts and interpret the rest as an int.
Note: ``bitnot`` and ``bitnand`` don't exist. This is because numbers in math don't really have a *width* in terms of bits,
and these operations necessarily care about leading zeroes.
If you need to negate a specific number you can do it with an xor with a mask, e.g.::
> math --base=hex bitxor 0x0F, 0xFF
0xF0
> math --base=hex bitxor 0x2, 0x3
# Here we mask with 0x3 == 0b111, so our number is 3 bits wide
# Only the 1 bit isn't set.
0x1
``ceil``
round number up to nearest integer
round number up to the nearest integer
``cos``
the cosine
``cosh``
@@ -132,7 +146,7 @@ Functions
``fac``
factorial - also known as ``x!`` (``x * (x - 1) * (x - 2) * ... * 1``)
``floor``
round number down to nearest integer
round number down to the nearest integer
``ln``
the base-e logarithm
``log`` or ``log10``
@@ -140,9 +154,9 @@ Functions
``log2``
the base-2 logarithm
``max``
returns the larger of two numbers
returns the largest of the given numbers - this takes an arbitrary number of arguments (but at least one)
``min``
returns the smaller of two numbers
returns the smallest of the given numbers - this takes an arbitrary number of arguments (but at least one)
``ncr``
"from n choose r" combination function - how many subsets of size r can be taken from n (order doesn't matter)
``npr``
@@ -191,6 +205,8 @@ Examples
``math 'ncr(49,6)'`` prints 13983816 - that's the number of possible picks in 6-from-49 lotto.
``or`` is used to execute a command if the previous command was not successful (returned a status of something other than 0).
``or`` statements may be used as part of the condition in an :ref:`and <cmd-if>` or :ref:`while <cmd-while>` block.
``or`` statements may be used as part of the condition in an :doc:`if <if>` or :doc:`while <while>` block.
``or`` does not change the current exit status itself, but the command it runs most likely will. The exit status of the last foreground command to exit can always be accessed using the :ref:`$status <variables-status>` variable.
@@ -33,4 +33,4 @@ The following code runs the ``make`` command to build a program. If the build su
PATH arguments are taken from the command line unless standard input is connected to a pipe or a file, in which case they are read from standard input, one PATH per line. It is an error to supply PATH arguments on both the command line and on standard input.
Arguments starting with ``-`` are normally interpreted as switches; ``--`` causes the following arguments not to be treated as switches even if they begin with ``-``. Switches and required arguments are recognized only on the command line.
When a path starts with ``-``, ``path filter`` and ``path normalize`` will prepend ``./`` on output to avoid it being interpreted as an option otherwise, so it's safe to pass path's output to other commands that can handle relative paths.
All subcommands accept a ``-q`` or ``--quiet`` switch, which suppresses the usual output but exits with the documented status. In this case these commands will quit early, without reading all of the available input.
All subcommands also accept a ``-Z`` or ``--null-out`` switch, which makes them print output separated with NUL instead of newlines. This is for further processing, e.g. passing to another ``path``, or ``xargs -0``. This is not recommended when the output goes to the terminal or a command substitution.
All subcommands also accept a ``-z`` or ``--null-in`` switch, which makes them accept arguments from stdin separated with NULL-bytes. Since Unix paths can't contain NULL, that makes it possible to handle all possible paths and read input from e.g. ``find -print0``. If arguments are given on the commandline this has no effect. This should mostly be unnecessary since ``path`` automatically starts splitting on NULL if one appears in the first PATH_MAX bytes, PATH_MAX being the operating system's maximum length for a path plus a NULL byte.
Some subcommands operate on the paths as strings and so work on nonexistent paths, while others need to access the paths themselves and so filter out nonexistent paths.
``path basename`` returns the last path component of the given path, by removing the directory prefix and removing trailing slashes. In other words, it is the part that is not the dirname. For files you might call it the "filename".
It returns 0 if there was a basename, i.e. if the path wasn't empty or just slashes.
``path dirname`` returns the dirname for the given path. This is the part before the last "/", discounting trailing slashes. In other words, it is the part that is not the basename (discounting superfluous slashes).
It returns 0 if there was a dirname, i.e. if the path wasn't empty or just slashes.
``path extension`` returns the extension of the given path. This is the part after (and including) the last ".", unless that "." followed a "/" or the basename is "." or "..", in which case there is no extension and an empty line is printed.
If the filename ends in a ".", only a "." is printed.
It returns 0 if there was an extension.
Examples
^^^^^^^^
::
>_ path extension ./foo.mp4
.mp4
>_ path extension ../banana
# an empty line, status 1
>_ path extension ~/.config
# an empty line, status 1
>_ path extension ~/.config.d
.d
>_ path extension ~/.config.
.
>_ set -l path (path change-extension '' ./foo.mp4)
``path filter`` returns all of the given paths that match the given checks. In all cases, the paths need to exist, nonexistent paths are always filtered.
The available filters are:
-``-t`` or ``--type`` with the options: "dir", "file", "link", "block", "char", "fifo" and "socket", in which case the path needs to be a directory, file, link, block device, character device, named pipe or socket, respectively.
-``-d``, ``-f`` and ``-l`` are short for ``--type=dir``, ``--type=file`` and ``--type=link``, respectively. There are no shortcuts for the other types.
-``-p`` or ``--perm`` with the options: "read", "write", and "exec", as well as "suid", "sgid", "user" (referring to the path owner) and "group" (referring to the path's group), in which case the path needs to have all of the given permissions for the current user.
-``-r``, ``-w`` and ``-x`` are short for ``--perm=read``, ``--perm=write`` and ``--perm=exec``, respectively. There are no shortcuts for the other permissions.
Note that the path needs to be *any* of the given types, but have *all* of the given permissions. This is because having a path that is both writable and executable makes sense, but having a path that is both a directory and a file doesn't. Links will count as the type of the linked-to file, so links to files count as files, links to directories count as directories.
The filter options can either be given as multiple options, or comma-separated - ``path filter -t dir,file`` or ``path filter --type dir --type file`` are equivalent.
With ``--invert``, the meaning of the filtering is inverted - any path that wouldn't pass (including by not existing) passes, and any path that would pass fails.
When a path starts with ``-``, ``path filter`` will prepend ``./`` to avoid it being interpreted as an option otherwise.
It returns 0 if at least one path passed the filter.
``path is`` is shorthand for ``path filter -q``, i.e. just checking without producing output, see :ref:`The is subcommand <cmd-path-is>`.
Examples
^^^^^^^^
::
>_ path filter /usr/bin /usr/argagagji
# The (hopefully) nonexistent argagagji is filtered implicitly:
``path mtime`` returns the last modification time ("mtime" in unix jargon) of the given paths, in seconds since the unix epoch (the beginning of the 1st of January 1970).
With ``--relative`` (or ``-R``), it prints the number of seconds since the modification time. It only reads the current time once at start, so in case multiple paths are given the times are all relative to the *start* of ``path mtime -R`` running.
If you want to know if a file is newer or older than another file, consider using ``test -nt`` instead. See :doc:`the test documentation <test>`.
It returns 0 if reading mtime for any path succeeded.
Examples
^^^^^^^^
::
>_ date +%s
# This prints the current time as seconds since the epoch
1657217847
>_ path mtime /etc/
1657213796
>_ path mtime -R /etc/
4078
# So /etc/ on this system was last modified a little over an hour ago
``path normalize`` returns the normalized versions of all paths. That means it squashes duplicate "/" (except for two leading "//"), collapses "../" with earlier components and removes "." components.
Unlike ``realpath`` or ``path resolve``, it does not make the paths absolute. It also does not resolve any symlinks. As such it can operate on non-existent paths.
Because it operates on paths as strings and doesn't resolve symlinks, it works sort of like ``pwd -L`` and ``cd``. E.g. ``path normalize link/..`` will return ``.``, just like ``cd link; cd ..`` would return to the current directory. For a physical view of the filesystem, see ``path resolve``.
Leading "./" components are usually removed. But when a path starts with ``-``, ``path normalize`` will add it instead to avoid confusion with options.
It returns 0 if any normalization was done, i.e. any given path wasn't in canonical form.
Examples
^^^^^^^^
::
>_ path normalize /usr/bin//../../etc/fish
# The "//" is squashed and the ".." components neutralize the components before
/etc/fish
>_ path normalize /bin//bash
# The "//" is squashed, but /bin isn't resolved even if your system links it to /usr/bin.
``path resolve`` returns the normalized, physical and absolute versions of all paths. That means it resolves symlinks and does what ``path normalize`` does: it squashes duplicate "/", collapses "../" with earlier components and removes "." components. Then it turns that path into the absolute path starting from the filesystem root "/".
It is similar to ``realpath``, as it creates the "real", canonical version of the path. However, for paths that can't be resolved, e.g. if they don't exist or form a symlink loop, it will resolve as far as it can and normalize the rest.
Because it resolves symlinks, it works sort of like ``pwd -P``. E.g. ``path resolve link/..`` will return the parent directory of what the link points to, just like ``cd link; cd (pwd -P)/..`` would go to it. For a logical view of the filesystem, see ``path normalize``.
It returns 0 if any normalization or resolution was done, i.e. any given path wasn't in canonical form.
Examples
^^^^^^^^
::
>_ path resolve /bin//sh
# The "//" is squashed, and /bin is resolved if your system links it to /usr/bin.
# sh here is bash (this is common on linux systems)
/usr/bin/bash
>_ path resolve /bin/foo///bar/../baz
# Assuming /bin exists and is a symlink to /usr/bin, but /bin/foo doesn't.
# This resolves the /bin/ and normalizes the nonexistent rest:
``path change-extension`` returns the given paths, with their extension changed to the given new extension. The extension is the part after (and including) the last ".", unless that "." followed a "/" or the basename is "." or "..", in which case there is no previous extension and the new one is simply added.
If the extension is empty, any previous extension is stripped, along with the ".". This is, of course, the inverse of ``path extension``.
One leading dot on the extension is ignored, so ".mp3" and "mp3" are treated the same.
It returns 0 if it was given any paths.
Examples
^^^^^^^^
::
>_ path change-extension mp4 ./foo.wmv
./foo.mp4
>_ path change-extension .mp4 ./foo.wmv
./foo.mp4
>_ path change-extension '' ../banana
../banana
# but status 1, because there was no extension.
>_ path change-extension '' ~/.config
/home/alfa/.config
# status 1
>_ path change-extension '' ~/.config.d
/home/alfa/.config
# status 0
>_ path change-extension '' ~/.config.
/home/alfa/.config
# status 0
"sort" subcommand
-----------------------------
::
path sort [-z | --null-in] [-Z | --null-out] \
[-q | --quiet] [-r | --reverse] \
[--key=basename|dirname|path] [PATH ...]
``path sort`` returns the given paths in sorted order. They are sorted in the same order as globs - alphabetically, but with runs of numerical digits compared numerically.
With ``--reverse`` or ``-r`` the sort is reversed.
With ``--key=`` only the given part of the path is compared, e.g. ``--key=dirname`` causes only the dirname to be compared, ``--key=basename`` only the basename and ``--key=path`` causes the entire path to be compared (this is the default).
With ``--unique`` or ``-u`` the sort is deduplicated, meaning only the first of a run that have the same key is kept. So if you are sorting by basename, then only the first of each basename is used.
The sort used is stable, so sorting first by basename and then by dirname works and causes the files to be grouped according to directory.
# prints a list of all function files fish would use, sorted by name.
Combining ``path``
-------------------
``path`` is meant to be easy to combine with itself, other tools and fish.
This is why
-``path``'s output is automatically split by fish if it goes into a command substitution, so just doing ``(path ...)`` handles all paths, even those containing newlines, correctly
-``path`` has ``--null-in`` to handle null-delimited input (typically automatically detected!), and ``--null-out`` to pass on null-delimited output
Some examples of combining ``path``::
# Expand all paths in the current directory, leave only executable files, and print their resolved path
path filter -zZ -xf -- * | path resolve -z
# The same thing, but using find (note -maxdepth needs to come first or find will scream)
# (this also depends on your particular version of find)
# Note the `-z` is unnecessary for any sensible version of find - if `path` sees a NULL,
``popd`` removes the top directory from the :ref:`directory stack <directory-stack>` and changes the working directory to the new top directory. Use :ref:`pushd <cmd-pushd>` to add directories to the stack.
``popd`` removes the top directory from the :ref:`directory stack <directory-stack>` and changes the working directory to the new top directory. Use :doc:`pushd <pushd>` to add directories to the stack.
The **-h** or **--help** option displays help about using this command.
@@ -37,5 +37,5 @@ Example
See Also
--------
- the :ref:`dirs <cmd-dirs>` command to print the directory stack
- the :ref:`cdh <cmd-cdh>` command which provides a more intuitive way to navigate to recently visited directories.
- the :doc:`dirs <dirs>` command to print the directory stack
- the :doc:`cdh <cdh>` command which provides a more intuitive way to navigate to recently visited directories.
The *FORMAT* argument is re-used as many times as necessary to convert all of the given arguments. So ``printf %s\n flounder catfish clownfish shark`` will print four lines.
Unlike :ref:`echo <cmd-echo>`, ``printf`` does not append a new line unless it is specified as part of the string.
Unlike :doc:`echo <echo>`, ``printf`` does not append a new line unless it is specified as part of the string.
It doesn't support any options, so there is no need for a ``--`` separator, which makes it easier to use for arbitrary input than ``echo``. [#]_
@@ -99,7 +99,7 @@ Will print "Number of bananas in my pocket: 42", `without` a newline.
See Also
--------
- the :ref:`echo <cmd-echo>` command, for simpler output
- the :doc:`echo <echo>` command, for simpler output
To change the number of characters per path component, pass ``--dir-length=`` or set :envvar:`fish_prompt_pwd_dir_length` to the number of characters. Setting it to 0 or an invalid value will disable shortening entirely. This defaults to 1.
To keep some components unshortened, pass ``--full-length-dirs=`` or set :envvar:`$fish_prompt_pwd_full_dirs` to the number of components. This defaults to 1, keeping the last component.
To keep some components unshortened, pass ``--full-length-dirs=`` or set :envvar:`fish_prompt_pwd_full_dirs` to the number of components. This defaults to 1, keeping the last component.
If any positional arguments are given, ``prompt_pwd`` shortens them instead of $PWD.
If any positional arguments are given, ``prompt_pwd`` shortens them instead of :envvar:`PWD`.
The ``pushd`` function adds *DIRECTORY* to the top of the :ref:`directory stack <directory-stack>` and makes it the current working directory. :ref:`popd <cmd-popd>` will pop it off and return to the original directory.
The ``pushd`` function adds *DIRECTORY* to the top of the :ref:`directory stack <directory-stack>` and makes it the current working directory. :doc:`popd <popd>` will pop it off and return to the original directory.
Without arguments, it exchanges the top two directories in the stack.
@@ -49,5 +49,5 @@ Example
See Also
--------
- the :ref:`dirs <cmd-dirs>` command to print the directory stack
- the :ref:`cdh <cmd-cdh>` command which provides a more intuitive way to navigate to recently visited directories.
- the :doc:`dirs <dirs>` command to print the directory stack
- the :doc:`cdh <cdh>` command which provides a more intuitive way to navigate to recently visited directories.
@@ -42,7 +42,7 @@ The following options are available:
Uses the output of the shell command *PROMPT_CMD* as the prompt for the interactive mode. The default prompt command is ``set_color green; echo read; set_color normal; echo "> "``
**-P** or **--prompt-str***PROMPT_STR*
Uses the *PROMPT_STR* as the prompt for the interactive mode. It is equivalent to ``echo $PROMPT_STR`` and is provided solely to avoid the need to frame the prompt as a command. All special characters in the string are automatically escaped before being passed to the :ref:`echo <cmd-echo>` command.
Uses the *PROMPT_STR* as the prompt for the interactive mode. It is equivalent to ``echo $PROMPT_STR`` and is provided solely to avoid the need to frame the prompt as a command. All special characters in the string are automatically escaped before being passed to the :doc:`echo <echo>` command.
**-R** or **--right-prompt***RIGHT_PROMPT_CMD*
Uses the output of the shell command *RIGHT_PROMPT_CMD* as the right prompt for the interactive mode. There is no default right prompt command.
@@ -98,26 +98,29 @@ is set to empty and the exit status is set to 122. This limit can be altered wit
Example
-------
The following code stores the value 'hello' in the shell variable :envvar:`$foo`.
``read`` has a few separate uses.
The following code stores the value 'hello' in the shell variable :envvar:`foo`.
::
echo hello|read foo
# This is a neat way to handle command output by-line:
While this is a neat way to handle command output line-by-line::
To see the documentation on the ``realpath`` command you might have,
use ``command man realpath``.
:program:`realpath` follows all symbolic links encountered for the provided :envvar:`PATH`, printing the absolute path resolved. :ref:`fish <cmd-fish>` provides a :command:`realpath`-alike builtin intended to be enrich systems where no such command is installed by default.
:program:`realpath` follows all symbolic links encountered for the provided :envvar:`PATH`, printing the absolute path resolved. :doc:`fish <fish>` provides a :command:`realpath`-alike builtin intended to enrich systems where no such command is installed by default.
If a :command:`realpath` command exists, that will be preferred.
``builtin realpath`` will explicitly use the fish implementation of :command:`realpath`.
If :program:`return` is invoked outside of a function or dot script it is equivalent to exit.
It is often added inside of a conditional block such as an :ref:`if <cmd-if>` statement or a :ref:`switch <cmd-switch>` statement to conditionally stop the executing function and return to the caller; it can also be used to specify the exit status of a function.
It is often added inside of a conditional block such as an :doc:`if <if>` statement or a :doc:`switch <switch>` statement to conditionally stop the executing function and return to the caller; it can also be used to specify the exit status of a function.
If at the top level of a script, it exits with the given status, like :ref:`exit <cmd-exit>`.
If at the top level of a script, it exits with the given status, like :doc:`exit <exit>`.
If at the top level in an interactive session, it will set :envvar:`status`, but not exit the shell.
The **-h** or **--help** option displays help about using this command.
If both a *VARIABLE* and *VALUES* are provided, ``set`` assigns the values to the variable of that name. Because all variables in fish are :ref:`lists <variables-lists>`, multiple values are allowed.
If both *NAME* and *VALUE* are provided, ``set`` assigns any values to variable *NAME*.
Variables in fish are :ref:`lists <variables-lists>`, multiple values are allowed.
One or more variable *INDEX* can be specified including ranges (not for all options.)
If only a variable name has been given, ``set`` sets the variable to the empty list.
If no *VALUE* is given, the variable will be set to the empty list i.e. ``''``.
If ``set`` is called with no arguments, it prints the names and values of all shell variables in sorted order. Passing :ref:`scope <variables-scope>` or :ref:`export <variables-export>` flags allows filtering this to only matching variables, so ``set --local`` would only show local variables.
If ``set`` is ran without arguments, it prints the names and values of all shell variables in sorted order.
Passing :ref:`scope <variables-scope>` or :ref:`export <variables-export>` flags allows filtering this to only matching variables, so ``set --local`` would only show local variables.
With ``--erase`` and optionally a scope flag ``set`` will erase the matching variable (or the variable of that name in the smallest possible scope).
With ``--show``, ``set`` will describe the given variable names, explaining how they have been defined - in which scope with which values and options.
The following options control variable scope:
**-f** or **--function**
Scopes the variable to the currently executing function. It is erased when the function ends.
**-l** or **--local**
Scopes the variable to the currently executing block. It is erased when the block ends. Outside of a block, this is the same as **--function**.
**-g** or **--global**
Causes the specified shell variable to be given a global scope. Global variables don't disappear and are available to all functions running in the same shell. They can even be modified.
The following scope control variable scope:
**-U** or **--universal**
Causes the specified shell variable to be given a universal scope. If this option is supplied, the variable will be shared between all the current user's fish instances on the current computer, and will be preserved across restarts of the shell.
Sets a universal variable.
The variable will be immediately available to all the user's ``fish`` instances on the machine, and will be persist across restarts of the shell.
These options control additional variable options:
**-f** or **--function**
Sets a variable scoped to the executing function.
It is erased when the function ends.
**-x** or **--export**
Causes the specified shell variable to be exported to child processes (making it an "environment variable")
**-l** or **--local**
Sets a locally-scoped variable in this block.
It is erased when the block ends.
Outside of a block, this is the same as **--function**.
**-u** or **--unexport**
Causes the specified shell variable to NOT be exported to child processes
**-g** or **--global**
Sets a globally-scoped variable.
Global variables are available to all functions running in the same shell.
They can be modified or erased.
These options modify how variables operate:
**--export** or **-x**
Causes the specified shell variable to be exported to child processes (making it an "environment variable").
**--unexport** or **-u**
Causes the specified shell variable to NOT be exported to child processes.
**--path**
Causes the specified variable to be treated as a :ref:`path variable <variables-path>`, meaning it will automatically be split on colons, and joined using colons when quoted (``echo "$PATH"``) or exported.
Treat specified variable as a :ref:`path variable <variables-path>`; variable will be split on colons (``:``) and will be displayed joined by colons colons when quoted (``echo "$PATH"``) or exported.
**--unpath**
Causes the specified variable to not be treated as a :ref:`path variable <variables-path>`. Variables with a name ending in "PATH" are automatically path variables, so this can be used to treat such a variable normally.
Causes variable to no longer be tred as a :ref:`path variable <variables-path>`.
Note: variables ending in "PATH" are automatically path variables.
The following other options are available:
Further options:
**-a** or **--append**
Causes the values to be appended to the current set of values for the variable. This can be used with **--prepend** to both append and prepend at the same time. This cannot be used when assigning to a variable slice.
**-a** or **--append***NAME**VALUE* ...
Appends *VALUES* to the current set of values for variable**NAME**.
Can be used with **--prepend** to both append and prepend at the same time.
This cannot be used when assigning to a variable slice.
**-p** or **--prepend**
Causes the values to be prepended to the current set of values for the variable. This can be used with **--append** to both append and prepend at the same time. This cannot be used when assigning to a variable slice.
**-p** or **--prepend***NAME**VALUE* ...
Prepends *VALUES* to the current set of values for variable**NAME**.
This can be used with **--append** to both append and prepend at the same time.
This cannot be used when assigning to a variable slice.
**-e** or **--erase**
Causes the specified shell variables to be erased
**-e** or **--erase***NAME*[*INDEX*]
Causes the specified shell variables to be erased.
Supports erasing from multiple scopes at once.
Individual items in a variable at *INDEX* in brackets can be specified.
**-q** or **--query**
Test if the specified variable names are defined. Does not output anything, but the builtins exit status is the number of variables specified that were not defined, up to a maximum of 255. If no variable was given, it also returns 255.
**-q** or **--query***NAME*[*INDEX*]
Test if the specified variable names are defined.
If an *INDEX* is provided, check for items at that slot.
Does not output anything, but the shell status is set to the number of variables specified that were not defined, up to a maximum of 255.
If no variable was given, it also returns 255.
**-n** or **--names**
List only the names of all defined variables, not their value. The names are guaranteed to be sorted.
List only the names of all defined variables, not their value.
The names are guaranteed to be sorted.
**-S** or **--show**
Shows information about the given variables. If no variable names are given then all variables are shown in sorted order. It shows the scopes the given variables are set in, along with the values in each and whether or not it is exported. No other flags can be used with this option.
Shows information about the given variables.
If no variable names are given then all variables are shown in sorted order.
It shows the scopes the given variables are set in, along with the values in each and whether or not it is exported.
No other flags can be used with this option.
**-L** or **--long**
Do not abbreviate long values when printing set variables.
@@ -85,38 +108,48 @@ The following other options are available:
**-h** or **--help**
Displays help about using this command.
If a variable is set to more than one value, the variable will be a list with the specified elements. If a variable is set to zero elements, it will become a list with zero elements.
If a variable is set to more than one value, the variable will be a list with the specified elements.
If a variable is set to zero elements, it will become a list with zero elements.
If the variable name is one or more list elements, such as ``PATH[1 3 7]``, only those list elements specified will be changed. If you specify a negative index when expanding or assigning to a list variable, the index will be calculated from the end of the list. For example, the index -1 means the last index of a list.
If the variable name is one or more list elements, such as ``PATH[1 3 7]``, only those list elements specified will be changed.
If you specify a negative index when expanding or assigning to a list variable, the index will be calculated from the end of the list.
For example, the index -1 means the last index of a list.
The scoping rules when creating or updating a variable are:
- Variables may be explicitly set to universal, global or local. Variables with the same name in different scopes will not be changed.
- Variables may be explicitly set as universal, global, function, or local.
Variables with the same name but in a different scope will not be changed.
- If a variable is not explicitly set to be either universal, global or local, but has been previously defined, the previous variable scope is used.
- If the scope of a variable is not explicitly set *but a variable by that name has been previously defined*, the scope of the existing variable is used.
If the variable is already defined in multiple scopes, the variable with the narrowest scope will be updated.
- If a variable is not explicitly set to be either universal, global or local and has never before been defined, the variable will be local to the currently executing function. Note that this is different from using the ``-l`` or ``--local`` flag. If one of those flags is used, the variable will be local to the most inner currently executing block, while without these the variable will be local to the function. If no function is executing, the variable will be global.
- If a variable's scope is not explicitly set and there is no existing variable by that name, the variable will be local to the currently executing function.
Note that this is different from using the ``-l`` or ``--local`` flag, in which case the variable will be local to the most-inner currently executing block, while without them the variable will be local to the function as a whole.
If no function is executing, the variable will be set in the global scope.
The exporting rules when creating or updating a variable are identical to the scoping rules for variables:
- Variables may be explicitly set to either exported or not exported. When an exported variable goes out of scope, it is unexported.
- Variables may be explicitly set to either exported or not exported.
When an exported variable goes out of scope, it is unexported.
- If a variable is not explicitly set to be exported or not exported, but has been previously defined, the previous exporting rule for the variable is kept.
- If a variable is not explicitly set to be either exported or unexported and has never before been defined, the variable will not be exported.
In query mode, the scope to be examined can be specified. Whether the variable has to be a path variable or exported can also be specified.
In query mode, the scope to be examined can be specified.
Whether the variable has to be a path variable or exported can also be specified.
In erase mode, if variable indices are specified, only the specified slices of the list variable will be erased.
``set`` requires all options to come before any other arguments. For example, ``set flags -l`` will have the effect of setting the value of the variable :envvar:`flags` to '-l', not making the variable local.
``set`` requires all options to come before any other arguments.
For example, ``set flags -l`` will have the effect of setting the value of the variable :envvar:`flags` to '-l', not making the variable local.
Exit status
-----------
In assignment mode, ``set`` does not modify the exit status, but passes along whatever :envvar:`status` was set, including by command substitutions. This allows capturing the output and exit status of a subcommand, like in ``if set output (command)``.
In assignment mode, ``set`` does not modify the exit status, but passes along whatever :envvar:`status` was set, including by command substitutions.
This allows capturing the output and exit status of a subcommand, like in ``if set output (command)``.
In query mode, the exit status is the number of variables that were not found.
@@ -126,49 +159,58 @@ In erase mode, ``set`` exits with a zero exit status in case of success, with a
Examples
--------
::
Print all global, exported variables::
# Prints all global, exported variables.
set -xg
> set -gx
# Sets the value of the variable $foo to be 'hi'.
set foo hi
Set the value of the variable _$foo_ to be 'hi'.::
# Appends the value "there" to the variable $foo.
set -a foo there
> set foo hi
# Does the same thing as the previous two commands the way it would be done pre-fish 3.0.
set foo hi
set foo $foo there
Append the value "there" to the variable $foo::
# Removes the variable $smurf
set -e smurf
> set -a foo there
# Changes the fourth element of the $PATH list to ~/bin
set PATH[4] ~/bin
Remove _$smurf_ from the scope::
> set -e smurf
Remove _$smurf_ from the global and universal scoeps::
> set -e -Ug smurf
Change the fourth element of the $PATH list to ~/bin::
> set PATH[4] ~/bin
Outputs the path to Python if ``type -p`` returns true::
# Outputs the path to Python if ``type -p`` returns true.
if set python_path (type -p python)
echo "Python is at $python_path"
end
# Setting a variable doesn't modify $status!
false
set foo bar
echo $status # prints 1, because of the "false" above.
Setting a variable doesn't modify $status; a command substitution still will, though::
true
set foo banana (false)
echo $status # prints 1, because of the "(false)" above.
# Like other shells, pass a variable to just one command:
# Run fish with a temporary home directory.
HOME=(mktemp -d) fish
# Which is essentially the same as:
begin; set -lx HOME (mktemp -d); fish; end
> echo $status
0
> false
> set foo bar
> echo $status
1
> true
> set foo banana (false)
> echo $status
1
``VAR=VALUE command`` sets a variable for just one command, like other shells.
This runs fish with a temporary home directory::
> HOME=(mktemp -d) fish
(which is essentially the same as)::
> begin; set -lx HOME (mktemp -d); fish; end
Notes
-----
Fish versions prior to 3.0 supported the syntax ``set PATH[1] PATH[4] /bin /sbin``, which worked like
``set PATH[1 4] /bin /sbin``. This syntax was not widely used, and was ambiguous and inconsistent.
- Fish versions prior to 3.0 supported the syntax ``set PATH[1] PATH[4] /bin /sbin``, which worked like ``set PATH[1 4] /bin /sbin``.
``set_color`` is used to control the color and styling of text in the terminal. *VALUE* describes that styling. *VALUE* can be a reserved color name like **red** or a RGB color value given as 3 or 6 hexadecimal digits ("F27" or "FF2277"). A special keyword **normal** resets text formatting to terminal defaults.
``set_color`` is used to control the color and styling of text in the terminal. *VALUE* describes that styling. *VALUE* can be a reserved color name like **red** or an RGB color value given as 3 or 6 hexadecimal digits ("F27" or "FF2277"). A special keyword **normal** resets text formatting to terminal defaults.
Valid colors include:
@@ -32,7 +32,7 @@ The following options are available:
Sets the background color.
**-c** or **--print-colors**
Prints a list of the 16 named colors.
Prints the given colors or a colored list of the 16 named colors.
**-o** or **--bold**
Sets bold mode.
@@ -87,9 +87,9 @@ In particular it will:
If terminfo reports 256 color support for a terminal, 256 color support will always be enabled.
To force true-color support on or off, set :envvar:`fish_term24bit`` to "1" for on and 0 for off - ``set -g fish_term24bit 1``.
To force true-color support on or off, set :envvar:`fish_term24bit` to "1" for on and 0 for off - ``set -g fish_term24bit 1``.
To debug color palette problems, ``tput colors`` may be useful to see the number of colors in terminfo for a terminal. Fish launched as ``fish -d2`` will include diagnostic messages that indicate the color support mode in use.
To debug color palette problems, ``tput colors`` may be useful to see the number of colors in terminfo for a terminal. Fish launched as ``fish -d term_support`` will include diagnostic messages that indicate the color support mode in use.
The ``set_color`` command uses the terminfo database to look up how to change terminal colors on whatever terminal is in use. Some systems have old and incomplete terminfo databases, and lack color information for terminals that support it. Fish assumes that all terminals can use the [ANSI X3.64](https://en.wikipedia.org/wiki/ANSI_escape_code) escape sequences if the terminfo definition indicates a color below 16 is not supported.
@@ -43,7 +44,7 @@ The following operations (subcommands) are available:
Returns 0 if fish is currently executing a block of code.
**is-breakpoint**
Returns 0 if fish is currently showing a prompt in the context of a :ref:`breakpoint <cmd-breakpoint>` command. See also the :ref:`fish_breakpoint_prompt <cmd-fish_breakpoint_prompt>` function.
Returns 0 if fish is currently showing a prompt in the context of a :doc:`breakpoint <breakpoint>` command. See also the :doc:`fish_breakpoint_prompt <fish_breakpoint_prompt>` function.
**is-interactive**, **-i** or **--is-interactive**
Returns 0 if fish is interactive - that is, connected to a keyboard.
@@ -63,8 +64,11 @@ The following operations (subcommands) are available:
**current-command**
Prints the name of the currently-running function or command, like the deprecated :envvar:`_` variable.
**current-commandline**
Prints the entirety of the currently-running commandline, inclusive of all jobs and operators.
**filename**, **current-filename**, **-f** or **--current-filename**
Prints the filename of the currently-running script. If the current script was called via a symlink, this will return the symlink. If the current script was received by piping into :ref:`source <cmd-source>`, then this will return ``-``.
Prints the filename of the currently-running script. If the current script was called via a symlink, this will return the symlink. If the current script was received by piping into :doc:`source <source>`, then this will return ``-``.
**basename**
Prints just the filename of the running script, without any path components before.
@@ -73,7 +77,7 @@ The following operations (subcommands) are available:
Prints just the path to the running script, without the actual filename itself. This can be relative to :envvar:`PWD` (including just "."), depending on how the script was called. This is the same as passing the filename to ``dirname(3)``. It's useful if you want to use other files in the current script's directory or similar.
**fish-path**
Prints the absolute path to the currently executing instance of fish.
Prints the absolute path to the currently executing instance of fish. This is a best-effort attempt and the exact output is down to what the platform gives fish. In some cases you might only get "fish".
**function** or **current-function**
Prints the name of the currently called function if able, when missing displays "Not a function" (or equivalent translated string).
``string join`` joins its *STRING* arguments into a single string separated by *SEP*, which can be an empty string. Exit status: 0 if at least one join was performed, or 1 otherwise.
``string join`` joins its *STRING* arguments into a single string separated by *SEP*, which can be an empty string. Exit status: 0 if at least one join was performed, or 1 otherwise. If ``-n`` or ``--no-empty`` is specified, empty strings are excluded from consideration (e.g. ``string join -n + a b "" c`` would expand to ``a+b+c`` not ``a+b++c``).
``string join0`` joins its *STRING* arguments into a single string separated by the zero byte (NUL), and adds a trailing NUL. This is most useful in conjunction with tools that accept NUL-delimited input, such as ``sort -z``. Exit status: 0 if at least one join was performed, or 1 otherwise.
``string shorten`` truncates each *STRING* to the given visible width and adds an ellipsis to indicate it. "Visible width" means the width of all visible characters added together, excluding escape sequences and accounting for :envvar:`fish_emoji_width` and :envvar:`fish_ambiguous_width`. It is the amount of columns in a terminal the *STRING* occupies.
The escape sequences reflect what fish knows about, and how it computes its output. Your terminal might support more escapes, or not support escape sequences that fish knows about.
If **-m** or **--max** is given, truncate at the given width. Otherwise, the lowest non-zero width of all input strings is used. A max of 0 means no shortening takes place, all STRINGs are printed as-is.
If **-N** or **--no-newline** is given, only the first line (or last line with **--left**) of each STRING is used, and an ellipsis is added if it was multiline. This only works for STRINGs being given as arguments, multiple lines given on stdin will be interpreted as separate STRINGs instead.
If **-c** or **--char** is given, add *CHAR* instead of an ellipsis. This can also be empty or more than one character.
If **-l** or **--left** is given, remove text from the left on instead, so this prints the longest *suffix* of the string that fits. With **--no-newline**, this will take from the last line instead of the first.
If **-q** or **--quiet** is given, ``string shorten`` only runs for the return value - if anything would be shortened, it returns 0, else 1.
The default ellipsis is ``…``. If fish thinks your system is incapable because of your locale, it will use ``...`` instead.
The return value is 0 if any shortening occured, 1 otherwise.
.. END DESCRIPTION
Examples
--------
.. BEGIN EXAMPLES
::
>_ string shorten foo foobar
# No width was given, we infer, and "foo" is the shortest.
foo
fo…
>_ string shorten --char="..." foo foobar
# The target width is 3 because of "foo",
# and our ellipsis is 3 too, so we can't really show anything.
# This is the default ellipsis if your locale doesn't allow "…".
foo
...
>_ string shorten --char="" --max 4 abcdef 123456
# Leaving the char empty makes us not add an ellipsis
# So this truncates at 4 columns:
abcd
1234
>_ touch "a multiline"\n"file"
>_ for file in *; string shorten -N -- $file; end
# Shorten the multiline file so we only show one line per file:
a multiline…
>_ ss -p | string shorten -m$COLUMNS -c ""
# `ss` from Linux' iproute2 shows socket information, but prints extremely long lines.
# This shortens input so it fits on the screen without overflowing lines.
``string split`` splits each *STRING* on the separator *SEP*, which can be an empty string. If **-m** or **--max** is specified, at most MAX splits are done on each *STRING*. If **-r** or **--right** is given, splitting is performed right-to-left. This is useful in combination with **-m** or **--max**. With **-n** or **--no-empty**, empty results are excluded from consideration (e.g. ``hello\n\nworld`` would expand to two strings and not three). Exit status: 0 if at least one split was performed, or 1 otherwise.
Use **-f** or **--fields** to print out specific fields. Unless **--allow-empty** is used, if a given field does not exist, then the command exits with status 1 and does not print anything.
Use **-f** or **--fields** to print out specific fields. FIELDS is a comma-separated string of field numbers and/or spans. Each field is one-indexed, and will be printed on separate lines. If a given field does not exist, then the command exits with status 1 and does not print anything, unless **--allow-empty** is used.
See also the **--delimiter** option of the :ref:`read <cmd-read>` command.
See also the **--delimiter** option of the :doc:`read <read>` command.
``string split0`` splits each *STRING* on the zero byte (NUL). Options are the same as ``string split`` except that no separator is given.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
