OCLINT was ignoring this, but we can just not do the bad thing.
Declare argc and argv const. These are in the stack, they can
be modified, but we won't.
Fix a typo
... rather than hard code it to "fish". This affects
what is found in $_ and improves the errors:
For example, if fish was ran with ./fish, instead of
something like:
fish: Expected 3 surprises, only got 2 surprises
we'll see:
./fish: Expected 3 surprises, only got 2 surprises
like most other shell utilities. It's just a tiny bit
of detail that can avoid confusion.
This broke fishtape, which did
somestuff | fish -c "source"
Because `source` didn't have a redirection, it refused to read from
stdin.
So, to keep the common issue of `source (command that does not print)`
from seeminly stopping fish, we instead actually check if stdin is a terminal.
This was causing problems if "fish" wasn't in exec_path, like
if the binary had been renamed.
I also noticed that even with 'fish' not renamed, only paths.data
was made relative to my source tree. paths.sysconf, paths.doc, and
paths.bin were all relative to /usr/local.
This had a bunch of "do_{backward,forward}" movements that differed
only in one argument.
Just keep them together, so it's less code, and less needs to be
changed.
If the user is in a directory which has been unlinked, it is possible
for the path .. to not exist, relative to the working directory.
Always pass in the working directory (potentially virtual) to
path_get_cdpath; this ensures we check absolute paths and are immune
from issues if the working directory has been unlinked.
Also introduce a new function path_normalize_for_cd which normalizes the
"join point" of a path and a working directory. This allows us to 'cd' out of
a non-existent directory, but not cd into such a directory.
Fixes#5341
realpath() will return NULL and sets errno if it fails.
We asserted that realpath(".") does not fail. We also didn't really
check that it was successful. Made sure we'll get a perror telling
us about what went wrong if something like this happens again.
Updated tests and added test case
Fixes#5351
If fish detects that it was started with a pgrp of 0 (which appears to
oddly be the case when run under firejail), create new process group for
fish and give it control of the terminal.
This selectively reverts 55b3c45 in cases where an invalid pgrp is
detected. Note that this is known to cause problems in other cases, such
as #3805 and Microsoft/WSL#1653, although the former may have been
ameliorated or even addressed by the recent job control overhaul, so
that's why we are careful to only assign fish to its own pgroup if an
invalid pgroup was detected and not as the normal case.
This reverts commit 54050bd4c5.
Type job_list_t was changed from a list to a deque in
commit 54050bd4c5.
In process_clean_after_marking(), we remove jobs while iterating.
dequeues do not support that. Make it a list again.
This fixes the `~floam/` case, where the out_tail_idx pointer needs to
point to the "/", not the last letter.
The `~/` and `~floam` cases still work.
Unfortunately, I'm unsure of how to test this.
Fixes#5325.
Limit the fish_wcstod fast path to ASCII digits only, to fix the problem
observed in the discussion for a700acadfa
where LANG=de_DE.UTF-8 would cause `test` to interpret commas instead of
periods inside floating point values.
Now jobs are aware of their parent jobs, and can interrogate those jobs,
to determine if every job in the chain is fully constructed.
Remove flags and the static stacks that manipulated them.
The parent of a job is the parent pipeline that executed the function or
block corresponding to this job. This will help simplify
process_mark_finished_children().
Prior to this fix, cding into a symlink and then completing .. would complete
from the physical directory instead of the logical directory, which could not
actually be cd'd to. Teach cd completiond to use the logical directory.
select_try() returned IO_ERROR to indicate that there's no file descriptors
from which to read. Name this return value properly.
Also migrate this type into proc.cpp since it's not used outside of the
header.
This is an opposite case from the usual "pipe into grep-the-function"
where my `pbpaste` emitted a lot of content exceeding the OS pipe
buffer. The `block_on_fg` condition was just `send_sigcont` in the
original job control rewrite, and it was incorrect to sub it for
WAIT_BY_PROCESS on its own.
However, this requires always blocking when select_try returns an
interrupted/incomplete read or else fish doesn't block and stays running
in a tight loop in the background (and incorrectly writing to a terminal
it doesn't own under higher debug levels), which I *think* is OK.
Instantiate the std:locale instance used within the character comparison
callback outside the lambda and take a reference to it instead of
creating the locale object for each character in the sequence.
This is part of a very tight loop with lots of inputs during the
evaluation of fuzzy string matches for completions/autosuggestions and
is worth optimizing.
This was introduced in 1b1bc28c0a but did
not cause any problems until the job control refactor, which caused it
to attempt to signal the calling `exec` builtin's own (invalid) pgrp
with SIGHUP.
Also improved debugging for `j->signal()` failures by printing the
signal we tried sending in case of error, rename the function to
`hup_background_jobs`, and move it from `reader.h`/`reader.cpp` to
`proc.h`/`proc.cpp`.
When a function is encountered by exec_job, a new context is created for
its execution from the ground up, with a new job and all, ultimately
resulting in a recursive call to exec_job from the same (main) thread.
Since each time exec_job encounters a new job with external commands
that needs terminal control it creates a new pgrp and gives it control
of the terminal (tcsetpgrp & co), this effectively takes control away
from the previously spawned external commands which may be (and likely
are) expecting to still have terminal access.
This commit attempts to detect when such a situation arises by handling
recursive calls to exec_job (which can only happen if the pipeline
included a function) by borrowing the pgrp from the (necessarily still
active) parent job and spawning new external commands into it.
When a parent job spawns new jobs due to the evaluation of a new
function (which shouldn't be the case in the first place), we end up
with two distinct jobs sharing one pgrp (to fix#3952). This can lead to
early termination of a pgrp if finished parent job children are reaped
before future processes in either the parent or future child jobs can
join it.
While the parent job is under construction, require that waitpid(2)
calls for the child job be done by process id and not job pgrp.
Closes#3952.
Use SIGCHLD to determine whether or not waitpid(2) calls can be elided,
but only with extreme caution. If we receive SIGCHLD but are not able to
reap all jobs, we need to iterate through them again.
For this to work, we need to make sure that we reap all children that we
can reap after a SIGCHLD, i.e. it's not OK to just reap the first and
return or else we can never clear the dirty state flag.
In all cases, as expensive as a call to waitpid() may be, if a child
process is available for reaping it is always cheaper to wait on it then
reap it than to call select_try() and end up timing out.
The old code was rather haphazard with regards to error control, and
would make mutable changes before operations that could fail without any
viable error handling options.
Convert `select_try()` to return a well-defined enum describing its
state, and handle each of the three possible cases with clear reasons
why we are blocking or not blocking in each subsequent call to
`process_mark_finished_children()`.
* Use the newly-introduced signal_block_t RAII wrapper
* Remove EINTR loops as all signals are blocked
* Clean up control flow thanks to RAII wrappers
* Rename parameter to clarify what it does and update docs accordingly
* Update outdated comments referencing SIGSTOP code that was removed a
long time ago.
* Remove no-op CHECK_BLOCK() call
* Convert JOB_* enums to scoped enums
* Convert standalone job_is_* functions to member functions
* Convert standalone job_{promote, signal, continue} to member functions
* Convert standolen job_get{,_from_pid} to `job_t` static functions
* Reduce usage of JOB_* enums outside of proc.cpp by using new
`job_t::is_foo()` const helper methods instead.
This patch is only a refactor and should not change any functionality or
behavior (both observed and unobserved).
* Debug level 3: describe all commands being executed (this is, after all,
a shell and one can argue that this is the most important debug
information avaliable)
* Debug level 4: details of execution, mainly fork vs no-fork and io
handling
Also introduced j->preview() to print a short descriptor of the job
based on the head of the first process so we don't overwhelm with
needless repitition, but also so that we don't have to rely on
distinguishing between repeated, non-unique/non-monotonic job ids that
are often recycled within a single "execution cycle" (pressing enter
once).
Per @ridiculousfish's suggestions in #5219,
`process_mark_finished_children()` has been updated to work in an easier-
to-follow manner. Its behavior is now straight forward, it always checks
for finished processes but only blocks if `block_on_fg` is true.
We're not using the SIGCHLD count in s_sigchld_generation_cnt for
anything any more, as it's not actually a reliable metric since we can
experience one SIGCHLD as a result of two processes exiting (see #1768),
but only reap one of them if the other is in a not-fully-constructed job
(see #5219), a state we cannot possibly detect without calling
`waitpid()` on all child processes, which we are explicitly avoiding.
We never insert elements into the middle of a job list, only move
elements to the top. While that can be done "efficiently" with a list, it
can be done faster with a deque, which also won't thrash the cache when
enumerating over jobs.
This speeds up enumeration in the critical path in
`process_mark_finished_children()`.
* Instead of reaping all child processes when we receive a SIGCHLD, try
reaping only processes belonging to process groups from fully-
constructed jobs, which should eliminate the need for the keepalive
process entirely (WSL's lack of zombies not withstanding) as now
completed processes are not reaped until the job has been fully
constructed (i.e. all processes launched), which means their process
group should still be around for new processes to join.
* When `tcgetpgrp()` calls return 0, attempt to `tcsetpgrp()` before
invoking failure handling code.
* When forking a builtin and not running interactively, do not bail if
unable to set/restore terminal attributes.
Fixes#4178. Fixes#3805. Fixes#5210.
This is to avoid development versions of fish 3.0 freaking out when the
file format is changed. We now have better support for for future universal
variable formats so it's unlikely we'll have to change the file name again.
In private mode, access to previous history is blocked and new history
does not persist and is only available for the duration of the current
session.
This mode can be used when it is not desirable for commandline history
to leak into a session, e.g. via autocomplete or when it is desirable to
test the behavior of fish in the absence of history items without
permanently clearing the history.
I'm sure there are a lot more features that can be incorporated into
private mode, such as restricting access to certain user-specific
configuration files, etc.
This addresses a lot of the concerns raised in #1363 (which was later
changed to track mosh-specific problems). See also #102.
When we discard output because there's been too much, we print a
warning, but subsequent uses of the same buffer still discard.
Now we explicitly reset the flag, so we warn once and everything works
normal after.
Fixes#5267.
For things like
source $undefined
or
source (nooutput)
it was quite annoying that it read from tty.
Instead we now require a "-" as the filename to read from the tty.
This does not apply to reading from stdin if it's redirected, so
something | source
still works.
Fixes#2633.
