This adopts the Rust postfork code, bridging it from C++ exec module.
We use direct function calls for the bridge, rather than cxx/autocxx, so that we
can be sure that no memory allocations or other shenanigans are happening.
This implements the "postfork" code in Rust, including calling fork(),
exec(), and all the bits that have to happen in between. postfork lives
in the fork_exec module.
It is not yet adopted.
This introduces a new module called fork_exec, which will be for posix_spawn,
postfork, and flog_safe - stuff concerned with actually executing binaries,
and error reporting.
Add a FLOG_SAFE! macro which writes errors to the flog fd in an
async-signal-safe way. This implementation differs from the C++ in that we
allow printing integers directly - no requiring them to be converted to a
buffer first.
This makes it so
```fish
if -e foo
# do something
end
```
complains about `-e` not being a command instead of `end` being used
outside of an if-block.
That means both that `-e` could now be used as a command name (it
already can outside of `if`!) *and* that we get a better error!
The only way to get `if` to be a decorated statement now is to use `if
-h` or `if --help` specifically (with a literal option).
The same goes for switch, while and begin.
It would be possible, alternatively, to disallow `if -e` and point
towards using `test` instead, but the "unknown command" message should
already point towards using `test` more than pointing at the
"end" (that might be quite far away).
- This is untested and unused, string ownership is very much subject to change
- Ports the minimally necessary parts of complete.rs as well
- This should fix an infinite loop in `create_directory` in `path.rs`, the first
`wstat` loop only breaks if it fails with an error that's different from
EAGAIN
- wildcard_match is now closer to the original that is linked in a comment, as
pointer-arithmetic translates very poorly. The act of calling wildcard
patterns wc or wildcard is kinda confusing when wc elsewhere is widechar.
This was already supposed to handle `--foo=bar<TAB>` cases, except it
printed the `--foo=` again, causing fish to take that as part of the
token.
See #9538 for a similar thing with __fish_complete_directories.
Fixes#10011
This is the most common and sensible env var, we check it outside,
so we can skip loading the function at all if we already know it's not
gonna do anything.
This is done on every startup of every single fish, and it saves ~0.2ms.
I sometimes find myself doing something like this:
- Look for a commandline that includes "echo" (as an example)
- Type echo, press up a few times
- I can't immediately find what I'm looking for
- Press ctrl-r to open up the history pager
- It uses the current commandline as the search string,
so now I'm looking for "echo foobar"
This makes it so if the search string already is in use, that's what
the history-pager picks as the initial search string.
This was the remaining immediately actionable part of #7375.
It's not definitely the last word, but a change here would require a
bigger plan.
Fixes#7375
Apparently this is actually a point of confusion.
Unfortunately we can't use `which` here because 1. it might not be
installed, 2. it might be trash.
So we give instructions from inside fish, and explain that they
should *typically* work.
See #10002
Without this, a recipe containing a trailing backslash followed by a line not
beginning with tab (like any non-continued recipe lines would) would result in
the continuation showing up in completions.
Whenever a line ends in a backslash, consider the next line invalid as a target.
Regex explanation:
^([^#]*[^#\\])? -- optional prefix not containing comment character and not
ending in backslash
(\\\\)*\\$ -- 2n+1 backslashes at end of line (handles escaped backslashes)
This is in regards to a comment on 290d07a833, which resulted in 46c967903d.
Those commits handled the default path when it is unset on startup.
DEFAULT_PATH is used when PATH is unset at runtime as far as I can tell.
As far as I can tell this has had the non-overidding ordering behavior since inception
(or at least 17 years ago ea998b03f2).
We don't change anything about compilation-setup, we just immediately jump to
Rust, making the eventual final swap to a Rust entrypoint very easy.
There are some string-usage and format-string differences that are generally
quite messy.
