2. .NET integration

3. Maintained by a large company. Extensively used in commercial.

I didn't care enough to dig deep into the why, but have happily been stuck on prezto for the last few years.

It's super fast supports everything I need now and couldn't work without it.

Beside this cmder is really great, but recently I switched to MS's own Terminal, which is maybe even better in my opinion. Especially the integrations with wsl2.

I haven't played with ms' really but interesting the wsl2 integration.. will check it out.

1. It didn’t execute native commands directly, at least then, so I was cobbling together pwsh functions to imitate ls, etc.

2. The pipeline is awesome, but incompatible with the default UNIX/style, where commands produce and expect text.

Having said all of that, it worked and worked well, at least for my purposes (immersion and education).

The pwsh pipeline is far more powerful, esp. since it passes objects and can maintain those: command B can perform work on the results of command A and C can access the results of both A and B with relative ease. The same trick is possible in bash, e.g., but requires some funky redirect and pipe management.

One the pwsh work was done, I switched back to bash.

Configured with PSReadline Emacs mode it really feels pretty much like bash for the most part, except better. https://github.com/lukeschlather/dotfiles/blob/master/src/Wi...

(Concrete better: copy-paste, selecting with the mouse, scrolling all just work. Copy-paste pastes multiline by default so you don't end up executing commands without a chance to review.)

I've been wanting to try out elvish which seems like it might be a cleaner and more "unixy" pwsh. https://elv.sh/

Outside of command line editing features, some kind of completion, novelties, and prettiness, I think most of the time it always comes back to "I chose this shell due to syntax, or programming of some kind". e.g. tcsh due to the C-ness of it.

I am writing this from Linux, been using csh on Solaris and then bash on linux since, well since back then... I have seen a lot of shells come out, but every time I switch to one I think about my personal needs in the shell and portability (I do manage a large number of boxes, and most of them do not have extra items installed, including shells) so I end up back at bash/dash/sh.

Again, I would ask myself what you need in the shell. If ZSH or Fish or csh or ksh or some esoteric shell fit the bill, why not just try it as a daily driver? I mean, what is the worst possible outcome? (unless you make a living making life support shell driven software...)

I'm especially interested in daily interactive use.

I tried fish but it's a bit tricky in some contexts.

Powershell is a bit too alien in *NIX-land, even though I really like it's concepts.

nushell looks quite promising but it's still pre-1.0.

On Windows I've settled with Windows Terminal and clink.

I've tried Powershell too but never got used to it. The concept where everything is an object sounds great. But in practice, to me it only is when scripting. When doing interactive work on the command line (which is what I do all day), as a human, nothing beats plain text for me. Enlighten me if this I missed the point of Powershell.

Plain-text has gotten annoying to me now (having to shell out to grep, cut, and awk is very meh).

What's your pain point when trying to use powershell?

A handy "punctuations" cheatsheet I found on reddit: https://www.red-gate.com/simple-talk/wp-content/uploads/2015...

Short aliases for all major commands: https://devblogs.microsoft.com/scripting/table-of-basic-powe...

Some commands have more than one alias, and you can set your own, of course.

PowerShell also has a very nice help system. For any commands that Microsoft provides, you can type : Get-Help Get-ChildItem

It will list all the various parameters, as well as the various aliases.

As far as return values, you can do $? or type out $LastExitCode - it works the same way you expect.

For a fuller help view you can type "help Get-ChildItem" (all commands and parameters are NOT case-sensitive - it does not care if you type LS or ls, get-childitem vs GET-CHILDITEM does not matter). I prefer this - it helps in remembering.

I guess other alternative shells like nu have about the same level of usability. If you like them, you can use them.

Personally, the main thing I like about it is that I can't copy paste bash commands. It forces me to read and understand and then convert. It also has some quality of life stuff I really like. I think next time I'm just going to go back to ZSH though as I feel I have learnt enough from the experience of using it that I'm no longer getting new things out of it, and I don't script in fish enough for the nicer syntax to be beneficial enough for me. Honestly, I prefer ZSH variables over fish variables too

I don't care too much about bash compatibility. I don't even care shell scripting in my shell - when I need to write a script I write a sh script (or python for more complex ones). I just want a shell that's easy to use and user friendly.

For some reason none of the other alternative shells "click" for me - I love the idea of having objects in my shell (like in nushell, or powershell), but all the implementations I've tried are just clumsy to use and get in the way. Whereas fish is awesome and works out of the box - barely need for any configuration/

  "\e[A": history-search-backward
  "\e[B": history-search-forward
  "\e[C": forward-char
  "\e[D": backward-char

The point of fish is a sane set of defaults that doesn't require customization and is good enough.

Comparable functionality in zsh would be 500loc of ultra obscure tweaks :)

