Wildcard errors are only reported interactively, and they're also not
really errors. Commands with multiple wildcards would in fact continue
executing if at least one wildcard matched, which is quite surprising.
But they would report an error if there is only one wildcard in the
arguments list and the wildcard has no match, even if there are other
remaining arguments.
Given this inconsistency, and given that sh does not stop execution if a
wildcard fails to match, it seems better to allow execution to continue.
This is better from a scripting perspective anyway, as it means
constructs like `set -l paths foo/*.txt` will actually create the
variable (with an empty value) instead of skipping the `set`
altogether and perhaps causing subsequent code to read or modify a
global or universal variable.
Wildcard errors are only supposed to reported when encountered during
interactive use. The old parser also suppressed them if `is_block` was
true. This was lost in the new parser. However, this also suppresses
errors generated from `begin; code_here; end` and other block
constructs.
Instead, check the parser block stack when we hit an error, and suppress
the error if there are any function calls / events / source invocations.
These all indicate that the code being executed came from somewhere
other than the commandline.
Unmatched wildcard errors during parsing are normally only reported when
run interactively. The switch command was unconditionally reporting them
anyway (and not setting the status to 124). Fix it so switch goes
through the same code path as everything else.
Prior to this change, inherited environment variables
would be split on colons, becoming an array. This change
eliminates that behavior. Now environment variables are
always split on the record separator character (ASCII 0x1e),
with the exception of a short whitelist of PATH, MANPATH,
CDPATH. Likewise, exported variables are also exported
delimited by rs, with the exception of the above whitelist.
Fixes#1374, also see #1656
The terminal width magic that __fish_print_help learned doesn't help
when builtin_print_help runs it in a subshell. Instead, add an
undocumented --tty-width flag to __fish_print_help that's used to pass
the terminal width.
As a result of this rewrite, the output now:
* Expands to fit the terminal width, like `man` does
* Preprocesses the manpage with `tbl` just in case, since `man` does
this, even though I doubt any fish manpages use `tbl` formatting.
* Handle bold/underline with the `ul` command as it was designed for
instead of trying to fake it with `sed`.
* Compresses blank lines as `man` does with the default `less -is`
pager.
We can't use $PATHS to test the :-splitting because the global config
file adds extra paths based on /etc/paths and /etc/paths.d.
Ideally fish would have a way to suppress behavior like that, but for
the time being it doesn't.
The usage is still the same, but it's a lot more robust, and also no
longer assumes $fish_user_abbreviations must be a universal variable.
This also fixes the unexpected error output when calling `abbr -a` with
no existing abbreviations.
Calling `abbr -a` with an abbreviation that already exists now silently
overwrites the abbreviation, just like `function` and `bind` do, instead
of complaining.
Re-running ./configure will cause fish.pc to rebuild, in case any of the
paths changed. It looks like this actually won't rebuild the rest of
fish, but figuring out how to handle that is out of scope for this
commit.
More importantly, this will rebuild fish.pc when the version string
changes.
This fixes the issue with nonexistant directories (some Linux
distributions put these for local modules), and also fixes the
issue of dot meaning any character instead of simply dot.
--inherit-variable takes a variable name and snapshots its current
value. When the function is executed, it will have a local variable with
this value already defined. Printing the function source will include
synthesized `set -l` lines for the values.
This is primarily useful for functions that are created on the fly, such
as in `psub`.
ENV_USER is intended to be used when setting any variable whose name is
controlled by the user. The names given to `function -a` certainly
qualifies. This wasn't an issue in practice because the only restriction
ENV_USER imposes is also imposed on ENV_LOCAL, but the rules may change
in the future.
