Hacker News new | past | comments | ask | show | jobs | submit login
Fish: Finally, a command line shell for the 90s (ridiculousfish.com)
442 points by rjshade on June 6, 2012 | hide | past | favorite | 146 comments



I've been using the original fish[1] for years. I'm very biased, I love fish for many reasons and despite the claims that zsh can do the same things I've never had cause to switch from it. Now it was quite disappointing to see the original fish project seemingly halted. So this isn't simply great news, in the sense that development has been picked back up in the fishfish fork, some great improvements have been made at the same time!

    * autosuggestion
      (this actually has a great amount of utility for me.
       it complements tab-completion quite well!)
    
    * optional web-based config
      (great for quickly editing your config settings)
    
    * speed improvements
      (although I never suffered from much lag with fish
       to begin with)
Overall I think the usability and utility of fish is greatly improved in this fork. Also it's worth pointing out that in terms of out-of-box functionality, some of fishfish features would be very hard to match. Things like autocompletion and simple history scrollback based one partial string matching set fish apart from the pack imo. So far, I'm quite impressed and I hope that more people adopt fishfish as the de facto replacement for fish.

[1] http://fishshell.com/


Have they found a better way for setting environment variables for single commands? The following bash command looks quite ugly with fish:

  LANG=C foo


can zsh autocomplete man pages?


Yes it can. Add something like this to your zsh config:

  zstyle ':completion:*:manuals'    separate-sections true
  zstyle ':completion:*:manuals.*'  insert-sections   true
  zstyle ':completion:*:man:*'      menu yes select


This does not work for me. If I type "tree -" and press [tab], nothing happens.


That's it. This thread sold me. Installing zsh now!


Tried fish yet? I prefer it to zsh ...