It avoids pauses when doing `git status` on gigantic repos.

Thank you, and yes, that's when you don't use fish.

The point of fish is being for people who are fine with the defaults set by the authors. It's the core selling point.

I just checked and the only things I have configured are `set fish_greeting` (i.e. empty) and some paths...

Edit: Also, I don't know how, but the fish completion is magic. It seems to remember which commands I use often in which folders and in which order. I'm not sure if that's how it's implemented. Sure feels that way though.

Check ~/.local/share/fish/fish_history!

Nonetheless, what moved me from bash to fish was having this as granted. Now I worry only about specific higher-level functions. Also hunting each of these optimizations distracts me from my task at hand.

There's other stuff as well, for instance I'm abusing `for` iterations a lot more to run the same command for lists of things. Using bash before was less ergonomic and painful.

    bash -c "" # to run some bash inline

    bash -l # to jump to a bash shell

The defaults and features are great.

Scripts I also write in bash, sh, or python for compatibility. It's not much of an issue.

I do remember something that used to break in my setup, but since I'm always in tmux, instead of changing the default shell (chsh -s), I just set the default for tmux to be fish.

    # set shell
    set -g default-shell /usr/local/bin/fish

Is something is more complicated than a one-liner, use a real programming language instead, with proper building blocks, tooling and documentation. Use something like Go to crosscompile if you don't want to depend on something on the host machine.

In my experience, even very trivial short shell scripts over time tend to grow into a pain, that could totally be avoided when using a real language instead.

We never did agree on whether that was right or not. It was something involving digging information out of elf binaries where the python libs were much more verbose than the flags passed to readelf (maybe objdump, it was a while ago).

Starship [0] and fzf [1] will make your life much easier in any shell.

I use fish but they work with bash, zsh and the like.

[0] https://starship.rs/

[1] https://github.com/junegunn/fzf

Fzf is a great productivity boost, especially because it integrates with everything so well. Starship is... nice and flashy, but I don't think it actually improves my productivity a lot. The biggest feature for me is giving me the current git branch, and I used to do it with my fish theme. I mean it's nice to know what version of Python I have currently, it's just not a killer feature.

Starship gives me quite a bit of situational awareness:

- git status, with branch, uncommited stuff, all that

- my python venv I'm in, not just the system python version

- my aws profile active

- etc

Forgot to add zoxide [0] and ripgrep [1].

[0] https://github.com/ajeetdsouza/zoxide

[1] https://github.com/BurntSushi/ripgrep

https://github.com/PatrickF1/fzf.fish

Being able to instantly fuzzy find files, directories, git history, processes, environment variables and command history is like having a superpower.

> Unlike the others, this plugin tries to pack as much as possible into a single "do what I mean" shortcut. Edit a file? cd to a directory? Just insert it into the command line? Many things like this can be determined from context.

A few here said they don't use Fish or another shell due to compatibility issues, but I wonder what the problem is: If I want to use a script written for another (POSIX) shell, it most likely has a shebang (or I can add it), so it will get properly executed using that other shell…

