On 5/21/07, Philip Ganchev <[EMAIL PROTECTED]> wrote:
> The Fish parser treats any "$" character that is unquoted or quoted
> inside double quotes as a variable reference. Unfortunately, the user
> may try to use "$" in a regexp inside double quotes. For example:
>
> > grep -E -v "^$" myfile
> fish: Did you mean (COMMAND)? In fish, the '$' character is only used
> for accessing variables. To learn more about command substitution in
> fish, type "help expand-command-substitution".
> grep -E -v "^$" myfile
> ^
>
> This can be achieved by using single quotes instead:
> > grep -E -v '^$' myfile
>
> But the user may not think of that. Unfortunately, I don't see a way
> to make the parser smarter in general. So either the error checking
> should be less strict, or the error message should be more general:
Thanks for pointing this out, this sort of thing is easy to miss when
you're coding.
I don't like the idea of sloppy error checking very much, just like I
don't like the way bash leaves wildcards unexpanded if there are no
matches. A syntax should be simple and consistent, or else you'll get
unexpected corner cases that cause ugly bugs.
I belive that better error messages is the right way to do this.
>
> fish: Incorrect variable reference. The "$" character is used for
> variable reference when it is unquoted or inside double quotes (").
> You can use single quotes (') instead. To learn about variables, type
> "help variables"; about variable substitution type "help
> expand-command-substitution".
>
> or
>
> fish: Incorrect use of "$". When the "$" character is unquoted or
> inside double quotes ("), it is interpreted as a variable reference.
> To avoid this, put it inside single quotes ('). To learn about
> variables, type "help variables"; about variable substitution, type
> "help expand-command-substitution".
>
> I'm not sure why the command substitution part is useful.
Because one common way to trigger this $-related errors is by using
posix-style command substitutions like '$(ls)'. But fish has a special
cased error message for that situation, so the general error no longer
needs to mention this. Feel free to send a suggested new wording.
>
> Incidentally, a more radical idea used in YubNub solves this and
> another problem: use a builtin called "var" for all variable
> operations, including setting, getting and removing:
> > var A --set-global hello bye
> > var A
> hello bye
> > echo "say: (var A) now!"
> say: hello bye now!
> > var A --erase
>
> This is more verbose but perhaps more intuitive, as it uses the same
> syntax for setting and reading. Also, the builtin may be easier to
> remember and discover because its name is mnemonic. It also solves
> the above problem, because "$" would never be special.
Agreed, operators like $ are less descriptive than using full commands
except in the few cases where the meaning of the operator is
_extremely_ common, like using '+' for addition. It's a tradeoff.
--
Axel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
