LWN: Comments on "Fish - The friendly interactive shell"

Awesome shell!

gf0710020216 — Sun, 15 Apr 2012 10:48:57 +0000

I completely agree to your opinion that shell should be more friendly to human~Best wishes to fish!

Fish - The friendly interactive shell

samroberts — Thu, 21 Aug 2008 21:24:59 +0000

About your re-implementation of NeXT's "open" using mimecap and custome 
files:

see does exactly this, it's part of the mime handling utilities.

Removing the quote distinction?

Mysingen — Sun, 09 Mar 2008 20:30:47 +0000

Why not just escape the variables instead?

set a Hello
set b '\$a is $a'
set a Goodbye
echo $b

should print "$a is Hello"

It is just a hassle to keep track of what will be expanded in bash scripts and I would really
like the distinction between ' and " to go away.

Incompatibility

beojan — Sun, 24 Feb 2008 12:16:52 +0000

It might be incompatibl with other shells, but since I am creating a 
distribution for beginners, fish is the default login shell, whilst bash 
is the default /bin/sh.

Fish - The friendly interactive shell

nutela — Mon, 15 Jan 2007 16:14:31 +0000

About completion, I was wondering, I want to do some task but I don't know the proper command (name) for it, would you care to adress this? Something like I want to search and replace and it'll return grep.

Or you want to search something and type search and it would return, "try "find""

Could be very useful IMHO.

Fish - The friendly interactive shell

dberkholz — Mon, 05 Dec 2005 22:52:15 +0000

> Wonder how long before a gentoo e-build shows up...

Probably about 6 1/2 months, since I just came across this in an article in some Linux magazine and added it.

Fish - The friendly interactive shell

liljencrantz — Thu, 09 Jun 2005 12:11:50 +0000

So many solutions to a single problem. What is really needed is a 'Do what i mean' command...

Fish - The friendly interactive shell

kjetilho — Wed, 01 Jun 2005 19:29:21 +0000

It would be bad to make the behaviour in scripts different from that in interactive use, often I just paste my recent command history and make it a script for later use. The obviously correct ;-) solution is to make globbing work differently in list context, ie. when used as an iterator in for loops.

Doing this correctly in bash is quite painful -- you need to handle case where the glob matches literally:


  for i in *.c; do
    [ "$i" = "*.c" -a ! -e "$i" ] && break
    do_stuff "$i"
  done

fish sure is neater:

  for i in *.c; do_stuff $i; end

Algorithms for loading history file

Blaisorblade — Wed, 01 Jun 2005 16:15:45 +0000

Ok, probably the search algorithm is ok...
For the hash function, SHA1 has almost 0 probability of collision and gives a 160 bits hash; to avoid collisions between around 5000 entries, it's really overkill. Actually a good hash function for non-cryptographic purposes (assuming you go compare entries with the same hash) is of the followind kind:

int hash(char a[], int size, int prime) {
  char * p = a;
  int sum = 0;
  while (*p) {
    sum = sum * prime;
    sum = (sum + *p++) % size;
    //printf("%d ", sum);
  }
  return sum;
}

it returns an integer in the range [0..size); (and prime must be a prime number, which usually you choose at compile time). prime=131 is a good choice. It is easy to add this code to build a testing program with the below (send size and prime on the first line, then a test file, and then sort|uniq -c|count the average number of collisions on used hash codes with awk).

char str[1000];

int main(void) {
  int size, prime;
  scanf("%d %d", &size, & prime);
  while (scanf("%s", str) != EOF) {
    printf("%d\n", hash(str, size, prime));
  }
}

Algorithms for loading history file

liljencrantz — Wed, 01 Jun 2005 11:11:48 +0000

The history search uses a linear search right now, since the history list is so small that searches take virtually no time at all. Making the search use a more clever algorithm would just increase code bloat without adding any noticable benefit to the user.

The thing that _does_ take time is reading the history file from disk. I haven't looked in to whether this is because of disk latency, because fish does mutiple mallocs for every entry, meaning several thousand mallocs are performed when loading into memory or if this is caused by using a slow hash function in the table used for removing duplicates. The hash function fish uses is pretty slow, since it does quite a lot of work. It is designed in much the same way as the SHA family of cryptographic functions, but with fewer laps and a smaller data set. The upside is that the distribution of the hash values is very good. The downside is that the hash function is a bit slow.

Algorithms for loading history file

Blaisorblade — Wed, 01 Jun 2005 00:27:49 +0000