What’s helped a lot more has been replacing shell scripts with Python once they hit a certain complexity level. Huge reduction in code size, better functionality (e.g. it’s trivial to have good CLI argument parsing so people actually add it), and every time a large bash script has been converted some set of error-handling bugs has been fixed.

(I assume you're talking about interactive use, not using them as the shebang line in your scripts. I wouldn't do that. But mainly just because then you need everyone to agree to install it, or to install it on your servers, etc.)

> Fish is probably usable, but outside of fish

I use fish, have for years, and I say the above to include it. Sometimes I'm not certain something works as I think it does (bash's myriad interpolation/variable manipulation techniques say) and so I switch shell to test it.

It does have bugs and weirdness of course, especially the vi mode, but it's not going to .. idk, rm -rf / when I only told it to rm -rf ~/.cache/* or something.

  ls **/data.json | each {|it| mv $it.name $"(dirname $it.name)/data.yml" }

  find -name "data.json" | xargs -i bash -c "mv \"{}\" \"\$(dirname '{}')/data.yml\""

In Nutshell we are actually using "functions" (supported syntax-wise) to do the job, so it will be much more simpler.

---

A more complex example from my recent code:

  ls $"(which npm.ps1 | get 0.path | path dirname)/*.ps1" | each {|it| get name | path basename }
    | each {|script_file| $"alias ($script_file | str replace ".ps1" "") = powershell.exe ($script_file)" }
    | str join "\n" | save --force ~/.config/nushell/env-generated.nu

  find "$(dirname "$(which npm.ps1)")/" -maxdepth 1 -name "*.ps1" | sed -r "s/^.*\/([^\/]+)\.ps1/alias \1 = powershell.exe \1.ps1/g" >> "$NU_CONFIG_FILE"

I think Nushell is more readable and easy to write for me.

Albeit this task needn't involve a shell at all - just `find` and `rename`:

    find . -name data.json -exec rename .json .yml {} +

It seems to be included with the util-linux package

https://packages.fedoraproject.org/pkgs/util-linux/util-linu...

  for f in **/data.json; mv $f $f:r.yaml

  for f in **/data.json; do mv $f ${f%.json}.yaml; done

Your first problem solved in bash:

    shopt -s globstar
    for f in ./**/data.json; do mv "$f" "${f%json}yml"; done

    find . -name data.json -print0 | while read -rd '' f; do mv "$f" "${f%json}yml"; done

    find . -name data.json -execdir mv {} data.yml \;

    (
        cd "$(which npm.ps1)" && \
        for f in *.ps1; do printf "alias %s='powershell.exe %s'\n" "${f%.ps1}" "$f"; done
    ) >file

How do you do that without a shell?

But that is the point, there are too many commands to do the same job in Bash, each with dozens of flags. It is hard to learn them all, or even find the right command (like shopt, read) or flag (like -rd, print0, -execdir) in the first place.

That's why Nutshell will be simpler for small tasks.

Then you go on and provide examples of extremely sub-optimal Y code and compare it to X code you wrote.

It's very uncharitable and very difficult to tell what is actually better. It doesn't matter if X or Y is better at this point because you haven't provided a fair comparison. And while I agree that bash is shit, I need a lot more than "here's some poorly written bash code compared to nushell" to persuade me to switch to something less ubiquitous.

Since bash and presumably nushell are both turing complete, there should be an infinite number of ways of achieving any task, what you want to compare is the shortest but so short that they're difficult to comprehend solutions, and there aren't that many. I can't tell if you picked the most idiomatic nushell solutions to your problems but I can definitely tell you didn't do the same for bash.

If you're happy to use nushell you would probably be happy to enable globstar in your shell. So my first solution would be comparable to your nushell version. And yes, you need to know what globstar is, just like you would need to know what nushell is.

Given that bash and presumably nushell both support running arbitrary commands the find version is actually shell independent and the fact that you don't know how to use find isn't bash's problem.

