Commit Graph

5 Commits

Author SHA1 Message Date
Fabian Boehm
8d7416048d Don't skip caret for some errors
This checked specifically for "| and" and "a=b" and then just gave the
error without a caret at all.

E.g. for a /tmp/broken.fish that contains

```fish
echo foo

echo foo | and cat
```

This would print:

```
/tmp/broken.fish (line 3): The 'and' command can not be used in a pipeline
warning: Error while reading file /tmp/broken.fish
```

without any indication other than the line number as to the location
of the error.

Now we do

```
/tmp/broken.fish (line 3): The 'and' command can not be used in a pipeline
echo foo | and cat
           ^~^
warning: Error while reading file /tmp/broken.fish
```

Another nice one:

```
fish --no-config -c 'echo notprinted; echo foo; a=b'
```

failed to give the error message!

(Note: Is it really a "warning" if we failed to read the one file we
wer told to?)

We should check if we should either centralize these error messages
completely, or always pass them and remove this "code" system, because
it's only used in some cases.
2022-08-12 18:38:47 +02:00
Johannes Altmanninger
05ddda9155 use variable assignments on commandline in completions
Fixes #6507

To do: If a variable assignment uses a command substitution that errors,
the error is printed, but without a proper location.
2020-01-17 14:53:35 +01:00
Fabian Homborg
69b464bc37 Run fish_indent on all our fish scripts
It's now good enough to do so.

We don't allow grid-alignment:

```fish
complete -c foo -s b -l barnanana -a '(something)'
complete -c foo -s z              -a '(something)'
```

becomes

```fish
complete -c foo -s b -l barnanana -a '(something)'
complete -c foo -s z -a '(something)'
```

It's just more trouble than it is worth.

The one part I'd change:

We align and/or'd parts of an if-condition with the in-block code:

```fish
if true
   and false
    dosomething
end
```

becomes

```fish
if true
    and false
    dosomething
end
```

but it's not used terribly much and if we ever fix it we can just
reindent.
2020-01-13 20:34:22 +01:00
Johannes Altmanninger
97969a9363 Restore error messages for bare variable assignment
Since #6287, bare variable assignments do not parse, which broke
the "Unsupported use of '='" error message.

This commit catches parse errors that occur on bare variable assignments.
When a statement node fails to parse, then we check if there is at least one
prefixing variable assignment. If so, we emit the old error message.

See also #6347
2019-11-26 13:59:17 +01:00
Johannes Altmanninger
7d5b44e828 Support FOO=bar syntax for passing variables to individual commands
This adds initial support for statements with prefixed variable assignments.
Statments like this are supported:

a=1 b=$a echo $b        # outputs 1

Just like in other shells, the left-hand side of each assignment must
be a valid variable identifier (no quoting/escaping).  Array indexing
(PATH[1]=/bin ls $PATH) is *not* yet supported, but can be added fairly
easily.

The right hand side may be any valid string token, like a command
substitution, or a brace expansion.

Since `a=* foo` is equivalent to `begin set -lx a *; foo; end`,
the assignment, like `set`, uses nullglob behavior, e.g. below command
can safely be used to check if a directory is empty.

x=/nothing/{,.}* test (count $x) -eq 0

Generic file completion is done after the equal sign, so for example
pressing tab after something like `HOME=/` completes files in the
root directory
Subcommand completion works, so something like
`GIT_DIR=repo.git and command git ` correctly calls git completions
(but the git completion does not use the variable as of now).

The variable assignment is highlighted like an argument.

Closes #6048
2019-11-25 09:20:51 +01:00