3 ms·
My problem with alternative shells (anything not bash) is that I have to learn bash anyway, and if I want to use a scripting language that requires me to first
by tormeh 4y ago
My problem with alternative shells (anything not bash) is that I have to learn bash anyway, and if I want to use a scripting language that requires me to first install a runtime, drop into it, doesn't work on colleagues machines, etc. then there are many non-shell alternatives that are better. I'll learn nushell or whatever once a mainstream or somehow desirable distro ships with it as their default shell.
- xcdzvyn 4y agoI have the same problem. The only viable neo-shell in my eyes would have to be 100% Bash compatible anyway, so what's the point?
- bmelton 4y agoThis is the same reason I eventually learned and stuck with Vi(m). Implementing a project on a massive array of SPARC Solaris boxes and every "easy' tool I'd learned just... wasn't there. I had kind of learned Vi at that point, but wasn't remotely proficient in it, and had only gotten as far as I had due to a bunch of cool plugins I'd installed that definitely weren't available.
- zamadatix 4y agoThat last part is often forgotten. I usually stick with defaults (or as close as I reasonably can) not because they are functionally better but because for most things I don't have the return on learning and regularly using two instances of ${tool} isn't worth the extra time. Sometimes it's a pain but it seems to pay off.
- deafpolygon 4y agoAnd when I'm doing something on my local machine - very often, a more modern tool is required anyway. (Visual Studio in the case of C#/C++, and VS Code is infinitely quicker and simpler to get up and going with when editing other source code).
- ParetoOptimal 4y agoI used to do this, but then found emacs/tramp and that has worked better ever since.
- zamadatix 4y agoAssuming everything you connect to has a remote file interface and you only use your computer affords many conveniences. Knowing the default tool first is for when those don't hold, not for when you need to do something from your machine.
- scns 4y agoThat is a good point. But Nu offers someting else: > First and foremost, Nu is cross-platform. Commands and techniques should work across platforms and Nu has first-class support for Windows, macOS, and Linux. Source: GitHub. No snark intended.
- IshKebab 4y agoNano is fairly commonly installed mercifully. Micro (which is an actually "normal" terminal editor) is becoming more popular too and is also trivial to install (since it is written in Go).
- kibwen 4y ago> I have to learn bash anyway Do you? You need bash installed, certainly, but you don't need to learn bash in order to merely execute bash scripts. To use an analogy, just because your distro scripts things in Python doesn't mean one needs to learn Python to use the distro. I basically never need to write or read a bash scripts these days (I use fish, but I rarely write a real fish script either; just learn the language of your shell and YOLO).
- MrJohz 4y agoAs a fellow fish user, I agree. Occasionally I write fish scripts/functions, but they're for my environment so I don't expect them to run on other people's fish shells, let alone bash. Then when I am in another shell, I can usually get by on the minimum (glob, pipes, redirection), which is mostly fairly universal. And when I'm not SSHd into some other machine (which is 99% of the time), then I get all the superpowers of fish to use. It's a bit like the equivalent vim argument. Yes, using unmodified vim means you have access to the same tools in every environment. But I spend 99% of my time in one environment, so I'd like to optimise for that one, whether that's by using an IDE or installing a bunch of vim plugins and customising everything. Then when I do need to SSH into a server somewhere, I can get by on the bare minimum - in my case, usually nano. If I'm using nano for long enough that I start missing my IDEA features, then I've been using nano for too long and need to figure out a different way of deploying/debugging changes in the first place.