> The history file takes about a quarter of a second to load 1000 entries, > though. That has to improve.
About this: since this is something smart algorithms can help about (I'm not sure about load time, but at least for search time), I wanted to answer. Have you thought to using a trie (also called radix tree)? It's a tree (not binary) where each word is stored split in characters, with one character at each level. So you store "cat a" and "cat b" in the same tree path, except for the last node:

(representing the tree in horizontal)
<c> -> <a> -> <t> -> < > -> <a> | <b>

This helps a lot searches done from the beginning. The root would be an empty node, having all (used) letters as childs.

Actually this wouldn't help for Ctrl-R searches... a solution I have on top of my head (but which isn't on textbooks, so it's not as studied as the above one) is to have a parallel array who contains all letters, and where each letter points to all occurrences of that letter itself in the main tree. So for "a" you find a list of all "a"'s in the main tree. Sadly, it would be better to have a parallel trie of all "a" in the main tree, but this would be hard (either you restore again the whole trie or you all "a"'s share the descendants, which isn't nice).

If you want, we can discuss this further (even if I'm not a deep expert on this)...

Fish - The friendly interactive shell

liljencrantz — Mon, 30 May 2005 21:15:20 +0000

Look at your example again... If *.bak does not match anything, the for loop body will execute exactly zero times. So the rm command will _never_ be run. And even if it had, running rm without any parameters doas not remove anything. So you are doubly safe.

Fish - The friendly interactive shell

Jyhem — Mon, 30 May 2005 17:10:09 +0000

Are you saying that if you write

for i in *.bak; rm $i; end

then if there is no backup file present, I will have all the files in the directory deleted ?

I hope you intend to implement "undo" :-D

Fish - filename transformation

liljencrantz — Mon, 30 May 2005 09:22:58 +0000

This type of feature is the kind of thing that should be possible to do yourself with very little effort. There is a world of difference between something configurable and something extensible. While there are virtually no configuration options in fish, there is a rudimentary framework for extending the shell using simple shellscripts. As this framework improves, I hope people will start hacking shellscripts that extend fish and make it cooler.

You can already bind arbitrary shell commands to a keyboard shortcuts, and get the value of the token under the cursor. Writing a bit of shellscript to change from a relative to an absolute filename is pretty easy. The only part that is missing is changing the token under the cursor. You can currently only set or append to the commandline. I was already planning on adding support for changing the current token, in order to move more and more of the fish implementation into shellscript.

So in the near future, the following should do what you want:

1). Create a file called .fish_inputrc in your home directory containing the lines

$include /etc/fish_inputrc
"\M-a": evaluate-command make_absolute_path

2). Create a file called .fish in your home directory containing something like this:

function make_absolute_path
set result $PWD/(commandline --current-token)
commandline --current-token $result
end

Obviously, the relative to absolute convertion is in much need of improvement, but otherwise, that should work as soon as I add the required functionality to the commandline builtin.

Fish - filename transformation

pason.fazon — Sat, 28 May 2005 15:25:49 +0000

Is there any possibility in fish easily transform/switch filename - you have written on command line - between relative and absolute form of a path if you placed cursor in the filename? The transformation to absolute form is clear, transformation from absolute to relative form could use the current directory as a referential point for the transformation. There are many other imaginable referential points (history of directories, ...), a current directory is propably the most prominent candidate for me.
I didn't discover this useful capability in any other shell (including zsh).

Uh printf is clear?

renox — Sat, 28 May 2005 14:42:46 +0000

printf is powerful and allows complex output format without being too verbose, I agree.

But what printf isn't is "clear"! All the right and left reading matching the format element to the variable makes it not clear at all, especially when there are many variables or long text.

[ off topic rant: I wish that script language would do something like:
print "%8d{$my_variable} %-5f{$my_other_variable}\n", it would be so much easier to read instead of normal printf ]