Let's put it this way, given I don't know nushell, I would also have to learn the iterator, lambda, and variable substitution syntax (each, ||, $v.name). I know how equivalents of those features work in bash (for, $...). I don't find your code any easier to read by default (without having to make guesses as to how nushell works). If I claimed right now that I find nushell syntax to be confusing, weird and unusual, would you think it would be fair for me to say that based on reading only your code?

Overall I agree with both of you but on different points, she'll scripting is an outdated painful process and yes we should provide optimal answers to be fair.

https://xon.sh/

Again, I'm not a shell script person and I never liked sh/bash so I don't have any 1000 line shell scripts that I'll be porting over to nu, and if I need to do something that would take more than a couple lines of code I'll switch to a proper programming language. I definitely wouldn't ship nushell scripts in production or for anything that isn't my local configuration because the commands and the language itself are far from having a stable API.

It is mature enough for me, and I have found that the nuance of having non-posix compatibility in some things doesn't annoy me as much as when I hit a problem that is too small to write python and to complex for bash.

Community is great, and I always find the answer to my problems in either the chat or other code samples.

[0] Elvish webpage: https://elv.sh/

Chris Siebenmann still uses rc, to the best of my knowledge. https://utcc.utoronto.ca/~cks/space/blog/unix/WhyISwitchedTo... He's not a poster to HN, AFAIK, but his blog is frequently featured here. I'm not sure whether he's amenable to sharing his configuration and utility scripts, but if you're at all interested, it's worth asking him, I would suppose.

