Switch from null terminated arrays to `wcstring_list_t` for lists of
special env var names. Rename `list_contains_string` to `contains` and
modify the latter interface to not rely on a `#define`.
Rename `list_contains_string()` to `contains()` and eliminate the
current variadic implementation. Update all callers of the removed
version to use the string list version.
There are at least three env vars describing a sequence of paths to be
searched where an empty path element is implicitly equivalent to ".".
This change converts the implicit "." to explicit whenever the variable
is imported or set. This makes the variable much easier to use in fish
scripts.
Fixes#3914
- Error out if anything that is not a PID is given
- Otherwise background all matching existing jobs, even if not all
PIDs exist (but print a message for the non-existing ones)
Fixes#3909.
We've gotten feedback from the Stackexchange team that too many fish
questions asked on stackoverflow don't really belong there. So clarify
the README to also point users at superuser for questions not related to
fish script.
A call to default_vars_path() takes the environment variable
lock while the uvars lock is held. Ensure that doesn't happen by
deferring the uvars lock to later in the function.
cached_esc_sequences_t::find_entry was constructing a wcstring
from a c string, using lengths longer than the length of the cstring.
Detected with asan.
In the process of fixing the issue I decided it didn't make sense to
have two, incompatible, ways of converting variable strings to arrays.
Especially since the one I'm removing does not return empty array elements.
Fixes#2106
This is to make pasting literals easier.
When a user pastes something, we normally take it as-is.
The exception is when a single-quote is open, e.g. the current token
is
foo'bar
When something is pasted here, we escape single-quotes (`'`) and
backslashes (`\\`), so typing a `'` after it will turn it into a
literal token.
Fixes#967.
This is the next step in determining whether we can disable blocking
signals without a good reason to do so. This makes not blocking signals
the default behavior. If someone finds a problem they can add this to
their ~/config/fish/config.fish file:
set FISH_NO_SIGNAL_BLOCK 0
Alternatively set that env var before starting fish. I won't be surprised
if people report problems. Till now we have relied on people opting in
to this behavior to tell us whether it causes problems. This makes the
experimental behavior the default that has to be opted out of. This will
give us a lot more confidence this change doesn't cause problems before
the next minor release.
Note that there are still a few places where we force blocking of
signals. Primarily to keep SIGTSTP from interfering with the shell in
response to manipulating the controlling tty. Bash is more selective
in the signals it blocks around the problematic syscalls (c.f., its
`git_terminal_to()` function). However, I don't see any value in that
refinement.