While replacing `` by () is a good idea as ` are a pain to find in non-QWERTY keyboards, removing the distinction between "" and '' is not good, I agree with liljencrantz here.

Fish - The friendly interactive shell

liljencrantz — Fri, 27 May 2005 14:19:19 +0000

Regarding the age of C, I don't think the analogy holds. When C was released it was a high level language, but nowadays it is considered a low level language. Many of the tasks that would have been suitable for C thirty years ago would be done in C++, Java, Python, Perl or Ruby today. C has definitely _not_ been replaced, but it has definitely got competition.

And as to C not changing, I don't think it's as clear cut as that. ANSI style prototypes, a greatly expanded standard library, enums, inline functions, const, new datatypes, the deprecation of goto, pragmas... I'd say that most of the issues with C have been corrected. What remains is a very small, very simple low level language. The POSIX shell syntax has some pretty fundamental issues that I don't think can be fixed by deprecating a few features and adding some new keywords and recomendations.

Fish - The friendly interactive shell

liljencrantz — Fri, 27 May 2005 14:02:28 +0000

This is very typical for zsh. Whenever there is a difficult design tradeof, zsh implements multiple solutions and lets the user choose. This may sound like a good way of doing things, but I think it is a cop out and a bad idea. Here is why:

Multiple implementations means that more time has to be spent on maintaining the code, it becomes more difficult to add new features and the number of possible configuration combinations means that it becomes impossible to test all configuration combinations, which leads to an increase in rare, hard to nail down bugs. And if you eventually figure out the _right_ way of doing something, it is difficult to change the code, because that means removing configuration options.

Fish - The friendly interactive shell

liljencrantz — Fri, 27 May 2005 12:07:41 +0000

The reason fish does what it does right now is that I regularly do things like:

for i in *.c; [...]; end

Inside of shellscripts. I expect this to work even when *.c does not match anything. If *.c is not expanded in this case, this will result in stupid behaviour, unless I add an explicit check, which is clearly dumb.

Maybe the perfect compromise is to have *.c expand to nothing inside of scripts, but emit a syntax error in interactive mode?

Fish - The friendly interactive shell

diehl — Thu, 26 May 2005 15:51:13 +0000

Well, in my opinion I perfer to have ls have the behavior of of saying "no file
found" if a file does not exist, rather than giving an entire directory listing if the
file does not exist, which I find confusing. So I vote for implementing that
behavior, at least as an option.

Fish - The friendly interactive shell

mikachu — Thu, 26 May 2005 15:25:40 +0000

In zsh, you can select between two behaviours, either you get an error when * doesn't match anything, or it expands to nothing as in fish. (and when in the first mode, you can write *(N) to make it expand to nothing if it doesn't match). In bash i think * is left as a literal * if it doesn't match, so the file not found message is actually from ls, not the shell. Not 100% sure about that one though.

Fish - The friendly interactive shell

liljencrantz — Wed, 25 May 2005 15:54:04 +0000

This is a bug disguised as a missing feature. There is an error message, but it is not printed because of a bug in the error reporting code. This is fixed in the latest version of fish, version 1.9.2.

Fish - The friendly interactive shell

diehl — Tue, 24 May 2005 13:29:13 +0000

I noticed that in fish if you "cd" to a non-existant directory it does not report an
error. You stay in the current directory, which is reasonable, but it would be nice
get an error message like you get in bash or tcsh so you are made aware that
you are not where you think you are.

Fish - The friendly interactive shell

liljencrantz — Sat, 21 May 2005 10:38:51 +0000

I wouldn't say tcsh lives in a different niche than bash.

Obviously, Perl and shellscript have a large overlap, but Perl is suited for many programming tasks where shellscript would be a terrible idea, and Perl is pretty far from suitable as an interactive shell. Attempts to create a Perl-based shell, like Zoidberg, haven't really attracted any users that aren't hardcore Perl lovers.

Removing the quote distinction?

liljencrantz — Sat, 21 May 2005 10:30:13 +0000

Meh. You are turning my own arguments against me. That's cheating! ;-)

Incompatibility

liljencrantz — Sat, 21 May 2005 10:26:15 +0000

The languages are close enough that this should be possible. Back in college, I wrote a Pascal to C converter for a syntax course, this should actually be easier. Of course, that converter ignored tricky bits like records and pointers, and it was never widely tested...

Fish - The friendly interactive shell

liljencrantz — Sat, 21 May 2005 01:06:48 +0000

1) I don't like the bash way of doing this, since it is inconsistent and for me at least it is very rarely what I want. As another poster said, csh refuses to execute commands with wildcards that match nothing. This seems better at least, but from a language viewpoint, neither is very logical. But I'll consider changing the way fish handles this.

2) I will look into how the mimedb command searches for the .desktop hierarchy. It has been a few months since I touched that code, so my memory is a bit hazy. I'll get back to you.

Setting prompt not trivial

liljencrantz — Sat, 21 May 2005 00:52:25 +0000

Oops. That is an error in the documentation. The thing is that some characters have to be escaped with backslashes in the documentation, but I've obviously escaped too many characters. Simply a case of bad proofreading of the documentation.

This should work:

set FISH_PROMPT "whoami; echo '@'; hostname |cut -d . -f 1; echo '> '"

I will fix this in the manual. The pipeline in hostname is for computers that have long hostnames like 'gacrux.nada.kth.se'.

I am also planning on supporting multiline editing and smart line usage, so that when the cursor reaches the end of the line, the entire row is shifted to the left and the beginning of the line is removed.

Fish - The friendly interactive shell

kingdon — Fri, 20 May 2005 23:57:20 +0000

Well, yes, non-POSIX shells live in a different niche than POSIX shells. This niche overlaps somewhat with perl and other languages that people sometimes use to invoke programs and hook them together and munge their output and such.

But the last such attempts that I remember seeing (of ones that try to be shell-like) were rc and es.

Fish - The friendly interactive shell

kingdon — Fri, 20 May 2005 23:51:03 +0000

As for the wildcard issue, a lot of utilities will read from standard in if called with no arguments. So having a non-matching wildcard expand to no arguments doesn't seem so good.

There are two traditional behaviors: pass along "*.txt" to the program (most/all Bourne-derived shells), or give an error and don't even call the program (csh). The latter makes more sense to me (one can always quote the *.txt if that's what one means).

Removing the quote distinction?

mikeraz — Fri, 20 May 2005 18:43:04 +0000

fish is "friendly" and for beginners printf syntax isn't.

I'd feel more comfortable with variable expansion in quoted strings so that

% set file ~/mail/sent
% echo "File is set to $file"
File is set to ~/mail/sent

to echo $file you escape it
% echo "File is set to \$file"
File is set to $file

Setting prompt not trivial

diehl — Fri, 20 May 2005 18:18:29 +0000

One aspect of fish which I find problematic right now is that the default prompt
displays your current directory, which is fine, except that after you get deep into
a directory tree you use up most of you command line on the prompt. This
aspect coupled to the lack of multiline editing, means that you find you cannot
edit a recalled command because it wraps to 2 lines and you cannot edit the first
part of the command anymore.

So I decided to try to reset my prompt to not include the PWD. I guess I just
don't understand the syntax, because I could not do it. The documentation says
the default prompt is:

set FISH_PROMPT "whoami; echo \@; hostname\|cut -d . -f 1; echo \\" \"; set_color
green; pwd; set_color normal; echo '\> ';"

Unfortunately I don't completely understand what is going on this this line, for
example, the purpose of: echo \\ which looks like you are echoing a "\" which
must be escaped, but apparently not because you do not see a "\" in the
command prompt. Anyway, I tried to reduce this to:

set FISH_PROMPT "whoami; echo \@; hostname\|cut -d . -f 1; echo '\> '"

This will generate an error:

Unknown command 'hostname|cut'

I could not figure out any way to remove the pwd part and get the hostname|cut
part to work. Even if you just remove the "pwd;" for some reason you still get
the default prompt.

Fish - The friendly interactive shell

diehl — Fri, 20 May 2005 16:06:37 +0000

1) Ok, I understand why "ls *.txt" lists all files when no txt files exists. However
this not behavior I particularly want. tcsh and bash do not do this. Is there any
way to get "ls *.txt" to return nothing or "No such file or directory" which is what
it returns if "ls" a specific file which does not exist.

2) As far as mimedb goes "mimedb -i text/plain -a" returns nothing. I poked
around found a bunch of *.desktop files in various subdirectories
under /usr/share. So it would seem that I have to somehow tell mimedb to
look in these subdirectories. Can this be done with symbolic links or
environmental variables?

It might be nice to have the open return some type of error message if it does
not know what to do with the file to clue the user into the problem.

Fish - The friendly interactive shell

liljencrantz — Fri, 20 May 2005 15:25:09 +0000

Hi. Glad you like fish.

1) Actually the exact opposite is happening. If the parameter '*.txt' does not match any files, it is expanded to exactly 0 parameters. In other words, you end up running ls with _no_ parameters, in which case ls will list the contents of the current directory.

2) I think you are referring to another .desktop file. The name overloading in Linux is pretty confusing. The .desktop files I'm referring to is a file hierarchy usually located somewhere under /usr/share.

Try using the mimedb command. If the command 'mimedb foo.txt' returns 'text/plain', the mime database is installed correctly. If 'mimedb -i text/plain -a' returns something like 'gedit %U', the mimedb command can find the .desktop files. Both of these are needed for the open command to work.

Incompatibility

markc — Fri, 20 May 2005 15:05:52 +0000

Perhaps if you wrote a "fishify" inbuilt function or program to covert
bash'isms to fish'isms then folks could adopt fish on top of established
bash scripts.

I could find myself using fish instead of bash but every time I went to
write something that might be widely distributed I'd probably always stick
to bash, unless there was a reliable way to ensure that a fish script
would still work under most circumstance and play well with establish bash
scripts (like rc startup scripts for instance).

Fish - The friendly interactive shell

diehl — Fri, 20 May 2005 13:38:15 +0000

I have tried out fish and I think it has many nice features and I will switch to
using it (from tcsh). However, I do find some unexpected behavior.

1) It would seem that the wildcards * and ? match everything if no matches are
found. That is if you type "ls *.txt" you get a listing of all txt files. However, if
no txt files exist, then you get a listing of all files. This behavior I find
completely baffling, and not particularly desirable.

2) I think the "open" command looks very nice, however, it does not work for
me. I'm using Mandriva 10.2 KDE. My .desktop file consists of one line:
DESKTOP=KDE
It would appear that some additional configuration or something is needed to
get open to work on my computer. Actually, it would be really cool to be able to
double-click a file name in a directory listing and get that to open.

Removing the quote distinction?

liljencrantz — Thu, 19 May 2005 23:20:46 +0000

Yes, using something like Pythons one, two or three quotes is an option. It means that quotes can be nested, while also allowing different kinds of quotes.

I think I'll wait for a while and see if the screams for more quoting options die out. I'd rater keep the language small. Also, I'm kind of lazy.

Fish - The friendly interactive shell

liljencrantz — Thu, 19 May 2005 23:07:13 +0000

Oops. That address has been acting up lately, marking lots of things as spam and what not. You can try using this address: liljencrantz at gmail dot com.

I'll start working on a real, good test suite after I finish the syntax additions described in the article.

Fish - The friendly interactive shell

EV — Thu, 19 May 2005 21:25:07 +0000

Looks good, I was just thinking about the need for a more user friendly shell the other day. Wonder how long before a gentoo e-build shows up...

Just compiled the 1.9.1 release on my laptop. Make test failed test3 because fish is not in my PATH. a change to ../fish seemed to work.

Also, your e-mail address on the fish home page doesn't seem to be working that well, keeps saying:

Message cannot be accepted, virus found (in reply to end of DATA command

Don't think yahoo is auto sending a virus, but I could be wrong ;-)

Keep up the good work,

-Eli

Fish - The friendly interactive shell

liljencrantz — Thu, 19 May 2005 20:59:44 +0000

I dont think supporting $'string' is a good idea, you can just use 'printf "%b" $string'. Don't build things into the shell if they can be performed just as well in an external command. Calling external commands is what shells are all about!

I will split the completions into separate files eventually. But since this ~1500 line file loads nearly instantly even on my old Pentim 2 300 MHz, this is not on the top of my priority list. (The history file takes about a quarter of a second to load 1000 entries, though. That has to improve.)

My gripe with zsh wildcard completion is that I dont want it to change the text before the cursor. Imagine that I want to remove all the backups of txt files in a directory. In fish I cound type 'rm *.t<TAB>' and it would be expanded to 'rm *.txt', after which I could add a '~' to make the commandline 'rm *.txt~', which is what I wanted. In zsh this won't work.

As to crippled configurations, I don't know. I base my experience on the default zsh package on Fedora Core 3 and on a custom build of zsh on Solaris at my old University. Both have underwhelming default settings. If they are crippled, either intentionally or by mistake, I dont know.

And as to further bloating fish - you're right. I don't want to bloat it. But on the other hand I've tried to make it possible to hack fish without bloating the shell itself. Examples of a few hacks that I've included in the default version of fish:

Press Meta-L to list the current directory. But if the cursor is over a string that is a file or directory, the contents of that directory is printed.

The vared function is used to edit a variable value. The vared function has a history, separate from the main command buffer, and includes quote and parenthesis highlighting X clipboard copy and paste, etc..

Ctrl-R does a regexp replace on the current commandline. Or if the current commandline is empty, the first entry of the command history is used.

These are all implemented as simple keybindings and/or fish functions, without bloating the shell with builtins.