On 5/10/06, Peter Moulder <[EMAIL PROTECTED]> wrote:
share/completions/apropos.fish needs one of its `$' signs (the one signifying end of line rather than being part of `$str') to be escaped, to fix the following:> apropos fis<TAB>fish: The '$' character begins a variable name. The character '/', which directly followed a '$', is not allowed as a part of a variable name, and variable names may not be zero characters long. To learn more about variable expansion in fish, type 'help expand- /usr/share/fish/completions/apropos.fish (line 6): apropos $str|sed -e "s/^\(.*$str\([^ ]*\).*\)$/$str\2"\t"\1/" ^ in function '__fish_complete_apropos', called on standard input, in command substitution called on standard input,
Fixed. Thanks!
I found this within the first few minutes of playing with fish. [Admittedly, that's not because I often use `apropos', but because I was wondering where the command descriptions in tab completion come from, and I hypothesized that they were from apropos.]
Still a bug.
fish is (I suppose) targetted at newbies and other non-computer-experts, who might be somewhat intimidated by error reports such as the above (especially with its lines continuing past the width of the window, and the `^' indicator that doesn't actually point at the `$' causing the problem).
The ^ counter doesn't take tab width into account. That should of course be fixed. As to newbie-ness and fish, it's not really that simple. I wrote fish mostly to suit me - I use the shell pretty often, but not enough to want to learn what [EMAIL PROTECTED]:=.foo} means. I have repeatedly stumbeld across functionality in bash and zsh that has a very cumbersome syntax making it almost impossible to discover or use without lots of bookreading. I want fish to be discoverable, i.e. I want it to be possible to figure out as much as possible about how fish works without using a manual. Some ways this can be done: * A small, uniform and logical syntax. Less to learn means more time to get things done. And by choosing the language features carefully, one can make sure the expressive power of other shells are still preserved. A lot of though has gone into making the fish language sane while still much smaller and more consistent than other languages. * Leverage existing knowledge - i.e. behave like Posix when possible, and when impossible, try to output an error message showing how to do things in fish: fish> make||make clean fish: Expected a command name, got token of type 'Pipe'. Did you mean 'COMMAND; or COMMAND'? See the help section for the 'or' builtin command by typing 'help or'. * Provide the user with help and hints - this is mostly done in the form of tab completions in fish. Not only is everything tab-completable, but nearly all completions have descriptions. Syntax highlighting is also a form of hint. The way I see it, these and other features make fish user friendly, and newbie friendly is a subcase of user friendly. On the other hand, it is possible to be newbie friendly without being user friendly. Think for example about a 'wizard'. A wizard is a set of dialogs that guides you through some specific process which could have been done using the applications regular user interface. But a wizard hides some of the less common knobs and is much 'talkier'. A wizard is very easy to use for the beginner, so it is newbie friendly, but it won't let you use the advanced features of the application, so it is not user firendly. A wizard can be used to quickly learn how to use an obtuse, crippled version of the application, but after that the user 'plateaus' . I do not want that for fish. Instead my goal for fish is to make it possible to quickly move from total newbie all the way to a seasoned shell expert.
There are currently 145 files in share/completion, and I suppose these will continue to be changed and added to (as evidenced by item 2 of http://roo.no-ip.org/fish/user_doc/index.html#todo-features).
Sure.
Is there any form of automated testing that can be done for these files, to reduce the chance of similar bugs in future?
Excellent question. My script for releasing a new fish version runs all the scripts provided with fish and faild if an error occurs. This catches some types of errors, but not all. The main problem is that completions contain lots of shellscripts that are injected into the shell for later evaluation. I have tried to avoid evaluating strings in fish because it is very difficult to validate such code beforehand. But I could not see a way to define a nice intuitive syntax for completions that doesn't use code in strings. To improve that situation, I try nowdays to move all non-trivial code into functions, since these can be validated beforehand. In this specific case, however, the affected code was in a function, but the validation code did not catch this specific type of error, e.g. an invalid variable name. I'll look into adding a test for this for an upcoming fish release.
Unfortunately, this particular bug wouldn't have been caught by the red syntax highlighting (at least not in 1.12.5). Nevertheless, having `make check' check that all .fish files are free of problems that would be marked with red syntax highlighting would be an excellent first step in reducing the likelihood that such bugs reach the user.
The error checking will be improved over time. It already catches quite a few subtle errors, but there are always more. I'll try to add the one you pointed out here soonish, but patches are of course welcome.
pjrm. (Not subscribed to fish-users.)
-- Axel ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
