On 1/6/06, Netocrat <[EMAIL PROTECTED]> wrote:
Axel Liljencrantz wrote:
Of, I have added a patch to the Darcs version of fish which changes the
syntax of 'and' and 'or' to:
[infix semantics, as builtins - the previous command must be properly
terminated]
That is indeed more precise.
You will notice in the above example that 'pwd && whoami' actually
launches 'pwd &' in the background. Maybe fish should do a syntax check
on the whole commandline and reject all of it instead?
After installing the most recent darcs repo fish build I think that the
error message redirecting the user to "or" or "and" is great for
discoverability for migrating POSIX scripters. I think it's best not to
run the job in the background though - it's almost certainly not what
the user intended.
But then, if you're going to be doing that parsing anyway, why not
simply do the replacement on behalf of the user:
"||" becomes "; or "
"&&" becomes "; and "
OK, I already know your answer - "one syntax only", "ugly hack", etc. ;-)
:)
But this does give me another idea - let's assume Joe User wants to
implement this alias. Fish doesn't support functions with pipe symbols
in their name, and the symbol doesn't occur in a valid spot for a
function anyhow, so that's out of the question.
How about supporting it through the (evolving) event model though: there
could be a "parser error" event, and one particular error could have
type "double-pipe". The user could install a handler for the
double-pipe parser error, and this handler would be given enough
information to be able to replace the double-pipe in the command-line
with "; or ". A little esoteric, but perhaps less objectionable to your
no-configurability tastes.
Seem a good idea, except that the proposed event is not very genreral
purpose.
Even more generically, there could be a pre-parse-commandline event that
would do replacements prior to fish interpreting the commandline.
Now we are talking. This is a great idea, language-wise. Makes perfect
sense to have such an event, and it has other uses as well, such as
implementing spelling correction.
Things like that would help to make a POSIX-compatible mode for fish a
possibility (activated through an entry-point function in a set of
separately distributed fish functions) without disturbing your desire to
avoid configurable options. It wouldn't be expected that users enable
this mode by default, but it would be helpful if they e.g. want to run a
POSIX script without changing shells, or want to try fish out briefly to
investigate its usability features without having to learn its syntax
when they already know POSIX.
Now we're talking. As you suggest, I don't think this mode should be enabled
by default. But I think it makes perfect sense to include it with fish, and
give it plenty of room in the documentation. The obvious things this mode
could fix are:
fi->end
done->end
then->
do->
case->switch
esac->end
FOO)->case 'FOO'
;;->
&&->;and
||->;or
foo=bar->set -g foo bar
export foo=bar->set -gx foo far
$(FOO)->(FOO)
Obvious problems: Parser errors, the history file and loads of other things
will operate on the translated messages. This is a bit confusing, but since
it is mostly how history substitution works in other shells, people should
be able to live with it. This also has the benefit that the user will see
the real fish syntax, and will hopefully in time learn to use it.
Also, unless some care is taken in the implementation, the wrong things
could get substituted. One should take care to make things like this work:
echo Do you want to switch shells?
echo "&& is merely a shortcut for ;and"
foo=bar baz=qux some_command
Does anyone feel like impementing this, once the event is in place? I'll be
happy to give a few pointers. It might also make sense to 'spice up' the
commandline builtin a bit to make things easier here, including giving full
access to the fish command tokenizer from the commandline. Should make this
relatively straighforward.
