8 ms·

Fish sucks (but your shell sucks more)

71 points by mhansen 16y ago

locopati 16y ago
Not wanting to learn a new shell, is there any movement in the bash community to implement some of these features?
- ortatherox 16y ago
  there's a lot of action going on in zsh at the minute, see: https://github.com/robbyrussell/oh-my-zsh https://github.com/robbyrussell/oh-my-zsh
- viraptor 16y ago
  I haven't seen any user-visible new features in bash the last couple of years, so wouldn't count on it. (see http://tiswww.case.edu/php/chet/bash/NEWS http://tiswww.case.edu/php/chet/bash/NEWS) On the other hand I'm slowly migrating to ipython shell as the main login shell. Since every other terminal I open runs ipython, that makes sense. It also lets me script a lot of stuff without the crazy *sh syntax.
  - rickr 16y ago
    Off the top of my head didn't bash4 include multiple globs? ie * * (no space...formatting)
    - viraptor 16y ago
      Sorry - by user-visible, I meant actually the stuff that "normal" users see, not the shell programming bits. Those are polished all the time of course. Magic symbols and internal functions change all the time with new exciting ways to do basic process calling (</sarcasm>). But on the outside, it's still same old bash you run 2 years ago - no major usability improvements.
jawee 16y ago
I definitely liked the idea of fish. I tried using for a little while when I first came across it a few years ago, but it´s new features were outweighed by simple things I had become use to in Bash such as operators like && to run commands at the same time and the keyboard short-cuts (Ctrl+A, Ctrl+U, etc.).
Sandman 16y ago
"The shell is one of the places where you’ll spend most of your time as a ['nix] coder" Maybe if you're a *nix system administrator. Otherwise, no, not really. I spend most of my time in Eclipse. People who prefer using editors to an IDE spend most of their time in Emacs or Vi(m). But shell? Maybe to hack together a script now and then, but certainly not most of the time.
- mileszs 16y ago
  Hmm. Are you saying that one's shell is not very important, then? That one shouldn't care what shell they are using? I'm sorry, but, otherwise, I don't think I understand why you felt compelled to pick out this single quote from the article and argue about it. Could you explain your point?
  - deleted 16y ago
    [deleted]
- daleharvey 16y ago
  I would say "most" of the time as a definite exaggeration, but I do spend close to 100% of my time between emacs / shell and a web browser.
- alinajaf 16y ago
  As a developer who uses vim I can confirm that the vast majority of my time is spent in the shell, running scripts, working with vcs etc. It's the equivalent of my 'IDE'. At least three other developers I currently work with have a similar setup, so I'm fairly sure its not just me.
  - Sandman 16y ago
    Well, in that case - I stand corrected.
  - scott_s 16y ago
    I think it's important to remember what IDE actually stands for: integrated development environment. That implies that the standard development environment used to not be integrated. And that's exactly what Unix is: a development environment where the tools are not integrated into one place. That sounds like a bad thing on the face of it, but I do not think it is. I think it allows for more flexibility.
daleharvey 16y ago
This article got my excited to try out a new shell, I moved to zsh a while ago but not been particularly impressed, its a shame their site is currently down, http://www.fishshell.org/ http://www.fishshell.org/, hopefully they realise / get it back up sharpish
- stevelosh 16y ago
  In the mean time, here's the Wikipedia page for it, which has a decent overview and a couple of examples: http://en.wikipedia.org/wiki/Friendly_interactive_shell http://en.wikipedia.org/wiki/Friendly_interactive_shell You can download it from Sourceforge: http://sourceforge.net/projects/fish/ http://sourceforge.net/projects/fish/
  - ortatherox 16y ago
    or install it through homebrew: brew install fish
rufugee 16y ago
I've always wondered why shells based on popular scripting languages don't catch on more...especially after living with Bash's horrible (my opinion) syntax over the years, and Korn before that. I know there have been a few shells created based on perl and perhaps python, but when I played with them years ago they seemed half-assed. Is there something special about the shell that requires one to create their own scripting language? I for one would love to have a well-done, reliable login shell based on ruby...
- viraptor 16y ago
  There are a few shells like that. At least 5 different ruby-based (all barely doing the basic stuff, although http://rush.heroku.com/ http://rush.heroku.com/ is not bad at all). Zoidberg (perl) is ok, but there is a lot of perl involved so you can run into situations where typical bash stuff triggers perl execution... I really like iPython's psh - unfortunately it's not well known, since it's not advertised properly (they concentrate on the python's repl part a lot). It does work quite well though: http://ipython.scipy.org/doc/manual/html/interactive/shell.html http://ipython.scipy.org/doc/manual/html/interactive/shell.h...
- cldwalker 16y ago
  You may be interested in ripl (https://github.com/cldwalker/ripl https://github.com/cldwalker/ripl) which is modular enough to serve as a base for more complex shells. It has already been used to create a web shell (http://github.com/cldwalker/nirvana http://github.com/cldwalker/nirvana), a ruby/system shell (https://github.com/janlelis/fresh https://github.com/janlelis/fresh) and a js shell (http://github.com/cldwalker/ripl-johnson http://github.com/cldwalker/ripl-johnson).
- sjs 16y ago
  Traditional shells provide some small conveniences that are hard to give up. You cannot shoehorn this stuff into an existing language by defining global functions, it must be syntax. Ruby could come close by not requiring parens, but still cannot allow something like the following zsh command without extra quoting, parens, or function calls. for f ({foo,bar}/*(.)) { cp -v $f ${f%.js}.min.js } > output.txt
rmc 16y ago
For the record bash has the smart tab completion turned on by default now. (At least it does in my Ubuntu machine)
- yock 16y ago
  Indeed, I was reading through his tab completion examples noting that I can already do much of this in my Ubuntu environment. Now, that doesn't mean it's not a pain to accomplish this in Bash, I just don't know. It's rather transparent to this end-user though.
- telemachos 16y ago
  That's your distro, however, not Bash itself. On OSX (for example), you must install bash_completion and source it. I'm not saying that this is a significant amount of work, but the author's complaint that other shells don't do per-app completion out of the box is valid. However, there are good reasons for keeping such completion code separate from the shell itself.
  - rmc 16y ago
    Well it shows that bash has the ability to customise the tab completion. I think this is a new feature of bash. Before that file-completion was hardcoded in.
    - telemachos 16y ago
      > Well it shows that bash has the ability to customise the tab completion. I think this is a new feature of bash. No, I don't think it's new at all. From Ian McDonald's site, Working more productively with bash 2.x/3.x[1]: > A relatively new feature in bash is programmable completion, which has been available since the beta version of 2.04. Taking a quick look at Bash's official downloads site[2], Bash 2.04 was released in March of 2000. [1]: http://www.caliban.org/bash/ http://www.caliban.org/bash/ [2]: http://ftp.gnu.org/gnu/bash/ http://ftp.gnu.org/gnu/bash/
EAMiller 16y ago
I'm always interested in the idea of learning a new shell - but the ubiquity of bash is what generally holds me back. I fear that switching gears for each system I log into would seriously break the flow.
- rikthevik 16y ago
  That's the same reason I stick with vim and a relatively vanilla vimrc. I know that I can ssh into almost any machine and be productive. GNU screen, vim and bash mean I can get work done.
  - technomancy 16y ago
    Once you throw Screen into the mix it's a lost cause IMO. Having it bind control-a by default means it's absolutely unusable without a .screenrc. Anyway, it's easy enough to just hit "curl p.hagelb.org/d | tar xzf -" first thing you do once you log in, and bam--all your stuff is there.
mithaler 16y ago
I'm perfectly fine with zsh, it gives me all that except syntax highlighting (which I don't really need)--I just use the GRML zsh scripts with some of my own personal aliases (and I don't have to learn a non-bashlike syntax). http://grml.org/zsh/ http://grml.org/zsh/
philjackson 16y ago
"When I’m browsing a path on a slow-ass NFS connection, it slows down my typing to a crawl while it does a network roundtrip ls’ing the directory every damn time I press a key." Huh?
- pyre 16y ago
  I think that he's complaining that the directory listing is hit up on every keypress, probably in an attempt to populate an auto-complete list.
  - buster 16y ago
    My guess is that it lists the directory everytime to underline correct paths (as he explains later) instead of listing a directory after each / and remembering the files and directories in it.
poink 16y ago
"Configurability is the root of all evil" I'm getting so tired of the overuse of this principle. Look, I don't care what options are available (really...) when I'm dealing with a word processor, or a spreadsheet program, or whatever. I expect people who don't use a computer so much might say the same thing about their web browser or email client. But a shell (and a text editor, and a window manager) is an extremely general tool by necessity, and I have a very specific way in which I use it to get things done. If a highly configurable terminal can make that marginally easier, over time it's worth it. I don't disagree that many/most programs could do with fewer options and more informed choices on the part of the developer, but there's nothing inherently wrong with putting well-considered options into your program. I love simple, discoverable interfaces as much as the next guy, but let us not stray too far from "fast" and "powerful" in search of "pretty" and "simple", where it counts.
- tjarratt 16y ago
  I agree completely. Every time I demo some code, people remark at my zsh setup (which I cloned from an article posted here some time ago). Unfortunately, when I suggest they do some customizations themselves, they make excuses and complain that they don't have any free time. This is completely backwards. If setting up a good shell saves you several seconds per command, then you're saving minutes every day, and several hours a month. I probably spent 30 minutes configuring zsh initially, and I occasionally spend a minute here and there tweaking small things (or not, if it looks like it will be too much trouble), but the payoff is worth it in the end. The moral of the story is try things, it really isn't as hard (or time consuming) as you think. If it is, then give up and do something else (or try later).
- pudquick 16y ago
  I think an unspoken aspect to that principle, but very much along the same thought lines as the article, is: Try something new, don't try to shoehorn this product into your existing method. "Configurability is the root of all evil" because if you can change everything, you'll eventually change it into the same stagnant workflow you've had all along. Take for example his mentioning of lack of 'man'. man has been with us since 1971. Lynx came 20 years later in 1992. There's no information that man encapsulates that couldn't be represented in hypertext - so why haven't the majority of shells moved away from man already? Sometimes that crutch of configuration can hobble you worse than it'll support you.
mhd 16y ago
Would you ever use an editor without syntax highlighting? Of course not! Speak for yourself. I also don't care a lot about "intellisense" in editors. That's why I'm not too entranced by the advanced tab completion features that a lot of shells (bash, zsh, fish) offer. Most of the time I'm better off just typing, using the history (!!, ^) or writing small aliases, scripts or functions. And in that regard, all those "modern" shells still have a lot to learn from ksh93 (or even ksh88). If I want advanced editor features in a shell, I can always use an advanced editor (i.e. use eshell).
- burgerbrain 16y ago
  You realize that all modern shells have those features too right? I know I find zsh's up-line-or-search to be invaluable. I just type the first few letters of whatever command I want to run and have run before, press whatever key I happened to bind that to (I use the up arrow), and whammo, it's completed out to the last item in history that starts with what I typed out. Wack it again to get the one before it. The main draw of the "modern" shells is their completion, particularly history related completion. The function I use for it is just one of god-knows how many, and they can be customized to the extreme. If all you want is advanced editing features, just about every shell under the sun supports vi-mode (my preference) or firing up an editor with the contents of the current line in it's buffer. Just advanced editing isn't really the main attraction.
  - mhd 16y ago
    Sorry if that didn't come across clear enough. When I said that a lot of the current shells can learn a thing or two from ksh, I was talking about the scripting part. And there it's mostly POSIX/Bourne with a few things from ksh and some idiosyncratic new features. The rc shell from Plan 9 was an interesting approach, too. Zsh/bash/fish don't try to innovate in that area. The readline library (which is the basis for most of the interactive history features) is quite nice, but I'd much rather save me some repetition than make sure that the repetitive commands can be entered fast enough. I guess it all comes down to how repetitive your shell usage is. If you're very exploratory, i.e. use different paths, systems and command line options all the time, completion helps, just like it helps you navigate a huge mess of a class inheritance tree. If you find yourself able to factor out common tasks, scripting is a bit more helpful. And most of the time, I fall into the second camp, which is why I've never found fish all that attractive. Which is what I wanted to point out (although a bit too bluntly – curse my German nature!).
presto8 16y ago
I fell in love with fish while watching a video tutorial for Babushka[1]. I immediately switched all of my boxes over to it as the default shell. Switching over decades of bash scripts was tough at first, but I bought into the whole simplified shell philosophy. But unfortunately I had to abandon fish after a solid month of using it exclusively. Active development seems to have ceased on it. There are a lot of bugs in the code, at least a couple of which make the shell almost completely unusable for me (for example, running fish from screen is problematic). The mailing lists have some activity, but nothing much from developers. At this point it seems like an abandoned project. As an example of the lack of oversight, the main project web site's domain registration lapsed earlier in the year and it is only back thanks to a good Samaritan. So I switched to zsh. And it has been pretty great. The configuration files are daunting, but it can do pretty much everything that fish can (and a whole lot more), it is under active development, and is backward-compatible with bash. [1] http://vimeo.com/6782671 http://vimeo.com/6782671 (it's about babushka, but he uses fish as the shell)
- StavrosK 16y ago
  Unfortunately, yes. I still use it as my main shell everywhere, but it has debilitating bugs that aren't getting fixed (such as fish freezing when logging in to another tty). I wish someone knew enough about it to pick it up...
- saurik 16y ago
  People are way too quick to compete rather than collaborate. Rather than writing their own shell, a shell that certainly hardly anyone was going to use and was certainly going to end up in the abandon-ware bin, they should of manned up and worked with bash/zsh to add some of these features, syntax highlighting for example, to a project where everyone could have benefited.
- terinjokes 16y ago
  That good samaritan is reads Hacker News. ;)
- mhansen 16y ago
  Development is still happening at http://gitorious.com/fish-shell http://gitorious.com/fish-shell
JoeAltmaier 16y ago
Lovely discussion here. Looks like you could argue forever. But the rule about that is, the less the differences matter, the longer you can argue. Folks campaign for what they know, because they are more productive in a familiar environment. Makes sense. But its definitely not an argument about the thing itself.

71 points by mhansen 16y ago

locopati 16y ago

Not wanting to learn a new shell, is there any movement in the bash community to implement some of these features?

ortatherox 16y ago
there's a lot of action going on in zsh at the minute, see: https://github.com/robbyrussell/oh-my-zsh https://github.com/robbyrussell/oh-my-zsh
viraptor 16y ago
I haven't seen any user-visible new features in bash the last couple of years, so wouldn't count on it. (see http://tiswww.case.edu/php/chet/bash/NEWS http://tiswww.case.edu/php/chet/bash/NEWS) On the other hand I'm slowly migrating to ipython shell as the main login shell. Since every other terminal I open runs ipython, that makes sense. It also lets me script a lot of stuff without the crazy *sh syntax.
- rickr 16y ago
  Off the top of my head didn't bash4 include multiple globs? ie * * (no space...formatting)
  - viraptor 16y ago
    Sorry - by user-visible, I meant actually the stuff that "normal" users see, not the shell programming bits. Those are polished all the time of course. Magic symbols and internal functions change all the time with new exciting ways to do basic process calling (</sarcasm>). But on the outside, it's still same old bash you run 2 years ago - no major usability improvements.

jawee 16y ago

I definitely liked the idea of fish. I tried using for a little while when I first came across it a few years ago, but it´s new features were outweighed by simple things I had become use to in Bash such as operators like && to run commands at the same time and the keyboard short-cuts (Ctrl+A, Ctrl+U, etc.).

Sandman 16y ago

"The shell is one of the places where you’ll spend most of your time as a ['nix] coder" Maybe if you're a *nix system administrator. Otherwise, no, not really. I spend most of my time in Eclipse. People who prefer using editors to an IDE spend most of their time in Emacs or Vi(m). But shell? Maybe to hack together a script now and then, but certainly not most of the time.

mileszs 16y ago
Hmm. Are you saying that one's shell is not very important, then? That one shouldn't care what shell they are using? I'm sorry, but, otherwise, I don't think I understand why you felt compelled to pick out this single quote from the article and argue about it. Could you explain your point?
- deleted 16y ago
  [deleted]
daleharvey 16y ago
I would say "most" of the time as a definite exaggeration, but I do spend close to 100% of my time between emacs / shell and a web browser.
alinajaf 16y ago
As a developer who uses vim I can confirm that the vast majority of my time is spent in the shell, running scripts, working with vcs etc. It's the equivalent of my 'IDE'. At least three other developers I currently work with have a similar setup, so I'm fairly sure its not just me.
- Sandman 16y ago
  Well, in that case - I stand corrected.
- scott_s 16y ago
  I think it's important to remember what IDE actually stands for: integrated development environment. That implies that the standard development environment used to not be integrated. And that's exactly what Unix is: a development environment where the tools are not integrated into one place. That sounds like a bad thing on the face of it, but I do not think it is. I think it allows for more flexibility.

daleharvey 16y ago

This article got my excited to try out a new shell, I moved to zsh a while ago but not been particularly impressed, its a shame their site is currently down, http://www.fishshell.org/ http://www.fishshell.org/, hopefully they realise / get it back up sharpish

stevelosh 16y ago
In the mean time, here's the Wikipedia page for it, which has a decent overview and a couple of examples: http://en.wikipedia.org/wiki/Friendly_interactive_shell http://en.wikipedia.org/wiki/Friendly_interactive_shell You can download it from Sourceforge: http://sourceforge.net/projects/fish/ http://sourceforge.net/projects/fish/
- ortatherox 16y ago
  or install it through homebrew: brew install fish

rufugee 16y ago

I've always wondered why shells based on popular scripting languages don't catch on more...especially after living with Bash's horrible (my opinion) syntax over the years, and Korn before that. I know there have been a few shells created based on perl and perhaps python, but when I played with them years ago they seemed half-assed. Is there something special about the shell that requires one to create their own scripting language? I for one would love to have a well-done, reliable login shell based on ruby...

viraptor 16y ago
There are a few shells like that. At least 5 different ruby-based (all barely doing the basic stuff, although http://rush.heroku.com/ http://rush.heroku.com/ is not bad at all). Zoidberg (perl) is ok, but there is a lot of perl involved so you can run into situations where typical bash stuff triggers perl execution... I really like iPython's psh - unfortunately it's not well known, since it's not advertised properly (they concentrate on the python's repl part a lot). It does work quite well though: http://ipython.scipy.org/doc/manual/html/interactive/shell.html http://ipython.scipy.org/doc/manual/html/interactive/shell.h...
cldwalker 16y ago
You may be interested in ripl (https://github.com/cldwalker/ripl https://github.com/cldwalker/ripl) which is modular enough to serve as a base for more complex shells. It has already been used to create a web shell (http://github.com/cldwalker/nirvana http://github.com/cldwalker/nirvana), a ruby/system shell (https://github.com/janlelis/fresh https://github.com/janlelis/fresh) and a js shell (http://github.com/cldwalker/ripl-johnson http://github.com/cldwalker/ripl-johnson).
sjs 16y ago
Traditional shells provide some small conveniences that are hard to give up. You cannot shoehorn this stuff into an existing language by defining global functions, it must be syntax. Ruby could come close by not requiring parens, but still cannot allow something like the following zsh command without extra quoting, parens, or function calls. for f ({foo,bar}/*(.)) { cp -v $f ${f%.js}.min.js } > output.txt

rmc 16y ago

For the record bash has the smart tab completion turned on by default now. (At least it does in my Ubuntu machine)

yock 16y ago
Indeed, I was reading through his tab completion examples noting that I can already do much of this in my Ubuntu environment. Now, that doesn't mean it's not a pain to accomplish this in Bash, I just don't know. It's rather transparent to this end-user though.
telemachos 16y ago
That's your distro, however, not Bash itself. On OSX (for example), you must install bash_completion and source it. I'm not saying that this is a significant amount of work, but the author's complaint that other shells don't do per-app completion out of the box is valid. However, there are good reasons for keeping such completion code separate from the shell itself.
- rmc 16y ago
  Well it shows that bash has the ability to customise the tab completion. I think this is a new feature of bash. Before that file-completion was hardcoded in.
  - telemachos 16y ago
    > Well it shows that bash has the ability to customise the tab completion. I think this is a new feature of bash. No, I don't think it's new at all. From Ian McDonald's site, Working more productively with bash 2.x/3.x[1]: > A relatively new feature in bash is programmable completion, which has been available since the beta version of 2.04. Taking a quick look at Bash's official downloads site[2], Bash 2.04 was released in March of 2000. [1]: http://www.caliban.org/bash/ http://www.caliban.org/bash/ [2]: http://ftp.gnu.org/gnu/bash/ http://ftp.gnu.org/gnu/bash/

EAMiller 16y ago

I'm always interested in the idea of learning a new shell - but the ubiquity of bash is what generally holds me back. I fear that switching gears for each system I log into would seriously break the flow.

rikthevik 16y ago
That's the same reason I stick with vim and a relatively vanilla vimrc. I know that I can ssh into almost any machine and be productive. GNU screen, vim and bash mean I can get work done.
- technomancy 16y ago
  Once you throw Screen into the mix it's a lost cause IMO. Having it bind control-a by default means it's absolutely unusable without a .screenrc. Anyway, it's easy enough to just hit "curl p.hagelb.org/d | tar xzf -" first thing you do once you log in, and bam--all your stuff is there.

mithaler 16y ago

I'm perfectly fine with zsh, it gives me all that except syntax highlighting (which I don't really need)--I just use the GRML zsh scripts with some of my own personal aliases (and I don't have to learn a non-bashlike syntax). http://grml.org/zsh/ http://grml.org/zsh/

philjackson 16y ago

"When I’m browsing a path on a slow-ass NFS connection, it slows down my typing to a crawl while it does a network roundtrip ls’ing the directory every damn time I press a key." Huh?

pyre 16y ago
I think that he's complaining that the directory listing is hit up on every keypress, probably in an attempt to populate an auto-complete list.
- buster 16y ago
  My guess is that it lists the directory everytime to underline correct paths (as he explains later) instead of listing a directory after each / and remembering the files and directories in it.

poink 16y ago

"Configurability is the root of all evil" I'm getting so tired of the overuse of this principle. Look, I don't care what options are available (really...) when I'm dealing with a word processor, or a spreadsheet program, or whatever. I expect people who don't use a computer so much might say the same thing about their web browser or email client. But a shell (and a text editor, and a window manager) is an extremely general tool by necessity, and I have a very specific way in which I use it to get things done. If a highly configurable terminal can make that marginally easier, over time it's worth it. I don't disagree that many/most programs could do with fewer options and more informed choices on the part of the developer, but there's nothing inherently wrong with putting well-considered options into your program. I love simple, discoverable interfaces as much as the next guy, but let us not stray too far from "fast" and "powerful" in search of "pretty" and "simple", where it counts.

tjarratt 16y ago
I agree completely. Every time I demo some code, people remark at my zsh setup (which I cloned from an article posted here some time ago). Unfortunately, when I suggest they do some customizations themselves, they make excuses and complain that they don't have any free time. This is completely backwards. If setting up a good shell saves you several seconds per command, then you're saving minutes every day, and several hours a month. I probably spent 30 minutes configuring zsh initially, and I occasionally spend a minute here and there tweaking small things (or not, if it looks like it will be too much trouble), but the payoff is worth it in the end. The moral of the story is try things, it really isn't as hard (or time consuming) as you think. If it is, then give up and do something else (or try later).
pudquick 16y ago
I think an unspoken aspect to that principle, but very much along the same thought lines as the article, is: Try something new, don't try to shoehorn this product into your existing method. "Configurability is the root of all evil" because if you can change everything, you'll eventually change it into the same stagnant workflow you've had all along. Take for example his mentioning of lack of 'man'. man has been with us since 1971. Lynx came 20 years later in 1992. There's no information that man encapsulates that couldn't be represented in hypertext - so why haven't the majority of shells moved away from man already? Sometimes that crutch of configuration can hobble you worse than it'll support you.

mhd 16y ago

Would you ever use an editor without syntax highlighting? Of course not! Speak for yourself. I also don't care a lot about "intellisense" in editors. That's why I'm not too entranced by the advanced tab completion features that a lot of shells (bash, zsh, fish) offer. Most of the time I'm better off just typing, using the history (!!, ^) or writing small aliases, scripts or functions. And in that regard, all those "modern" shells still have a lot to learn from ksh93 (or even ksh88). If I want advanced editor features in a shell, I can always use an advanced editor (i.e. use eshell).

burgerbrain 16y ago
You realize that all modern shells have those features too right? I know I find zsh's up-line-or-search to be invaluable. I just type the first few letters of whatever command I want to run and have run before, press whatever key I happened to bind that to (I use the up arrow), and whammo, it's completed out to the last item in history that starts with what I typed out. Wack it again to get the one before it. The main draw of the "modern" shells is their completion, particularly history related completion. The function I use for it is just one of god-knows how many, and they can be customized to the extreme. If all you want is advanced editing features, just about every shell under the sun supports vi-mode (my preference) or firing up an editor with the contents of the current line in it's buffer. Just advanced editing isn't really the main attraction.
- mhd 16y ago
  Sorry if that didn't come across clear enough. When I said that a lot of the current shells can learn a thing or two from ksh, I was talking about the scripting part. And there it's mostly POSIX/Bourne with a few things from ksh and some idiosyncratic new features. The rc shell from Plan 9 was an interesting approach, too. Zsh/bash/fish don't try to innovate in that area. The readline library (which is the basis for most of the interactive history features) is quite nice, but I'd much rather save me some repetition than make sure that the repetitive commands can be entered fast enough. I guess it all comes down to how repetitive your shell usage is. If you're very exploratory, i.e. use different paths, systems and command line options all the time, completion helps, just like it helps you navigate a huge mess of a class inheritance tree. If you find yourself able to factor out common tasks, scripting is a bit more helpful. And most of the time, I fall into the second camp, which is why I've never found fish all that attractive. Which is what I wanted to point out (although a bit too bluntly – curse my German nature!).

presto8 16y ago

I fell in love with fish while watching a video tutorial for Babushka[1]. I immediately switched all of my boxes over to it as the default shell. Switching over decades of bash scripts was tough at first, but I bought into the whole simplified shell philosophy. But unfortunately I had to abandon fish after a solid month of using it exclusively. Active development seems to have ceased on it. There are a lot of bugs in the code, at least a couple of which make the shell almost completely unusable for me (for example, running fish from screen is problematic). The mailing lists have some activity, but nothing much from developers. At this point it seems like an abandoned project. As an example of the lack of oversight, the main project web site's domain registration lapsed earlier in the year and it is only back thanks to a good Samaritan. So I switched to zsh. And it has been pretty great. The configuration files are daunting, but it can do pretty much everything that fish can (and a whole lot more), it is under active development, and is backward-compatible with bash. [1] http://vimeo.com/6782671 http://vimeo.com/6782671 (it's about babushka, but he uses fish as the shell)

StavrosK 16y ago
Unfortunately, yes. I still use it as my main shell everywhere, but it has debilitating bugs that aren't getting fixed (such as fish freezing when logging in to another tty). I wish someone knew enough about it to pick it up...
saurik 16y ago
People are way too quick to compete rather than collaborate. Rather than writing their own shell, a shell that certainly hardly anyone was going to use and was certainly going to end up in the abandon-ware bin, they should of manned up and worked with bash/zsh to add some of these features, syntax highlighting for example, to a project where everyone could have benefited.
terinjokes 16y ago
That good samaritan is reads Hacker News. ;)
mhansen 16y ago
Development is still happening at http://gitorious.com/fish-shell http://gitorious.com/fish-shell

JoeAltmaier 16y ago

Lovely discussion here. Looks like you could argue forever. But the rule about that is, the less the differences matter, the longer you can argue. Folks campaign for what they know, because they are more productive in a familiar environment. Makes sense. But its definitely not an argument about the thing itself.