141–150 of 188 posts
I can clearly see the difference between Fish and regular ol' bash, but struggling to see what value Fish adds above prezto/zsh. Could anyone help me out here?
- not assuming you're using an outdated terminal so doesn't waste a column when using a right-hand prompt?
- lots of async calls, thus really fast.
I used to use fish, and emacs. But when I switched to vim, I had to switch away from fish as well because of its lack of vi bindings. It is a little disappointing to go back to using bash, but as long as bash-completion is working, it's not really a big issue. Of course, I do miss the syntax highlighting. (I would use zsh, but it provides little benefit over bash out of the box and is slower (oh-my-zsh is unbearably…
It's not anyone's cup of tea, but I'm using percol to get similar functionality:
(taken from oh-my-fish)
* pip install percol
* make a function like this:
function percol_select_history
history|percol|read foo
if [ $foo ]
commandline $foo
else
commandline ''
end
end
function fish_user_key_bindings
bind \cr percol_select_history
end
I do quite a bit of programming in bash. One construct in bash is absolutely super: process substitution. You can read the output of a program as if it were a file with the construct: Bash is a fine tool, but it has a number of flaws that prevent me from using it for certain tasks. * Functions can only return a status number. Functions are always subshells. * The hashtable (associative array) syntax is unpalatable, u…
I wonder if you could make a function as a work-around, something like:
r() {
#r(first some args $ff
first=`sed -re 's/\((.*) $ff
second=`sed -re 's/\(.* $ff &
${first} I'm not convinced trying to parse shell command lines for macro functionality is a good idea in general...
Earlier quoted context omitted.
Yikes! I'll open an issue and make sure this is addressed for the 2.2 release. Can you please post your config.fish in a gist?
https://github.com/c02y/dotfiles/blob/master/fish/.config/fi...
[0] https://github.com/fish-shell/fish-shell/issues/1549 [1] http://mumak.net/undistract-me/
edit: Just installed the beta and implemented it (status WorksForMe) https://github.com/qznc/dot/commit/8cf55564383ed93af148234d2...
Fish is definitely good, but not great enough to justify a switch from Bash. I maintain tens of thousands of lines of Bash scripts and was considering switching to Fish once, but decided it wasn't worth it. When you compare the *nix shells to PowerShell, they feel prehistoric. We all use grep, sed, awk, and the likes, but don't you get tired of having to deal with unstructured data and gross limitations of the shell…
I've tried to use and get comfortable with Powershell but it's insistence on types and overly heavy syntax just get in the way for my primary use case for shell scripting. (e.g. quick and dirty hacks) I don't in fact get tired of unstructured data and the limitations of the shell like basic data structures because nine times out of 10 the data I have to work with in a shell is exactly that. Unstructured and basic. No…
The sed command is not a shell. You can use sed in PowerShell.
Fish is great. I've been using it for close to 3 months now, was using zsh with prezto before. I find Fish to be simpler to use and more powerful by default. You can probably have a zsh or maybe even bash setup which does the same fish does, but I don't want to do that.
Would you mind expanding on what fish does out-of-the-box that prezto neglects or hides behind configuration? I am in a similar boat as you and was just wondering what I had to look forward to as a prezto user.
Another thing is writing scripts and completions functions with fish, it's a way better experience than zsh. Writing completion stuff using zsh is really painful.
The preview with the autocompletion is really cool, but maybe you can have that with zsh too.
And then there's the speed, it's totally not objective but IIRC my prezto setup was quite a bit slower.
In the end I just really appreciate that I don't have to spend time customizing my shell: now I install fish on my VMs or servers, and everything is like I want it without me doing anything.
If you're happily using prezto you may not have much to gain from using fish, and you may not even like it since there's stuff from prezto you won't find out of the box.
Hey, I'm the lead dev of the fish shell. There's some great discussion in this thread! For those who are interested, the fish shell is about to release version 2.2, a very significant release that wraps up eighteen months of development. You can try the beta now: http://fishshell.com/beta/ A sampling of new features: - vi mode (yay!) - Abbreviations, fish's take on aliases. They expand as you type them. - A new "inli…
Earlier quoted context omitted.
> ^R is more powerful, though; it matches at any point in previous commands, not just at the beginning. That's how it works in Fish as well. user@system ~> echo wow wow user@system ~> echo something something user@system ~> wow█ ...press the up arrow and the current line becomes... user@system ~> echo wow█
In bash, you hit Ctrl-R on the empty prompt and type "w": (reverse-i-search)`w': echo wow Hit return to execute, or any motion keys to start editing. It was the first thing I missed in Fish.
In fish you just type 'w' hit the up arrow and then hit enter to execute or any motion keys to edit. The same number of keypresses as well.
Am I misunderstanding?
I do quite a bit of programming in bash. One construct in bash is absolutely super: process substitution. You can read the output of a program as if it were a file with the construct: Bash is a fine tool, but it has a number of flaws that prevent me from using it for certain tasks. * Functions can only return a status number. Functions are always subshells. * The hashtable (associative array) syntax is unpalatable, u…
[In Bourne shell] A function can just print to stdout, and the caller can capture it. In this way, a function has two outputs: an exit status, and a (normally text) result.
It's unusual to go any further, but if you really wanted to you could make a function return any number of outputs by writing to different file descriptors and having the caller capture them all separately.