The POSIX standard specifies that a buffer should be supplied to
getcwd(), not doing so is undefined (or rather, platform-defined)
behavior. This was causing the getcwd errors on illumos (though not seen
on Solaris 11) reported in #3340Closes#3340
Took care of remaining issues preventing fish from building on Solaris.
Mainly caused by some assumptions that certain defines are POSIX when
they are not (`NAME_MAX`).
Moved `NAME_MAX` defines to common.h - for some reason, it was being
defined in a cpp file (`env_universal_common.cpp`) even though it is used
in multiple source files.
Now compiles on Solaris 11 with GNU Make. Still some warnings because
fish was written with GNU getopt in mind and the Solaris version doesn't
use `const char *` but rather just `char *` for getopt values, but it
builds nevertheless.
Assuming this closes#3340
We had pid_status defined as a pid_t instance, which was fine since on
most platforms pid_t is an alias for int. However, that is not
universally the case and waitpid takes an int *, not a pid_t *.
A completion may have zero length; in this case the length of the
prefix was omitted and the completion was not visible. Correct the
calculation to account for zero-width completions.
Fixes#4424
A recent discussion involving whether `can_be_encoded()` was broken
caused me to notice that we are inconsistent about whether Unicode code
points are specified using `\xXXXX` or `\uXXXX` notation. Which is
harmless but silly and potentially confusing.
This flag was only documented for a few weeks before being renamed
`--show-time` and has been deprecated for a long time. Fish 3.0 is a good
opportunity to remove it.
Instead of treating the search term as a literal string to be matched
treat it as a glob. This allows the user to get a more useful set of
results by using the `*` glob character in the search term.
Partial fix for #3136
* Implement `history search --reverse`
It should be possible to have `history search` output ordered oldest to
newest like nearly every other shell including bash, ksh, zsh, and csh.
We can't make this the default because too many people expect the
current behavior. This simply makes it possible for people to define
their own abbreviations or functions that provide behavior they are
likely used to if they are transitioning to fish from another shell.
This also fixes a bug in the `history` function with respect to how it
handles the `-n` / `--max` flag.
Fixes#4354
* Fix comment for format_history_record()
As discussed in #3805, this patch disables assigning fish to its own
process group at startup. This was trialled in #4349 alongside other
pgrp fixes which introduced additional problems, but this particular fix
seems to be OK.
Fixes#3805 and works around Microsoft/BashOnWindows#1653
* Hoist `for` loop control var to enclosing scope
It should be possible to reference the last value assigned to a `for`
loop control var when the loop terminates. This makes it easier to detect
if we broke out of the loop among other things. This change makes fish
`for` loops behave like most other shells.
Fixes#1935
* Remove redundant line
The type cached_esc_sequences_t caches escape sequences, and is tasked
with finding an escape sequence that prefixes a given string. Before
this fix, it did so by storing the lengths of cached escape sequences,
and searching for substrings of that length. The new implementation
instead stores all cached escape sequences in a sorted vector, and uses
binary search to find the shortest escape sequence that is a prefix of
the input. This is a substantial simplification that also reduces
allocations.
This eliminates the "missing" notion of env_var_t. Instead
env_get returns a maybe_t<env_var_t>, which forces callers to
handle the possibility that the variable is missing.
maybe_t is an implementation of the Maybe/Optional type, allowing
for an optional value to be stored. This will enable a more
principled approach for functions that return values or failure,
such as env_get.
This commit backs out certain optimizations around setting environment
variables, and replaces them with move semantics. env_set accepts a
list, by value, permitting callers to use std::move to transfer
ownership.
Commit f872f25f introduced a freed memory access regression on line 460
of env.cpp, where an environment variable was converted to a temporary
string, the .c_str() address of which was stored while the string
temporary was destroyed.
This commit keeps a reference to the original string lying around so
that the c_str() pointer does not point to freed memory.
Valgrind warns that the sometimes uninitialized sigaction.sa_flags field
is sometimes used when passed to the signal handler.
This patch explicitly zeros out the sigaction.sa_flags field at creation
time.
cherry-picked from krader1961/fish-shell commit b69df4fe72
Fixes#4353 (regression in indexing of history contents) and introduces
new unit tests to catch bad $history indexing in the future.
This implements an LRU cache of recently seen math expressions. When
executing math inside loops and the like this can provide a 33% decrease
in the time to execute the `math` command.
We need our `math` builtin to behave like `bc` with respect to rounding
floating point values to integer to avoid breaking to many existing
uses. So when scale is zero round down to the nearest integer.
Another change for #3157.
The MuParser supports the concept of multiple expressions separated by
commas. This implements support for that so that you can do things like
this:
set results (math '1+1, 4*2, 9^2')
This is the second baby step in resolving #3157. Implement a bare minimum
builtin `math` command. This is solely to ensure that fish can be built
and run in the Travis build environments. This is okay since anyone running
`builtin math` today is already getting an error response.
Also, more work is needed to support bare var references, multiple result
values, etc.
Using a read-only variable like `status` as a for loop control variable
has never worked. But without this change you simply get non-sensical
behavior that leaves you scratching your head in puzzlement. This change
replaces the non-sensical behavior with an explicit error message.
Fixes#4342
Recent changes to switch to unordered sets/maps can cause the order in
which items are returned to be non-deterministic. This change ensures
that the argparse "Mutually exclusive flags" error message to be
deterministic with respect to the order of the interpolated values.
Make setting fish vars more efficient by avoiding creating a
wcstring_list_t for the case where we're setting one value. For the case
where we're passing a list of values swap it with the list in the var
rather than copying it. This makes the benchmark in #4200 approximately
6% faster.
Since we are including XXHash32/64 anyway for the wchar_t* hashing,
we might as well use it.
Use arch-specific hash size and xxhash for all wcstring hashing
Instead of using XXHash64 for all platforms, use the 32-bit version
when running on 32-bit platforms where XXHash64 is significantly slower
than XXHash32 (and the additional precision will not be used).
Additionally, manually specify wcstring_hash as hashing method for
non-const wcstring unordered_set/map instances (the const varieties
don't have an in-library hash and so already use our xxhash-based
specialization when calling std::hash<const wcstring>).
commit 50f414a45d58fcab664ff662dd27befcfa0fdd95
Author: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
Date: Sat Aug 19 13:43:35 2017 -0500
Converted file_id_t set to unordered_set with custom hash
commit 83ef2dd7cc1bc3e4fdf0b2d3546d6811326cc3c9
Author: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
Date: Sat Aug 19 13:43:14 2017 -0500
Converted remaining set<wcstring> to unordered_set<wcstring>
commit 053da88f933f27505b3cf4810402e2a2be070203
Author: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
Date: Sat Aug 19 13:29:21 2017 -0500
Switched function sets to unordered_set
commit d469742a14ac99599022a9258cda8255178826b5
Author: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
Date: Sat Aug 19 13:21:32 2017 -0500
Converted list of modified variables to an unordered set
commit 5c06f866beeafb23878b1a932c7cd2558412c283
Author: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
Date: Sat Aug 19 13:15:20 2017 -0500
Convert const_string_set_t to std::unordered_set
As it is a readonly-list of raw character pointer strings (not
wcstring), this necessitated the addition of a hashing function since
the C++ standard library does not come with a char pointer hash
function.
To that end, a zlib-licensed [0] port of the excellent, lightweight
XXHash family of 32- and 64-bit hashing algorithms in the form of a C++
header-only include library has been included. XXHash32/64 is pretty
much universally the fastest hashing library for general purpose
applications, and has been thoroughly vetted and is used in countless
open source projects. The single-header version of this library makes it
a lot simpler to include in the fish project, and the license
compatibility with fish' GPLv2 and the zero-lib nature should make it an
easy decision.
std::unordered_set brings a massive speedup as compared to the default
std::set, and the further use of the fast XXHash library to provide the
string hashing should make all forms of string lookups in fish
significantly faster (to a user-noticeable extent).
0: http://create.stephan-brumme.com/about.html
commit 30d7710be8f0c23a4d42f7e713fcb7850f99036e
Author: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
Date: Sat Aug 19 12:29:39 2017 -0500
Using std::unordered_set for completions backing store
While the completions shown to the user are sorted, their storage in
memory does not need to be since they are re-sorted before they are
shown in completions.cpp.
commit 695e83331d7a60ba188e57f6ea0d9b6da54860c6
Author: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
Date: Sat Aug 19 12:06:53 2017 -0500
Updated is_loading to use unordered_set
No longer using RAII wrappers around pthread_mutex_t and pthread_cond_t
in favor of the C++11 std::mutex, std::recursive_mutex, and
std::condition_variable data types.
The `react_to_variable_change()` function is called whenever a fish var
is set. Even as a consequence of statements like `for x in a b c`. It is
therefore critical that that function be as fast as possible. Especially
when setting the var doesn't have any side-effects which is true something
like 99.9999% of the time.
This change reduces the overhead of `react_to_variable_change()` to
unmeasurable levels. Making the synthetic benchmark in issue #4341
36% faster.
Fixes#4341
Internally fish should store vars as a vector of elements. The current
flat string representation is a holdover from when the code was written
in C.
Fixes#4200
A semi-empty var is one with a single empty string element. The
`env_var_t::empty()` method returns true for such vars but we want
`set --show` to report that it has a single empty element.
Newer versions of GCC and Clang are not satisfied by a cast to void,
this fix is adapted from glibc's solution.
New wrapper function ignore_result should be used when a function with
explicit _unused_attribute_ wrapper is called whose result will not be
handled.
Make the `env_var_t::missing_var()` object a singleton rather than a
dynamically constructed object. This requires some discipline in its use
since C++ doesn't directly support immutable objects. But it is slightly
more efficient and helps identify code that incorrectly mutates `env_var_t`
objects that should not be modified.
It's bugged me forever that the scope is the second arg to `env_get()`
but not `env_set()`. And since I'll be introducing some helper functions
that wrap `env_set()` now is a good time to change the order of its
arguments.
My previous change to eliminate `class var_entry_t` caused me to notice
that `env_get()` turned a set but empty var into a missing var. Which
is wrong. Fixing that brought to light several other pieces of code that
were wrong as a consequence of the aforementioned bug.
Another step to fixing issue #4200.
* Fix clearing abandoned line with VTE
With VTE-based terminals, resizing currently causes multi-line prompts
to go weird.
This changes the sequence we use to clear the line to one suggested by
a VTE
developer (https://bugzilla.gnome.org/show_bug.cgi?id=763390#c4).
It changes nothing in konsole 17.04.3 and urxvt 9.22, but they already
work.
Note that this does not fix the case where output did not end in a
newline, but that doesn't seem to be up to us. Also, it only affects
those lines.
Fixes#2320.
* Use terminfo definition instead of hardcoding
Thanks to @ixjlyons.
Doing `set -U var` when a global named `var` exists can result in
confusing behavior. Try to limit the confusion by improving the warning
we write. Also, only write the warning if interactive.
Fixes#4267
The process_t pointer sent to setup_child_process can actually be 0
without it being failure, as that is what fish sends when `exec` is run
(in the case of INTERNAL_EXEC).
This was causing exec to fail.
There is no more race condition between parent and child with
regards to setting the process groups. Each child sets it for themselves
and then blocks indefinitely until the parent does what it needs to for
them (having waited for them to set their process groups). They are not
SIGCONT'd until the next process in the chain (if any) starts so that
that process can join their process group and open the pipes.
In the last commit, we introduced an indiscriminate if !EXTERNAL check
that unblocks a previously SIGSTOP'd command (if any) to allow the main
loop in exec_job to read from it without deadlocking (since builtins and
functions read directly from input as an optimization, sometimes).
Now only unblocking where a fork will not happen to ensure that if a
builtin ends up forking, that fork'd process is guaranteed to be able to
join the previous process' process group and access its output pipes.
Setting the process group in a fork/exec scenario is a well-documented
race condition in pretty much any job control mechanism [0] [1]. The
Wikipedia article contradicts the glibc article and suggests that the
best approach is for the parent to wait for the child to become the
process group leader, while the glibc article suggests that both should
make it so (which is what fish did previously). However, I'm running
into cases where tcsetpgrp is causing an EPERM error, which it isn't
documented to do except if the session id for the calling process
differs from that of the target process group (which is never the case
in fish since they are all part of the same session), which should cause
a _different_ error (SIGTTOU to be sent to all members of the calling
process' group).
In all cases, this is easily remedied by checking if the process group
in question is already in control of the terimnal. There's still the
off-chance that in the time between we check that and the time that the
command completes that situation may have changed, but the parent
process is supposed to ignore the result of this call if it errors out.
[0]: https://en.wikipedia.org/wiki/Process_group
[1]: https://www.gnu.org/software/libc/manual/html_node/Launching-Jobs.html
We were having child processes SIGSTOP themselves immediately after
setting their process group and before launching their intended targets,
but they were not necessarily stopped by the time the next command was
being executed (so the opposite of the original race condition where
they might have finished executing by the time the next command came
around), and as a result when we sent them SIGCONT, that could never
reach. Now using waitpid to synchronize the SIGSTOP/SIGCONT between the
two.
If we had a good, unnamed inter-process event/semaphore, we could use
that to have a child process conditionally stop itself if the next
command in the job chain hadn't yet been started / setup, but this is
probably a lot more straightforward and less-confusing, which isn't a
bad thing.
Additionally, there was a bug caused by the fact that the main exec_job
loop actually blocks to read from previous commands in the job if the
current command is a built-in that doesn't need to fork.
With this waitpid code, I was able to finally add the SIGSTOP code to
all the fork'd processes in the main exec_job loop without introducing
deadlocks; it turns out that they should be treated just like the main
EXTERNAL fork, but they tend to execute faster causing the same deadlock
described above to occur more readily.
The only thing I'm not sure about is whether we should execute
unblock_pid undconditionally for all !EXTERNAL commands. It makes more
sense to *only* do that if a blocking read were about to be done in the
main loop, otherwise the original race condition could still appear
(though it is probably mitigated by whatever duration the SIGSTOP lasted
for, even if it is SIGCONT'd before the next command tries to join the
process group).