For a while I kept bash as my login shell and had nu as my default command in tmux. This had the advantage of allowing a bunch of environment setup to run in bash and get inherited, which allowed my overall config to be more vanilla. (Also nushell doesn't have any kind of job control, so something like tmux is a must IMO.)

About two months ago I promoted nushell to my login shell. In hindsight that was probably more trouble than it's worth, but I have no intention of changing back.

I now keep a very minimal bash config (~10 lines total) for when I inevitably need to shell into it for some reason. That doesn't happen very often, though — a quick look at my bash history shows that I'm mostly either running stuff interactively which assumes bash, or using it as a repl while working on scripts.

I wouldn't recommend nushell to anyone without a decent background wrangling posix shells, because that's not going anywhere. I've had to reverse engineer a bunch of shell integrations for things like package and version managers, most of which assume bash/zsh/fish.

I don't resent any of that work, because I'm in my shell all day, and the expressive power of nushell is so far ahead of other shells for the kinds of tasks that I'm doing in that environment. I won't try to convince anyone of this, since the question was about suitability for daily use. If you're into it, you're into it.

I'll just add that nushell in particular rewards daily use, because as a language for writing your own custom commands, it has a way of quickly building momentum once you get going.

Also, how stable is it? Especially when interacting with weirder stuff like tmux, vim, ncurses apps?

Stability (in the sense of not crashing) is decent, it's been a long time since I've crashed Nushell. We do get the occasional crashing bug filed but most of those are in areas like our completion engine rather than interacting with external tools.

OTOH, command design and language are not entirely stable; we are still pre-1.0 and we do make breaking changes fairly often.

(I work on Nushell)

Ooooh! Awesome! Thank you for your great work, I'd have 2 big questions:

1. Do you have any visibility into when things should stabilize enough for a 1.0 release? 1 year? 5 years? Impossible to say?

2. And the be-all-end-all of Linux distro packaging, Debian. Any plans to include it into Debian? Usually when this happens the package propagates to many, many downstream distributions, such as Ubuntu & family.

Not sure about Debian. We generally rely on the community for distro packaging. Right now Homebrew is the easiest way to install Nu on most Linux distros.

    journalctl -xefu systemd-networkd-wait-online.service | lines | filter {|in| $in =~ 'start'}

I can reproduce your issue, I suspect that `filter` is collecting its input when it shouldn't. It's not totally clear why from looking at the code.

If you can file an issue that would be appreciated, if not I'll try to do so later today. We have a tag for streaming issues: https://github.com/nushell/nushell/issues?q=is%3Aissue+is%3A...

https://github.com/nushell/nushell/issues/8016

I couldn't apply labels myself, I don't think.

Prompt configuration is good... you define commands for the left and right prompt, as well as variables for vi mode indicators (the line editor's vi mode is mostly complete, I'm happy with it). You can also set the cursor shape based on vi mode. Also https://starship.rs works well.

There are hooks for running commands on events like changes to environment variables, which is how you implement support for things like version managers (i.e. on change to $PWD, run whatever).

Nushell parses pipelines upfront, so the error messages are often very precise and useful, and arrive before any damage has been done. This is fundamentally different to how you might expect pipelines to work, so its difficult to compare like for like (... it's great, though).

There's a built in fuzzy finder for commands, completions and history, as well as the line editor visually showing matches against partial commands (a trend which I think started with fish). I do miss some of the history search magic that's possible with zsh plugins — specifically using vi movements to incrementally match more of those visual completions from history.

Completions for external programs have gotten good. If you set up carapace as a completion provider, then most things on the happy path work well (based on bash completions). Edge cases can be understandably buggy... I've noticed that completions for aliases are a bit unpredictable, but I haven't looked into it enough to know whether this is nushell or carapace.

Finally, the automatic generation of help and completions for nushell commands (including your own custom commands) is excellent and one of my favourite features. I'd encourage anyone to look up the docs for custom commands.

> Also, how stable is it? Especially when interacting with weirder stuff like tmux, vim, ncurses apps?

I use tmux and vim, and I've had almost no issues. The only thing that comes to mind is the lack of job control, which means you need to remap ctrl-z to stop vim from getting into a weird state where it can't actually background itself.

Another thing (which isn't nushell's fault at all) is if you change your default shell, many programs will expect that to correspond to a posix shell. For example, after changing my login shell I had to run around explicitly setting my shell to bash in a bunch of places, including vim.

Also every now and then I'll find another oddball command that acts up. For example I noticed that `go test ./...` didn't work without quoting the (admittedly strange) `./...` argument. Later it started working without the quotes after a nushell update, but that's the kind of thing to watch out for.

And another kind of stability: nushell has regular breaking changes. I think this is fine, because it's a fast-moving project which I'm only using locally, and this allows it to evolve quickly (I get excited to read the change notes). But this does make it harder for people who are trying to support nushell from their projects... and so I think naturally the responsibility to keep anything working has to lie with the user. If you are comfortable with that (which I am) then I think it's a good deal.

I'm very interested in nushell, but haven't tried it yet. It seems to have some similarities with powershell.

https://www.cca.org/mpsh/

Is there any reason why you think Fish isn't enough, and you're looking at super-niche ones?

Fish is a wonderful, mature project, but for me it wasn't quite ambitious enough. It breaks from POSIX just often enough to cause friction when adapting instructions written for POSIX shells, but not enough to make CLI UX significantly better than a POSIX shell. Also, scripting often seems like an afterthought in Fish.

Personally, Bash is stuck to my fingers out of habit.

I tend to write my scripts in a Functional Programming style, which plays well with stdio and pipes, and makes for composable and testable code.

Like this: https://www.evalapply.org/tags/bash/

edit: add reference

nushell is really, really great as a shell but I find it far too limiting in some cases to use as a scripting language. For example, you can't build a non-external command from a string and run that command. I'll definitely come back to nushell in the future.

elvish is also really great, especially as a scripting language (being able to pass around lambdas is amazing), but ultimately fish has so much community support and so many nice plugins that it's hard to justify using anything else at the moment.

The thing about ZSH that made me jump ship was that even though you can customize it like fish (with Oh My ZSH plugins) ZSH was always slow or didn't display some things correctly. It was frustrating having to wait a few seconds for a command or having things just not work out correctly.

Fish, on the other hand, is fast and has a lot of quality of life features like typing part of a command and then serach with the up key. I didn't even install any plugins (I like to Fisher[1]).

Also, Fish has gotten me more and more into shell scripting. The docs for Fish are very clear and easy to navigate. I love how you can have custom scripts on the .config folder or abbreviations[2], which I think are superior to aliases since they expand into the command you're calling.

I was using it as the default shell for my user until recently and it was fine, but I have gone back to Bash as my default shell and just set my terminal emulator to start into Fish on startup. I didn't have any incident. I just wanted to avoid anything unexpected further down the line.

[1]: https://github.com/jorgebucaran/fisher

[2]: https://fishshell.com/docs/current/interactive.html#abbrevia...

The one thing I don't do is make it my official shell in Linux. I keep bash/zsh as my shell, but the first thing I do in any shell is launch xonsh. Occasionally it does crash and it's nice to end up in a "backup" shell in case I need to recover anything.

[1] - https://teddit.sethforprivacy.com/r/linux/comments/1h13g8/ba...

Now I work at Google where there are tons of shared bash commands and scripts. It's so easy to simply copy/paste something that works into your shell instead of futzing around with compatibility differences.

It'd be neat to work at a place where everyone used fish but I've never experienced that.

I really like it despite its quirks. I love the implicit $in variable. I find the library easy to understand. I'm only using it interactively so if I have to restart my terminal every once in a while I'm not bothered by it. I trust that those sorts of things will get straightened out --- the git repository is very active.

I saw the maintainers in this thread, so shout out for your good work.

In particular, starting in October, contributor Melvin Walls has almost single-handedly enabled the interactive shell to be translated, including some of the hardest bits like shell traps, signal handling, and GNU readline bindings.

I was a little worried that we'd run into difficulties with our style of Python and this "inverted" / callback-heavy component, but the result is better than I expected. Melvin came up with creative and solid solutions.

So we have a tiny garbage-collected runtime, and the rest is statically-typed, memory safe Python code. (We learned first hand that memory safety is especially important when you're interfacing with a garbage collector.)

-----

So we need more people who can put in some elbow grease. You can even be paid to work on open source code! We just got a second grant from NLnet, which I mentioned on the blog.

https://news.ycombinator.com/item?id=34221617

https://www.oilshell.org/blog/

-----

There are a few misconceptions in this thread which make me realize I need to update the blog:

1) The Oil project contains OSH, which is not only POSIX- compatible, but bash-compatible. Some people don't believe that it could be both things -- how could it be both compatible and new? But that is absolutely true (and a major reason why it's a big project!)

You can type 'osh' and it will run your existing shell scripts, or type 'oil', and it's a brand new language. ( Tour: https://www.oilshell.org/release/latest/doc/oil-language-tou... )

(Note: I also plan to slightly rename the project, to address this confusion, since I've encountered it before.)

2) On the other hand, the Oil language is NOT "just waiting to be deployed". There are a few TODOs in that doc, and they're actually quite big. Though filling them in is going to lead to something pretty great which spans a variety of domains, IMO. I hope to write a few blog posts about that in the coming months.

As always feel free to check out the code and join Zulip. On most Linux distros you can get a working bin/osh in about 30 seconds:

https://github.com/oilshell/oil/wiki/Contributing

The code is in great shape, and completely different than it was 6 months ago. Especially the C++ side. But you can just hack on Python, with MyPy, and it just works!

The tools are also very solid now, with dozens of cleanups/fixes even in the last few weeks. Getting the GC working was a big breath of fresh air that unlocked a lot of possibilities.

https://github.com/nushell/nushell/issues/4564#issuecomment-...

And coming back to this after all this time, it seems the nushell issue tracker is not getting groomed at all -- are the authors starting get tired of it? https://github.com/nushell/nushell/issues/4320 lists a huge number of duplicates.