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.
There should be just one place that calls `setupterm()`. While refactoring
the code I also decided to not make initializing the curses subsystem a
fatal error. We now try two fallback terminal names ("ansi" and "dumb")
and if those can't be used we still end up with a usable shell.
Fixes#3850
Before defining fallback functions of wcsdup(), wcscasecmp() and
wcsncasecmp(), use the std:: namespace functions instead if they exist.
0019c12af3 fixed the build on Solaris 10, but broke it on Solaris 11.
This is a terminal feature where pastes will be "bracketed" in
\e\[200~ and \e\[201~.
It is more of a "security" measure (since particularly copying from a
browser can copy text different from what the user sees, which might
be malicious) than a performance optimization.
Work towards #967.
Some platforms ship the headers and libraries for ncurses in different
packages, which can produce false positives when checking for their
presence.
Closes#3866.
I have noticed that too many new issues have not used the issue template
in the expected manner. Primarily because most people opening issues are
not accustomed to Github Markdown syntax. So change the template to be
exclusively a comment that provides advice regarding what information
will help the fish community resolve a issue.
This reverts commit e30f3fee88.
Not sure why I didn't notice this before merging it but the change I'm
reverting makes it impossible to start a login shell.
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 is a lot more confidence this change doesn't cause major problems
prior to the next minor release.
The `make style` and `make style-all` commands have been performing well
without glitches for long enough that it is no longer necessary to report
when they don't change the style of a file. Especially in light of the
fact that all the relevant code has been restyled in the past year. This
change makes `make style-all` much less noisy.