Yes. zsh can also auto-complete command line arguments for a lot of commonly used commands (including the GNU utilities, git, mutt, mplayer, imagemagick's convert and others.)


Bash too can do that. It does by default in Debian for instance, it also does cool things like autocompleting filenames based on which command is already typed (so it won't autocomplete to some pdf filename if the command is mplayer), autocompletion depending on config files (alias from ~/.ssh/config and /etc/hosts, remotes from the git config, package names when the command is apt-*…).

About fish, for the history based autocompletion of commands, how is that different from Bash's C-r?


Bash has completion, of course, but does it have autocompletion? Big difference as getting completions without hitting the tab key changes how you interact with the line editor.


Bash's auto completion is a child's toy compared to Zsh's.


People say this kind of thing a lot, but I’m pretty sure it’s simply not true. bash-completion handles pretty much everything I can imagine already, and can be extended to handle anything you can express programmatically.


Care to back that FUD up with some proof?


And when it cannot complete arguments, just hit `ESC h` or Alt-h to get help on the current command you're typing. (See also: `ESC q` or Alt-q)


I use fish (http://fishshell.com/), and it's amazing. However, they're missing the most important feature from their front page: Syntax highlighting!

Valid executables are colored green, as you type. Invalid commands are red, as you type. Valid files are underlined, as you type.

Like the carpenter who can feels the feedback of the grain of the wood through the handle of his plane can adjust his technique as he planes, fish shell lets me 'feel' the programs and files I'm working with through the shell.

And that makes me happy.


I stopped using fish a while ago, when it would crash whenever I opened a console session (so I couldn't do anything when X didn't start). I switched to zsh with fish emulation, but lately I realized I have a shell that takes much longer to start up and basically does everything fish does, and nothing more.

If fishfish is more stable, I'll switch in a heartbeat.


> I stopped using fish a while ago, when it would crash whenever I opened a console session (so I couldn't do anything when X didn't start)

This is why I launch my interactive shell from a failsafe /bin/sh instead of using chsh. If zsh ever messes up horribly, I end up back in a good old bog standard shell prompt.


I was just wondering how you accomplish that.


I put this at the end of my ~/.profile:

    REALSHELLS="/usr/local/bin/zsh /usr/bin/zsh"
    for REALSHELL in $REALSHELLS; do
    	if [ -e $REALSHELL ]; then
    		if ! $REALSHELL -l; then
    			echo "$REALSHELL exit $?"
    		fi
    		echo "$SHELL exit in 1s, Ctrl-C to abort"
    		sleep 1 && exit
    	fi
    done
    echo "No shells in [$REALSHELLS] found, falling back to $SHELL"


I'd been using fish for a year or two before switching to zsh too.

The main reason for me to give it up is because I could not get it to work smoothly with rvm.

I've gotten quite used to zsh by now, and I have to say, I don't feel much for having another go at fish just to run into the same limitations again.


I just downloaded it and while it looks awesome, I see the rvm problem. I haven't used zsh but I'm assuming from your comment that zsh is compatible with RVM. Seems like it shouldn't be too hard to write a fish version of the script that sets up your rvm environment, but if you've gone down that path and it proved too painful I won't bother. However, perhaps fish + rbenv works. Has anyone tried that?


Yes, I switched from rvm to rbenv because rvm didn’t work with fish. rbenv did work with fish.

I switched away from fish after that because go (a directory-jumping tool) required bash to install (http://code.google.com/p/go-tool/wiki/InstallNotes). I didn’t know how to port that bash code to fish, since I don’t know bash scripting, and I also anticipated that I would keep finding cool programs that didn’t work with fish.


Just add those two files listed here (https://github.com/eventualbuddha/fish-nuggets/commit/186775...) to ~/.config/fish/functions, and everything should work out just fine.


zsh has a plugin for fish-style syntax highlighting: https://github.com/zsh-users/zsh-syntax-highlighting


~ git clone https://github.com/zsh-users/zsh-syntax-highlighting.git Cloning into zsh-syntax-highlighting... warning: remote HEAD refers to nonexistent ref, unable to checkout.

:(


A bit more context: Ridiculous Fish is an Apple Engineer on the AppKit team. He also has a nice hex editor for the Mac (Hex Fiend) and an interesting programming Blog:

http://ridiculousfish.com/blog/


Man, I used to use fish. It was great. It was like all the things people eventually make zsh do but in one convenient binary.

I think my favorite feature was that history was instantly shared among all your open fish instances.


zsh used to do this for me (back when I used it; switched back to bash about a year ago now), and it was the most _annoying_ thing it ever did. My typical workflow (when working on a software project) involves a pair of terminals for compiling and execution, an editor window (whether gvim or kate/kile/kdevelop etc.), and a documentation terminal for manpages.

Oftentimes my execution lines are somewhat long -- enabling/disable debugging info in certain sections of the program while tracing programs, etc, and I'd not want to type them out continuously. As a result I'd use the command history a lot, muscle memory would automatically hit CTRL-P once I switched to one of my execution terminals. If I'd visited something in the documentation terminal in the meantime, I'd be staring at 'man 2 timer_create' instead of my expected './aesalon --set listen=6421 --set ::debug-shm --set ::debug-interaction'. The third-second or so I'd need to do a sanity check would seriously interrupt my train of thought.

It's neat, and I can see why people like it. But for my particular one use-case of terminals/shells, it was annoying. Took me about a week before I realized just how much it was slowing me down and disabled it.

[I probably should have just set up another zsh configuration for those particular terminals, but enough years with bash have trained me, I guess, to not expect it from my shell.]


You could have simply turned history sharing off...


I prefer a middle ground, in which entries from multiple sessions are interleaved in the history file, but individual in-memory histories don't reflect what happened in other sessions in the meantime.

For future reference, I use the following Zsh history options:

  setopt incappendhistory
  setopt extendedhistory
  setopt histignorespace
  setopt histignoredups


I think what would be slickest is if up-arrow and down-arrow navigate local history, but history-search would navigate all history... I wonder if I can make it do that.


What do you use now? And why did you switch?


I didn't get this right from the start, but this is a fork of fish(shell), which has been around for quite a while:

http://fishshell.com/


I'm on the fish mailing list and it has been well received by current contribs and the original author. I expect that the two forks will be one at some point.


Why did they pick the exact same name?


Presumably because fish hasn't been updated since 2009 and they expect their fork to become the new standard version.

http://ridiculousfish.com/shell/beta.html

"Welcome to our fork of the fish shell, a command line shell like bash. Its working name is fishfish, but I hope eventually it will just be fish!"


Obvious joke is obvious, but he could have called it the Unno Fish Shell?

Looks interesting. I expect my fingers will be even more confused than ever switching machines now (they've never learned that Alt-3 isn't # on linux or that middle-click isn't paste in Putty)


There's no reason middle-click shouldn't be paste on PuTTY -- it's a configuration option.


That one always bites me at other people's desks; I'd figure out how to reconfigure it if it was mine. But there's always something jarring like that when you switch between similar-but-not-quite-the-same environments.


i've gotten to the point where i can subconciously key off the window chrome to know how to paste. (half my coworkers use xterm, the other half putty.)


It's not called that yet: "Its working name is fishfish, but I hope eventually it will just be fish!"

The ambition is quite reasonable as work on the fish shell itself has petered out, there was a recent dead cat bounce after a long fallow period, but it seems to be back to stasis there.


Well.. they do have quite a list of possibilities to piggy back off ( http://en.wikipedia.org/wiki/List_of_common_fish_names ) that could reduce confusion but still maintain similarity.


I don't believe that's an option for the author as he's known as "fish" around the web. :)

http://ridiculousfish.com/blog/about.html


"ghoti" would be a perfect name for a ridiculous fish, though (http://en.wikipedia.org/wiki/Ghoti)


If you run chsh and get error "/usr/local/bin/fish: non-standard shell" simply add /usr/local/bin/fish to /etc/shells. Just to save you a Google search :)


They need to update the slogan? "A command line shell for the 90s" doesn't really draw me in.

What I want to know:

1. In what specific ways is it better than zsh?

2. Is it absolutely, rock-solid stable?


1:

a. Superb readline colouring. Nonexistent commands are shown in red, commands that exist and are on PATH in green. Unclosed string literals become obvious.

b. A history search that is orders of magnitude better that Ctrl-r in Bash. (Though oh-my-zsh has the history-substring-search plugin which provides this functionality.)

c. Features work out of the box, fish helps you avoid managing a .zshrc equivalent file.

d. Tab completion offers hints. If I type l<tab><tab>, I get:

  leaftoppm  (Convert Interleaf image format to a portable anymap)
  less                                          (Opposite of more)
  lessecho                                 (Expand metacharacters)
  lessfile                        ("input preprocessor" for less.)
  lesskey                          (Specify key bindings for less)
  lesspipe                        ("input preprocessor" for less.)
  lexgrog                  (Parse header information in man pages)
(These summaries are the first lines of the man pages.)

2: I've only seen it crash on me once, which matches my experience with zsh. YMMV.

I used fish exclusively for a number of years, but eventually moved back to something sh-compatible. Too many wrapper scripts assume this.


I do not understand your last paragraph. Don't your wrapper scripts have "#!/bin/sh" at the top?


That's being explicit, the problem is with wrapper scripts that omit that, assuming a sh compatible shell.

Still running fish on one of my systems, excited to see new development work as it was getting past the point where I was comfortable using it on anything new.


An old trick for convincing (some) shells that your script is an sh-compatibile shell is to use a colon on the first line. Support for this trick was added to fish back in 2007: https://gitorious.org/~ridiculousfish/fish-shell/fishfish/bl...


Thanks for the pointer. I can't say how much I wish more people would include pointers to code fragments or specific commits on a site called hacker news.

Tangential question: is gitorious's syntax highlighting usually this awful? The first thing I need from syntax highlighting is distinguishing comments from code.


I'm not sure how to use it. Can you give an example of where it works, and what changes if this is not done?


The point isn't executables that happen to be written in {ba,}sh, it's wrappers that attempt to add functionality to your commandline. For example, Python's virtualenv and Ruby's rvm presumably don't work.


I agree with your point. But virtualenv has support for fish:

    . your_env/bin/activate.fish
https://github.com/pypa/virtualenv/blob/develop/virtualenv_e...


Ah, I didn't think of that (no experience with neither virtualenv nor rvm). So thanks for the clarification.


Please elaborate on point 1b. I certainly see ways ctrl-r can be improved, but orders of magnitude (while obviously subjective in something like this) would surprise me. That said, I hope to be surprised!


Sure. There's no single feature improvement that is much better, but when considering the improvements together the difference is striking.

1. The search term is highlighted.

2. The search is far more discoverable, its key binding means you can stumble across it.

3. The up cursor key is a better key binding choice. Pressing up without a search term may be considered as searching for commands that match "", namely everything. This conforms with fish's aim for orthogonality.

4. (Most importantly) The up cursor key has a natural undo button, down. Quick quiz: if you type "Ctrl-r foobarbaz", how do you get back to a terminal you can type in, preserving your search term? You can't. Pressing "Esc" dumps you in the middle of your history with something matching the first few characters of your search term. (Assuming you have nothing in your history matching 'foobarbaz')

Similarly, if you press "Ctrl-r foo Ctrl-r", you will get the second item in your history that matches foo. There's no way to get back to your first search result without repeating the search.

5. You can use previous commands as search terms. For example, I ran "mvn clean install", then hit "Ctrl-C" when I wanted to skip tests. I pressed "<Up> <Space> <Up>" and I was searching through all my history that contains "mvn install ". Using "Ctrl-C" I'd have had to retype "mvn clean install ".


Thanks! 1, 4, and 5 in particular do seem useful. Having up search and down cancel is a win for orthogonality, but loses a touch in flexibility (if I'm searching, find something, and then realize I want to run the command before or after it, for instance). On balance, I think fish is doing it right for new users but I don't see anything there that's worth the shift for those of us who have the muscle memory for the other.

One thing I've missed from ctrl-r is the ability to drop in (an implicit or explicit) .* in my search - often, I start my search and hit a line, and I know what will disambiguate but it's a ways down the line.


> if you press "Ctrl-r foo Ctrl-r", you will get the second item in your history that matches foo. There's no way to get back to your first search result without repeating the search.

Actually, ctrl-shift-r goes backwards.


When I saw the slogan, I thought it was ironic. I kind of like it.


Agree. I'm happy there's finally a Mac term app that can support the same emacs color scheme I was using on a Linux desktop 14 years ago!


To be fair, it's "Finally, a command line shell for the 90s."

I couldn't agree more. We've been using shells from the 80's for far too long.


1) I don't know. I haven't dug that far into zsh, I didn't like it on the surface. Or rather I love both surface and depth of fish enough that I haven't yet investigated zsh.

Maybe you could tell us? Here's a pretty good article on fish by its original author: http://arstechnica.com/information-technology/2005/12/linux-...


I'm wondering about the answer to #1 as well. After trying this out for a bit there's nothing obvious and there are definitely things I miss.


1. No need to mess with configs. Works out of the box.

2. Breaking Bourne Shell compatibility. Personally I find Bourne syntax hard to learn and hard to read. Fish syntax is much better. [1, 2]

[1]: http://en.wikipedia.org/wiki/Friendly_interactive_shell

[2]: http://ridiculousfish.com/shell/user_doc/html/index.html


Sounds like there's no reason for me to switch.

I've already messed with configs and everything is stable now, so that's a sunk cost.

I already know bourne-style syntax, so learning fish (even if it's easier) is an added cost, not to mention the fact that I have to work on various boxes that I can't install fish on so it's easier to have my fingers know how to operate a single shell (zsh) that's generally backwards-compatible with bash (which is ubiquitous).


Funny I was about to say the same thing about installing on systems. When you're a systems person or work with many different customers you can't ask them to install a custom shell. Try explaining to the CIO at a major bank why all his linux boxes need fish shell installed.

So we get stuck back at the minimal set of SH syntax that I learned to master some 25 years ago.


I tried fish a few years ago, but stopped for some reason that I can't remember. I will try again, and will either keep using it, or will remember why I stopped in the first place.


I'm so glad I'm not the only one that does this.


Ahhh, finally. I used to use fish for many months, but after i figured that there is no development anymore, i switched back to bash...

Now it's time to change to fishfish and decide what's best suited for me! :)

edit: Also, i am disappointed that the ASCII-art fish on the frontpage is actually a picture and not ascii :(


Very poor support for alias:

    batman@batman ~/D/S/rails> alias foo="cd ~/"
    fish: Could not expand string '$tmp[2]'
    /usr/local/share/fish/functions/alias.fish (line 19): 			set body $tmp[2]
                                                                                           ^
    in function 'alias',
      called on standard input,
      with parameter list 'foo=cd ~/'
Makes me wonder what else I'll have to relearn to use fish. Can someone tell me if it's worth the effort?

Edit: didn't take me long to find something worse. I defined my aliases as functions, but apparently fish executes all functions when it sources the file? By putting this function in:

    function foo
    cd ~/
    end
I was able to send fish into an infinite loop.


Howdy, author here.

fish doesn't have aliases, only functions. 'alias' is itself a function, which looks like it has a bug. I filed https://github.com/ridiculousfish/fishfish/issues/48 to track this.

(The usual way a fish user would add this function would be to put a file 'foo.fish' in ~/.config/fish/functions, or to use 'funced fish' to create one interactively.)

As for your infinite loop - fish certainly does not execute all functions when it sources the file. I wasn't able to reproduce your problem. Can you explain how you added this function?

Thanks!


I never use alias in fish, just functions - see the Fish design document, law of orthogonality: http://fishshell.com/user_doc/design.html#ortho

That infinite loop thing is a bug for sure, it shouldn't do that! I have defined that type of function to jump to the directories of current projects - that should work.


> I have defined that type of function to jump to the directories of current projects - that should work.

What do you mean? Even if I define a function like so:

    function foo; cd /var; end
It shouldn't automatically execute the function and cd into /var.


No, exactly, for me it wouldn't.

For example, I'd type something like this:

  function gogogo
    cd ~/src/teh_project
  end
  funcsave gogogo
Then the "gogogo" function is available in all shells and loaded on startup - but not executed until I do so myself. From what I understand you wish to have the same functionality, and are doing the same thing, but are getting totally weird results.

Explicitly: No, it definitely shouldn't try to run functions right away. Bug!

FWIW I haven't tried the fishfish fork/update, just used the original version for a number of years.

It'd be greatly appreciated if you could spare a moment to send a bug report! (I'm not a dev by any means, just a fish lover ...)


It totally worths the effort. It wouldn't take more than an hour, but even if it would take you 10 hours, it would still worth the time.


Could you elaborate? What features do you regularly use? What happens when you log in to a machine that doesn't have fish?


That alias-example works for me with the current fish version from Arch-Linux. (And that seems to be the fishfish fork, from what I can tell.)


It gives me great joy every time a new command-line-related project is released (or, as in this case, gets a major update). I will dedicate a few hours of my weekend to take this for a thorough spin!


Looks like the author is trying to replace the old fish (http://fishshell.com/)

Welcome to our fork of the fish shell, a command line shell like bash. Its working name is fishfish, but I hope eventually it will just be fish! (http://ridiculousfish.com/shell/beta.html)


I really like what I see, but I don't understand their reasoning for leaving out history substitution (see http://ridiculousfish.com/shell/user_doc/html/faq.html#faq-h...).

Why can't a better interactive history go hand in hand with something like "sudo !!"?



Why does xargs under fish not accept {} as a replstr like it does with bash?

    find . | xargs -I {} grep pat {}
On OS X fish this gives "xargs: replstr may not be empty" and on Linux fish I get "xargs: command too long". Using % as the replstr for example does work though.


The beauty of fish is that it handles lists much better than bash - it kind of has xargs "baked in". If I understand the example correctly, it finds every file under the current directory and greps for "pat" in each file.

In fish you could do this:

  grep pat (find .)
... or this:

  for i in (find .)
    grep pat $i
  end
The first example would work correctly in fish, but AFAIK it wouldn't work in bash. The is because every line from the command substitution is automatically escaped and quoted in fish. The small drawback is that a symbol-heavy commandline sometimes needs a few extra \ escapes - the power to handle lists of lines (i.e. lines from stdin or from command substitution) is bought for a little extra escaping. And it's a good deal IMO.

And the for loop in fish is so elegant and convenient that it's worth using for small random stuff.

(Everything I say is pending that I understand the find/xargs/grep example!)


Yep, you understood it fine. ('pat' was short for 'pattern'. It was just an example)

Wow, that 'autoescaping the commands in parens' syntax is great. But it doesn't seem to be list related. For example: grep pattern (echo "foo.txt") just passes the result from the echo to grep. It's grep which is doing the right thing with a list, right? Still this is interesting. So fish stuff isn't necessarily written left to right and joined with pipes, instead it's written in nested form like in a more modern langauge.

Alas you still need to use the "find | grep" technique in fish because of the argument size limit. For example:

    grep pattern (find .)
results in:

Failed to execute process '/usr/bin/grep'. Reason: The total size of the argument and environment lists 34kB exceeds the operating system limit of 34kB. Try running the command again with fewer arguments.

The equivalent in bash gives you:

-bash: /usr/bin/grep: Argument list too long


I'm not sure why the recommended replacement string to use with xargs's -I is "{}". I just use "XXX" as the replacement string and stop worrying about how the shell is interpreting metacharacters in this particular case:

    find . | xargs -I XXX grep pat XXX


Fish does brace expansion, even for empty braces. In order to actually pass braces to xargs, do:

    find . | xargs -I \{\} grep pat \{\}


OK, thanks.


I just tried it out, I use zsh and don't really look for replacement, but my first impression is that things are much more snappy and significantly faster in fish. I liked how help opened browser, even though I was startled a little bit.


Under the known bugs and issues:

History file should apply some kind of maximum history length

Fine, but the default needs to be large, like 100MB. Disks are big now. I hope ridiculousfish agrees.


Hi, ridi here!

This bug is actually fixed with my changes (see the release notes at http://ridiculousfish.com/shell/release_notes.html). The maximum history length is now 250k unique items, with an LRU discard policy. A full history would be around 15 MB.

Processing time is one concern. fish doesn't do anything as clumsy as keeping the entire file in memory, but scanning a large history file can still add up.

But the larger concern is writing it out. fish saves its history atomically by writing an entirely new file to disk, and swapping it in. You may not notice a 100 MB file, but you would probably notice a frequent 100 MB write!


fish saves its history atomically by writing an entirely new file to disk, and swapping it in

That's so you get sync'd histories across one user's logins? Good feature, but I need my history. It's invaluable to me. Still, maybe 250k lines is enough. Is there a way I could bump that up and judge for myself the consequences?


Thanks for the reply and for picking up this project. So far I'm loving the extra interactivity of fish.


Disks are big, but I think 100MB is maybe a bit excessive...even 10MB gives you 40k lines of history, at 256 bytes per line, and that is a conservative estimate.


400k lines sounds like less than a lifetime at the terminal. So maybe 200MB would be safer - thanks for the reminder! ;)


100 MB is indeed small but there are privacy concerns with storing hundreds of thousands of lines of history. Do you really want every command you've typed for the last several years to be visible to anyone with physical access to your box? It could contain clear-text passwords to other machines.

I'd be happy with 100 MB as a maximum size but there should also be time-based limits, like remove anything from history that is older than a few months.


Do you really want every command you've typed for the last several years

Yes.

visible to anyone with physical access to your box

Maybe not. That's an auth problem, not a reason to throw away your archives. I keep all my email even though there's probably something in there embarrassing to me given some audience.


Just FYI, You can hide sensitive commands (like those that require you to type your password in plain!) in bash, by simply adding an space at the beginning (after adding `export HISTCONTROL=ignorespace` in your bash_profile, of course). I don't know about fish yet.

more: http://www.linuxjournal.com/content/using-bash-history-more-...


The package doesn't work on Debian testing/unstable/experimental: fish: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by fish)

(I am running GLIB 2.13).

I tried compiling from source, but I am clearly missing dependencies. So far, I had to install:

libncurses5-dev, gettext, xsel, libxt-dev (alternatively, I could use --without-xsel and ignore these last two depends). You may want to add this to the project somewhere.

At any rate, I am looking forward to giving this a try.


Maybe you already know this, but glibc and glib are two entirely different libraries. (The similarity in their names is unfortunate.) So be precise when asking for help.


Whoa. Just installed it and it's beautiful. I'm most surprised by fish_config which fires up a webserver to set config information -- awesome, really awesome.


Unfortunately I can't try this right now, but do suggestions support something like taking only part of the suggestion? I.e. move left/right from cursor into the suggestion instead of writing. Shift+Arrow would work as expected, thus allowing quickly using part of the suggestion and writing the rest out if needed. It seems to be a better solution than deleting things from the end.


Can you add custom completions? I don't see proper completion for tmux sub-commands or git sub-commands.


Some instructions here: http://ridiculousfish.com/shell/user_doc/html/index.html#com...

You can put this stuff in your ~/.config/fish/config.fish .

There's a useful set of completions and utilities at https://github.com/zmalltalker/fish-nuggets with a variety of forks that add and remove various things. If nothing else, it's a pretty solid starting point.


This is missing the point of a shell by a mile. Extra features are nice. As an extra. Preferably on top of a rock solid platform that works everywhere, on everything, under any conditions. Same reason your PC boots in 16 bit real mode.

I'm quite happy living in the 80s.


Isn't this entire shell an extra? I wouldn't replace bash with it, it seems more like a nicer interactive frontend but you could always drop down to bash if it didn't work for something. Sort of like KDE being a more fully-featured frontend to X, but you can drop back to Fluxbox if you want to test X without all the gizmos.


Your PC boots in 16 bit real mode because Intel is too locked into x86 to get rid of legacy modes and instructions. A proper architecture starts in its intended mode.

But I agree, adding all this fluff to a shell is a bit much. I use bash and keep ls colors disabled.


Hard to tell from docs if fish has vi mode? vi mode is the main thing I love about bash.


Under missing features[1] you can find "Complete vi-mode key bindings", so I think it doesn't have it yet.

[1] http://ridiculousfish.com/shell/user_doc/html/index.html#tod...


When using auto-completion is there a way not to use arrow keys? Especially when completing a match it seems like I need to use the right arrow key. I would prefer not to use arrow keys at all, but use something like CTRL+(HJKL).


Yes, you can use Ctrl + F instead of right arrow key to autocomplete.


Well, the normal tab-based autocompletion works like you'd expect. You can go backwards in history the same way you do with the up arrow by using CTRL+P, and CTRL+N is the same as down arrow.


I've never used anything besides bash before. I use a terminal a lot, but don't really do anything fancy so I thought switching would be a waste of time. Reading the features in fish though made me want to give it a whirl.



Don't see why not.


Right, but I meant, "Tell me how". I figured it out and dashed off a quick post: http://herdrick.tumblr.com/post/24563032599/display-git-bran...


You can also find `how' on the Arch-Linux Wiki (https://wiki.archlinux.org/index.php/Fish#Configuration_Sugg...).

Also judging by your blog you might like something like

    PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND ; }"'echo $$ $USER \
                   "$(pwd) $(history 1)" >> ~/.bash_eternal_history'
in your .bashrc, so that you don't have to abuse the bash-history for keeping a lifetime of commands around.


Is it abuse? It hasn't slowed anything down yet.

Also, in the blog post I linked to the link you mention.


I don't know whether it's abuse. I just don't trust bash's history enough.

Yeah, I now noticed that you already put that link in the blog.


And to be clear, what's described in that link doesn't work, at least not on my OS X machine. Thus the code in my blog post.


Doesn't seem to be in Homebrew yet (I mean this fork; the original Fish is there).

That brings me to the question: What is different in this fork? Is it worth to use this fork or should I stick to the original?


The features mentioned on the homepage were added to this fork.


How to I remove it? I set fish as default, but I realized that none of my scripts in .bash_profile worked... and it's too much work to rewrite everything again.


I wonder if there is a modern shell with csh like syntax. I know this may sound anal retentive, but I prefer the csh syntax to the sh syntax.


I've been used it. I think lazy people will love it.


I tried fish some time ago. I thought it was pretty cool, but I didn't end up using it because it lacked Vi(m) key bindings.


Anyone managed to make it run in cygwin? Bash completion in cygwin makes the shell very slooooow to start.


I've installed this on my Mac, love it!


Please, some budding genius, get fish to work with Cygwin! Then I can rule the world as fate intends.


So, is this new fish fully compatible with sh syntax? IIRC the original one was not.


I guess for a sh-compatible version you could use fizsh (http://sourceforge.net/projects/fizsh/) but it doesn't seem as mature in other areas.


No. I prefer its syntax, but since it is different from anything else I find it hard to remember. So I write my scripts in bash but use fish at the command line. Best of both.


Is there any possibility to provide vi mode? Like 'set -o vi' in bash.


you could always put "set editing-mode vi" in your ~/.inputrc .. this has the advantage of affecting all programs which use readline, gnuplot, python shell, mysql etc.. I also put

"\e[A": history-search-backward

"\e[B": history-search-forward

in the ~/.inputrc which maps arrow up/down to history search.. more tips here http://vim.wikia.com/wiki/Use_vi_shortcuts_in_terminal

zsh has a better vi-mode than most of the shells I've tried, although I can't say I've made a serious attempt at using fish..

the color syntax highlighting implemented in zsh is much slower than the fish equivalent though, and can be quite laggy ime


Ahaha. I like the sense of humor.

I shall have to give it a try!


Where's the bash_profile or bashrc equivalent?



I don't see that there...


It should be there if you've installed fishfish, if you feel it's a bug please consider opening an issue on github : https://github.com/ridiculousfish/fishfish/issues


The directory ~/.config/fish should be there. However, you'll have to create the file config.fish inside that directory, if you want to use it.

I'd hazard a guess that fish_config may do that for you.


Who doesn't package an RPM? >:|


'cutting edge technology called threads' oh wow


:)

I'm sure you know that that's a joke ... ?


"Watch out, Netscape Navigator 4.0!"


I just tried fish for the first time, and it couldn't do the very first thing I tried to do, which was source my .zshrc. It doesn't have 'export', has some kind of nonstandard syntax for 'alias', and that was enough to get me to give up.

Since there are many fish fanboys here, and since it seems like it would be cool if it worked, I'm hoping someone can tell me the simple obvious thing I should have done. Can you help?


Shell rc files aren't interoperable. .bashrc, .cshrc, and .zshrc work only with the shells named on the tin.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: