Though, I’m keeping a very interested eye on Nu shell. They’re doing a lot of stuff right, and I expect it will become a very useful scripting language in its own right even when not used full-time as a shell.
Also... the script will then run only on my machine as most Linux systems don't have powershell and most Windows don't have the Unix commands I still use all the time.
> Also... the script will then run only on my machine as most Linux systems don't have powershell and most Windows don't have the Unix commands I still use all the time.
Hahahaha! Oof.
It's more work, but when I use PowerShell, I try to use pure PowerShell, both for aesthetic reasons (cleanliness, ‘portability’) and just in order to practice and learn more PowerShell APIs along the way.
Now-If-They-Could-Improve the Syntax To-Make-It-Usable.
In recent years the existence of frameworks like oh-my-zsh has contributed further to this situation because it has separated the detailed configuration from the base zsh project. It's a pity omz doesn't enable more really. Many things it does are not really useful unless you take the time to actually learn them. A lot of plugins just define aliases but if you don't know what they are, they just sit there unused.
That's weird. Fish has all of the GNU readline shortcuts OOTB and has for as long as I can remember
I guess it does the PATH hacking based on whether the system is GNU or not so that it can get `realpath`/`readlink -f`-like behavior even on systems that don't natively have that because they include *BSD coreutils.
That might not behave as expected (and is unnecessary) on my macOS systems, either, since I like to keep GNU coreutils (with no `g` prefixes on the executable names) on my PATH there (heresy, I know).
It's also noticeably slower, to the point that there's a bit of jitter as I type.
It's pretty cool, though. If it's any better after I patch the readlink PATH hacking out, maybe I'll configure it for bash on my systems.
That said: what do you like about Nu shell specifically?
A whole bunch of things:
1. abandonment of POSIX shell syntax. We can do better. I'm happy with Zsh being POSIX-compatible, and that will always be there.
2. a focus on structured data. Nu basically has hierarchical dataframes built-in, along with lots of facilities for their manipulation. There have been a few other attempts at this but the benefits are obvious. Rather than figuring out how to `awk` your way through whatever text output a command generates, command output in Nu is structured and everything can be handled in orthogonal ways.
3. modern conveniences built-in, like syntax highlighting, and AFAIK they want to include features like "do something when you cd into a directory" that we currently need more tools for (i.e. direnv, which I highly recommend!)
4. serious technology. The people behind it are experts and JT has been showing off (https://youtu.be/3o8b_QcrFHc) the engine that enables trivially parallelizable loops. No more need for `xargs`.
5. I hesitate to mention "made in Rust" as a feature, but using a modern language for core infrastructure does matter.
The thing is, there's currently NOTHING GOOD for "shell scripting". Shell sucks (yes it does), so for anything more than very short things I'd rather write Python. But Python sucks for shell-like things, parallelization, it has slow startup, and you also can't do things like put environment variables into your session or change the working directory, so you often wind up writing shims (eg. Broot's br alias - https://dystroy.org/broot/install-br/).
Yes I've looked at Xonsh but maybe the additional syntax is offputting to me. Like, I wouldn't use it as a shell over Zsh (how's Xonsh's fzf support? I don't know, but I know everything's going to support Zsh), and I dunno if I want to use its syntax extensions over just Python. Though It's always on my list of things to re-explore, and maybe it'll click one day. But it being based in Python makes it feel slow (I wrote my prompt in Zig to get it to be fast...)
This is relevant to mention: I wrote a small Python library (https://github.com/kbd/aush) that's basically a DSL for subprocesses, so it tries to make it more convenient to do shell-like things. I find it preferable to shell or Python alone most of the time. Here's an example of its use in my script that creates a new Python project: https://github.com/kbd/setup/blob/master/HOME/bin/create-pyt...
I haven't figured out a convenient way to implement shell piping well with Python's pipe operator, or pass through interactive output directly (so things that "update" the display, like poetry and npm don't behave the same as they do interactively) so it's still .9 status, but it works really well for what it is, and you can always write "regular Python" along with it.
Anyway, Nu seems to be an attempt to put a "real" programming language REPL in my shell, from people who have serious language experience, so I'm hopeful it'll be great.
I appreciate the clarity of your message... curiously enough all the things that you mention I see them as anti-features of nushell (except the first one)
1. Posix shell is clunky has its limitations but there's nothing really flawed about it. It is nice to have non-posix shells, though; in that I agree with you.
2. I hate hate hate the very concept of dataframes. They seem like a useless over-engineering. Plain tabular data is a perfect, and the columns of a table are always named 1, 2, 3. The whole point of abstraction is that you do not care about the meaning of the columns of your table, and the programs (like the lovely awk) that deal with these columns do not care either. There's nothing more "orthogonal" than that: filters that do not understand the data but can filter it anyway.
3. syntax highlighting is a very personal issue; in my case I prefer my terminal not to look like a christmas tree.
4. xargs is one of my favorite tools (alongside gnu make and gnu parallel) and there's nothing "unserious" about it. The happiest moments in my programming life are when I get to use these tools. Not using xargs sounds like a nightmare!
5. Rust is definitely an anti-feature to me: it's like a language that was built by picking the worst features of many already ugly languages. I would not really care in what language the shell is written, but I'd rather have it written in saner, "unsafe" languages.
I think shellcheck is the best argument against this. POSIX shell is just stuffed to the brim with weird gotchas, places where the obvious way to write something causes subtle bugs down the line.
It's the only programming language I use that feels adversarial, where you have to be paranoid to properly solve simple tasks. (Admittedly some of that is because of the reliance on system programs rather than the shell language itself.)
This may be just that you are not very used to the language. I have the same dreadful feeling (that the language fights against me), even when using languages that I'm reasonably proficient with.
For example, in C++, a simple expression like "y = f(x);" already gives me the chills... Is the () operator overloaded? and the assignement operator? If the object x has size equal to 10GB, and y is supposed to have the same size, how much memory does this operation require? 10GB? 20GB? 30GB? 40GB? each of these completely different answers is perfectly reasonable, depending on extremely delicate details of the implementation.
Garbage-collected languages are even worse, I never know whether they will start a memory reclaiming spree that will halt my program for a few seconds.
Even in python, I have this sort of jump scares a few times per month.
Edit: also things like `kill`. `kill [tab]` gives you a fuzzy-find list of all your processes so it's way faster to use than ps | grep.
The point of fish is that there is no configuration required.
You don't have to learn to configure it, you don't have to be part of "the community" to learn which plugins to use, you'll be able to sit in front of any fish prompt and have it work as expected without having to move dotfiles around.
I use Fish, however I also use Vim and do the plugin hunt there. I enjoy it, but I’m glad to not be doing it for both my environments.
I think it would be more accurate to say that the point of fish is that there is no configuration allowed. If you don't like the out of the box configuration, I would say configuration is still required, but it's unfortunately not available. If you happen to like every single decision the developers made, then I admit having no configuration does mean you end up with a simpler, faster, more maintainable shell.
Then either decide to like it -- humans are adaptable, this is possible -- or don't use the thing. Both outcomes are acceptable. A hammer doesn't need to have a configurable grip and head and claw in order to be a good tool.
A: Linux is amazing, I can configure everything the exact way I want.
B: Linux sucks, I need to mess around with configurations for hours before I get something usable.
A lot of us just want something that works out of the box with amazing defaults. Others want something that can be tuned to their exact preferences. However, configurability comes with it's own costs too.
You can configure scripting to run at various times, and there are even plugin frameworks for Fish. It just doesn't have toggles for things like language features in the way that ZSH does.