jobs -p %1 prints all processes in the first job.
fg is special because it only takes one argument. Using the last process
in the pipeline works for the cases I can think of.
Fixes#7406
Previously, when a command wasn't found, fish would emit the
"fish_command_not_found" *event*.
This was annoying as it was hard to override (the code ended up
checking for a function called `__fish_command_not_found_handler`
anyway!), the setup was ugly,
and it's useless - there is no use case for multiple command-not-found handlers.
Instead, let's just call a function `fish_command_not_found` if it
exists, or print the default message otherwise.
The event is completely removed, but because a missing event is not an error
(MEISNAE in C++-speak) this isn't an issue.
Note that, for backwards-compatibility, we still keep the default
handler function around even tho the new one is hard-coded in C++.
Also, if we detect a previous handler, the new handler just calls it.
This way, the backwards-compatible way to install a custom handler is:
```fish
function __fish_command_not_found_handler --on-event fish_command_not_found
# do a little dance, make a little love, get down tonight
end
```
and the new hotness is
```fish
function fish_command_not_found
# do the thing
end
```
Fixes#7293.
This allows us to send proper debug messages via FLOG, and it removes
more things from share/config.fish.
Note that the logic differs in some subtle ways. For instance it will
now obey $COLORTERM, so if that isn't "truecolor" or "24bit" it will
deactivate truecolor.
a) they can screw up our expected output/behavior
b) they can blow up your system
In my case, the unit tests were calling Pantheon's fish integration
script which would then proceed to blow up dbus with messages about each
individual test completing.
Fixes#6556.
Although present since 2006, fish no longer relies on POSIX-compliant tools to the same degree. This
code causes a platform specific change that makes the tests fail, so remove it.
We'd use $__fish_data_dir, but that already had the "/fish" component,
and then we'd add it again later, so we would try to find vendor
functions in places like
/usr/share/fish/fish/vendor_functions.d
which obviously don't exist.
Instead let's add the "/fish" component to the xdg dirs early, which
also saves us from having to repeat it later.
Fixes#6428
See #6508
[ci skip]
$XDG_DATA_DIRS/vendor_{completions,conf,functions}.d
Additionally, CMake variables extra_{completions,conf,functions}dir are
appended, if they are not already contained in $XDG_DATA_DIRS.
If XDG_DATA_DIRS is not defined, we fall back to
$__fish_datadir/vendor_completions.d:${extra_completionsdir}
for completions. Same for conf and functions.
This variable holds an integer that resembles the fish version up to
that initializations were performed. It should be incremented whenever
some new initialization is required after upgrading fish. This should
not change the behavior for existing fish installations, except for a
minor message on installations that upgrade from fish<2.3.0.
[ci skip]
Previously, elements already existing in the path variable would keep their position when the path was being constructed from the config files. This caused issues given that $PATH typically already contains "/usr/bin:/bin" when fish initializes within a macOS terminal app. In this case, these would keep their position at the front of the $PATH, even though the system path_helper configs explicitly place them _after_ other paths, like "/usr/local/bin". This would render binaries in "/usr/local/bin" as effectively "invisible" if they also happen to live in "/usr/bin" as well. This is not the intended
This change makes the __fish_macos_set_env config function emulate the macOS standard path_helper behavior more faithfully, with:
1. The path list being constructed *from scratch* based on the paths specified in the config files
2. Any distinct entries in the exist path environment variable being appended to this list
3. And then this list being used to *replace* the existing path environment variable
The result, for a vanilla fish shell on macOS, is that the $PATH is now set to:
/usr/local/bin /usr/local/sbin /usr/bin /bin /usr/sbin /sbin
Where previously it was set to:
/usr/bin /bin /usr/local/bin /usr/sbin /sbin
This new $PATH exactly matches the order of paths specified in `/etc/paths`.
Matches upstream path_helper which is invoked in /etc/profile and only
applies to login shells. Enables running interactive, non-login shells
with altered PATH values.
Reverts change in c0f832a7, which reverts change in adbaddf.
Our weird %-expanding function wrappers around kill et all defined
"--wraps" for the same name.
As it turns out, fish follows that one, and executes the completion
multiple times.
I didn't notice because these tend to be rather quick on linux, but on
macOS that's apparently a real issue.
Fixes#5541.
[ci skip]
Cleaned up the code to no longer replicate in fishscript what fish
already does (and caches to boot) in C++ in setting up the paths to the
user configuration directory.
Also introduced a `$__fish_user_data_dir` instead of the sporadic
definitions of `$userdatadir` that may or may not go through
`XDG_DATA_HOME`.
This allows snippets to use everything that is defined in config.fish,
which is our _base_ initialization.
Among other things, it enables snippets to use $PATH as it will appear
in the user's config.fish, or even to change $PATH.
Also, this is how it was in 2.7.1 and before (with the small change
that abbrs were upgraded after).
The job expansion wrapper was swallowing `-n` (and presumably `-e` and
others) when that was the literal argument we needed to emit. Using
`printf %s ...` instead.
fish reads paths out of /etc/paths.d. Prior to adbaddf it did
this on every shell invocation; with adbaddf it does so on only login
shells. This change wasn't justified so let's revert this behavior.
(and /etc/paths.d/*)
Do so by emulating the behavior of /usr/libexec/path_helper for login
shells, matching the behavior in /etc/profile.
Also add a path_helper command to reproduce the behavior of
/usr/libexec/path_helper for fish.
This also handles setting MANPATH if necessary.
Fixes issue #4336
