CMake seems to have trouble finding libraries from multiarch packages
that do not have the compatibility symlink installed to the
arch-independent library directory. Users must either manually supply
the path to the library in question via command-line parameters or we
can fall back to CMake's alternate method of finding packages based off
of pkg-config rather than using the hard-coded `FindCurses` CMake module
specific to the CMake version/distribution installed.
e4b6007f33 introduced the following warning:
configure.ac:327: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
Fix by using the right autoconf macros for the job.
Turns out busybox diff (used on alpine) defaults to unified output,
which we can't use because that prints filenames, and those are
tempfiles made by psub.
Instead, we use builtins to print the first line and compare the others.
This isn't all that important, and it breaks on musl just because the message is different.
Just skip it for now, until we figure out how to better test this.
This `set TERM`. Which, if $TERM is inherited, is already exported,
but not if it isn't.
This is the case on sr.ht's arch images, so we failed without a TERM variable.
This checks if uname exists (we already call it elsewhere without
check, nobody has complained, uname is in POSIX), then calls to see if
it's "Linux", and only then offers any completions.
Since we don't have any other version to offer, the check is worse
than useless.
This helps on netbsd, because enter_standout_mode et al are const
there.
These methods don't alter their argument, so they should have been
const to begin with.
This is non-const on macOS, but some of the args we pass are always
const on netbsd.
I have no idea why you'd ever want this to modify its argument, but whatever.
This is the more correct fix for #5447, as regardless of which process
in the job (be it the first or the last) finished first, once we have
waited on a process without ~WNOHANG we don't do that for any subsequent
processes in the job.
It is also a waste to call into the kernel to wait for a process we
already know is completed!
@ridiculousfish had introduced this in 3a45cad12e
to work around an issue with Coverity Scan where it couldn't tell the
mutex was correctly locked, but even with the `fish_mutex_t` hack, it
still emits the same warnings, so there's no pointing in keeping it.
This is necessary for the history race condition test to succeed.
(That test is permanently disabled under WSL (as it always fails) so I
didn't catch this on my end.)
Use `pthread_atfork()` to mark child processes as dirty when `fork()` is
invoked rather than needing to call into the kernel each time
`ASSERT_IS_NOT_FORKED_CHILD()` is called.
This makes simple test cases that hit `ASSERT_IS_NOT_FORKED_CHILD()` 1.8x faster.
------------------------
With a7998c4829 reverted but before this optimization:
```
mqudsi@ZBOOK ~/r/fish-shell> hyperfine -S build/fish 'for i in (seq 100000); test 1 = 1; end'
Benchmark #1: for i in (seq 100000); test 1 = 1; end
Time (mean ± σ): 717.8 ms ± 14.9 ms [User: 503.4 ms, System: 216.2 ms]
Range (min … max): 692.3 ms … 740.2 ms
```
With a7998c4829 reverted and with this optimization:
```
mqudsi@ZBOOK ~/r/fish-shell> hyperfine -S build/fish 'for i in (seq 100000); test 1 = 1; end'
Benchmark #1: for i in (seq 100000); test 1 = 1; end
Time (mean ± σ): 397.2 ms ± 22.3 ms [User: 322.1 ms, System: 79.3 ms]
Range (min … max): 376.0 ms … 444.0 ms
```
Without a7998c4829 reverted and with this optimization:
mqudsi@ZBOOK ~/r/fish-shell> hyperfine -S build/fish 'for i in (seq 100000); test 1 = 1; end'
Benchmark #1: for i in (seq 100000); test 1 = 1; end
Time (mean ± σ): 423.4 ms ± 51.6 ms [User: 363.2 ms, System: 61.3 ms]
Range (min … max): 378.4 ms … 541.1 ms
```
By using a user-land thread-local integer and lock-free (at least under
x86/x64) atomics, we can implement a safe `assert_is_main_thread()`
without calling into the kernel. Thread-local variables are part of
C++11.
This is called a lot in some performance-sensitive areas, so it is worth
optimizing.
This fixes#5438 by having fish block while waiting on a foreground job
via its individual processes by enumerating the procs in reverse order,
such that we hang waiting for the last job in the IO chain to terminate,
rather than the first.
If it's a foreground job, it is related to the currently running exec.
This fixes exec in functions, i.e.
function reload
exec fish
end
would previously always ask about the "function reload" job.
Fixes#5449.
Fixesoh-my-fish/oh-my-fish#664.
