111–120 of 120 posts
I find it so much easier to quickly throw together a function or a script for whatever random task I want to do in fish than in bash and actually have confidence that it'll work without tons of trial and error and needing to look up syntax.
Anyone using fish in Vim mode? Does it work well? Last time I tried I had not such a good time. Would love to see a tutorial on how to use it efficiently.
Earlier quoted context omitted.
I just start fish from .bashrc: https://github.com/pkulak/dotfiles/blob/master/.bashrc
I did that, but this makes it far more difficult to use bash if you need to.
You can use Fish on any system where Nix runs on, btw. For example, I use it on Synology's DSM.
So the massive drawback of fish is it's incompatible with bash (and other shells people use). If you're in fish, this is easily remedied because almost every machine has bash too. However, you can't expect another machine to have fish. However, I just really like fish. I also live out of my own shell, and I don't spend much of my life remote-ing into other machines. When I do, my mind flips into bash just as easily a…
There is no need to change `$SHELL` :-/ you can use Bass ( https://github.com/edc/bass ) to execute any bash script and it will apply the environment variables to the current fish environment.
Earlier quoted context omitted.
I think this warning is actually harmful: Years ago, I read this argument about fish and it turned me completely off using it. Only more recently have I really realised this never applied to 99% of my (most people's?) use-cases. The logical step many people miss is that shebangs make the compatibility of the user's shell largely irrelevant: the only real compatibility concerns are the bash version or `sh` aliasing on…
> Only more recently have I really realised this never applied to 99% of my (most people's?) use-cases. every time someone asks "how do i accomplish X task on the command line" (witness literally thousands of Stack Overflow posts like this) the answer is in bash. so, i say it applies to essentially every use case where you didn't already know how to do it. I love fish, but the fact that every answer to your questions…
Those answers, imo, come in 3 forms:
1. Short simple bash commands that will work in fish
2. Overly clever "one-liners" that would be better as a script
3. Edge cases.
(3) is rare enough that I don't see it as a big enough hurdle to avoid using fish.
So the massive drawback of fish is it's incompatible with bash (and other shells people use). If you're in fish, this is easily remedied because almost every machine has bash too. However, you can't expect another machine to have fish. However, I just really like fish. I also live out of my own shell, and I don't spend much of my life remote-ing into other machines. When I do, my mind flips into bash just as easily a…
> However, you can't expect another machine to have fish. I can, because whenever I get access to a new machine I download and compile it!
Earlier quoted context omitted.
What about bash shell? Bourne Again SHell shell. That's the same thing. But i think it can be a helpful distinction between using bash shell as an interactive shell and using the bash scripting language.
Yup. I'm one of those folks who thinks that RAS syndrome is an entertaining and occasionally useful language quirk, and not at all a problem. For example, even within a computing context, saying "Fish shell" just might help someone understand that you're talking about the Unix shell and not the cipher, and would always help someone who's not familiar with Fish to at least understand that you're talking about an alter…
Earlier quoted context omitted.
AFAIK, login shell can be thought of as the default shell anytime you start a shell. By default your terminal program uses that, but most terminals let you override that to be something else.
I still fail to see a significant difference. Been using fish as my shell for perhaps 15 years. Perhaps not having to run chsh on a new machine, which I have to run -h on to remember how to use ever few years.
Being new increases the chances of doing something like that that breaks the shell. It's annoying to fix for those of us with experience, and extremely difficult to fix for those without experience. It gets even worse when you consider that some distros like Ubuntu don't set a root password, so you can't log into the root account without sudo, which requires your user to have a functional login shell. I wouldn't want a new user to paint themselves into a corner where the only way to get their desktop working again is to remember how to boot into single user mode or boot from removable media and mount their hard drive. Doubly so if their Linux desktop is their only PC; it's going to be really annoying if the only way to write removable media to boot from is the machine that's currently broken.
Earlier quoted context omitted.
I still fail to see a significant difference. Been using fish as my shell for perhaps 15 years. Perhaps not having to run chsh on a new machine, which I have to run -h on to remember how to use ever few years.
The main advantage is that if you screw it up or an update borks the shell itself, it's easier to fix if it isn't your login shell. At one point I decided to set Elvish as my login shell, and it turned out to not function as a login shell. As in, won't start at all. Any time I logged in, it would just immediately exit, ending my session. Work doesn't allow us to have root access (annoying), so I ended up having to bo…