POSIX shell is a bit quirky language and bash add a few quirks on its own, but you can write reasonably working shell code if you'll approach it like any other programming language: learn it (read guides, read man), choose a style guide (or write own), use static analyzers (shellcheck is a great tool), test code on different inputs, ask to review your code.

For some reason it is commonly believed that writing shell so easy that one don't need anything of this. Don't even need to learn it.

I guess you can use that approach for pretty much anything in the world. You can totally use it for brainfuck.

However, good systems impose elegance without users having to create complex standards around it.

1. Yes, but there are little reasons to use brainfuck in production code, and there are reasons to use POSIX shell: 1. It is available on practically all UNIX-like systems from NetBSD to Ubuntu in their default installation (no additional dependencies) 2. For small scripts it can run faster than Python/Ruby/Perl thanks to small startup time. 3. It is a handy tool when all you need a small script which mostly runs other commands/CLI tools (but you still have to spend at least little time to learn it first).

May be availability of the shell is an unfortunate historical artifact, yet it still the reason why one may want to use it.

2. Idea to impose elegance upon users is attractive, but even if we ignore that it makes system/language design harder, different people can have different option on what is elegant and what is not. Having said that I like Go (which tries to enforce what can be enforced) because options of its author are not too far from mine. But not everybody is happy with Go and it is not hard to find its criticism.

> people can have different option on what is elegant and what is not

Thera are also measurable effects of elegant system like number of bugs, questions, libraries, standards, etc.

To compare say how language syntax/features affect number of bugs, questions, etc you have to make everything else to be equal and it is very hard if possible at all in the real world.

I agree. However, we had to create complex C "standards" for dos and don'ts in order to _try_ to write safe code.

And C is still omnipresent. So there must be some other characteristic of Bash that makes it not fit for this age (or some characteristic of C that makes it irreplaceable, that Bash does not have)

> And C is still omnipresent.

And actively being replaced by rust each day because those "standards" are obviously not enough.

And there is some other characteristic of C - its portable.

Bash has multiple better solutions to this. This is a really really really old hack. New code that uses it is either trying to be backwards compatible to the extreme or is more likely just someone unthinkingly copying what they’ve been taught or seen.

What's a decent replacement shell? Sometimes I think there should be one, with all backwards compatibility for if/looping thrown out, but still adhering to the core concept of mostly being made of a handful of builtins and otherwise executing commands (i.e., without having to type system("") or exec("") etc. to execute commands).

tclsh is very nice for scripts - it's a first-class part of TCL which is a proper grown-up programming language, but it pulls it very much into being a shell, and it's been around for decades so there's a decent chance that any old unix system will have it installed.

Does it have to be a shell? I would be fine with having bash as a shell for basic stuff like piping and a non-interactive scripting language for actual scripts.

I've written one specifically to solve if and looping: https://github.com/lmorg/murex (docs: https://murex.rocks)

Others I've not used are oil shell, which aims to be a better Bash. Elvish, which has a heck of a lot of similarities with my own project (and is arguably more mature too). There are REPL shells in LISP, Python and all sorts too.

So there are options out there if you want a $SHELL and happy to break from POSIX and/or bash compatibility.

Seconding PowerShell. Or some future development that files off the rough edges, but otherwise follows the same sane principle of piping objects instead of unstructured text :).

So. Much. Typing. though.

Command/type aliases and autocompletion make this a non-issue on the console and advanced code editors. Personally, I don't mind the verbosity even when using plain editors, like Notepad2, my text/script editor of choice.

Extra-long command names and deeply namespaced .Net types can be a chore both to read and write, but I find the *nix tools way too cryptic. Never could get used to them, but then again, I've been on DOS/Windows all my life since the 90s.

To be honest, I'd occasionally get frustrated and think about switching to Linux. However, Python and PowerShell are the two things that have kept me on Windows. The fact that they are both open-source and cross-platform is just the cherry on top.

Python with sh.py is often alright in the place of a shell script.

Really ?

    sh.ls("-l", "/tmp", color="never")

PowerShell obvioslly, if you can handle awesome.

Now there will be tones of angry dudes complaining about:

- Optional verbosity

- 1-5s startup time on some machines

- Random MS agenda to conquer and destroy

- Random problem with usage that is solved by RTFM

- Suggesting python, ruby, go, node, perl and whatever non-shell language

Thankfully, ignoring is still a great human feature.

First, I like PowerShell - sufficiently much to have used it as a login shell _on macOS_ for a while.

However, you grossly overestimate the “awesome”. To answer each “angry dude” point in turn:

- The verbosity is fine - in scripts, one should fully expand command names. Interactively, `gci` is fine (or the `ls` alias, though some of the default aliases are travesties).

- The startup time is insane. I start a new terminal window hundreds of times per day, and the startup time is what made me abandon POSH.

- Apache 2 licensed, so I don’t care. I do default to assuming that MSFT are doing something shady though, and I’m right [1].

- RTFMing is perfectly fine (and Get-Help has high quality documentation for built-ins), but one must accept that most users will not. ISE (if it existed outside of Windows) was a nice workaround for needing this.

- Python, Ruby, Go, Node and Perl are all more portable (see my last comment about FreeBSD support).

As an interactive shell, nushell [2] is probably the closest thing to the PowerShell experience which is not tied to .NET Core.

[1]: https://docs.microsoft.com/en-us/powershell/module/microsoft... [2]: https://github.com/nushell/nushell

So your answers just confirm my 'angry dude' bullet list.

As far as I can see, the only really problematic one is startup time, which is surely something that will be resolved in the future. I witnessed this only rarely while I use PowerShell on Windows and Linux - it was on windows and it was on VM with very slow disk, and some modules that each keep functions separated by files.

I welcome nushell development, but you can't really compare it to pwsh - even if they continue developing it, its decade or so from being usable as main shell.

> you grossly overestimate the “awesome”.

Nah, its awesome. I save bunch of time any time I open the PowerShell. And any time when one tries to be quicker in some other language one is not, eventually.

In that case you cannot see sufficiently far: telemetry on by default is a non-starter. If the startup time were going to be fixed “real soon now”, it would have improved since 2006. It has not, especially when basic usability enhancements like “posh-git” are enabled.

> [nushell is a] decade or so from being usable as a main shell

News to me. I replaced Powershell with NuShell.

> it would have improved since 2006

cross platform pwsh is just few years old

> I replaced Powershell with NuShell.

Sure, you can replace it with LOLCAT either, its totally legit.

Regarding startup time, I can't believe there is such drama. If that troubles you so much, you can easily workaround it by always keeping powershell process pool ready in the background (1 or 2 suspended instances until you use them).

> you can easily workaround it by always keeping powershell process pool ready in the background (1 or 2 suspended instances until you use them).

This is a pretty absurd take when the discussion is about alternative shells for writing scripts. Shell scripts are everywhere. A fairly heavily used UNIX box might easily execute hundreds of shell scripts every minute. A startup time of several seconds makes it completely unusable.

Not sure what to tell you to break your bubble. I have literary thousands of pwsh scripts running in critical gov projects in production, most of them as part of CI, CD, build and automatic test but some of them serving millions of users. I had dozen of such projects in previous decade on Windows and several on Linux and never had any significant problem with slow startup really. Sometimes it happened that some machines had slow startup but team usually fixed that one way or another.

Pattern of usage of bash scripts where hundreds of shell script run every minute is IMO not something you should brag about in systems architecture. And pwsh is different - it has modules which are encapsulated and you don't have to start another instance of shell to prevent mingle. Parallelism ofc still benefits from faster startup.

> I had dozen of such projects in previous decade on Windows and several on Linux and never had any problem with slow startup really.

OK. So then startup time is not slow? Well, then it's of course a non issue - but then I also don't see why a process pool would be required.

> Pattern of usage of bash scripts where hundreds of shell script run every minute is IMO not something you should brag about in systems architecture.

Yet, you just did :) Anyway, it was hardly intended as bragging, rather than just stating facts. Lots of stuff are shell scripts. Lots of user facing commands are wrapped in shell scripts. Of the ~3k commands in my $PATH, around 500 are shell scripts. You may not think this is a good state of affairs, but it's still a fact. (And it's quite unclear to me what's so bad about it - an excellent use for scripts is providing environment for other programs.)

> OK. So then startup time is not slow? Well, then it's of course a non issue

Its not as fast as bash or cmd but I don't start hundreeds of instances of shell

> but then I also don't see why a process pool would be required.

If you have habit of starting shell every ten seconds or so and equally fast close them, I guess powershell will not be your friend. Bad habit to have anyway IMO, because there are few tools that support that workflow.

> Yet, you just did :)

I never said I run bunch of instances of pwsh - I usually run couple only and within them, everything happens. Although pwsh starts in 300ms on my machine.

> And it's quite unclear to me what's so bad about it

The bad about it is jungle of bashizms and next to 90% of statements which have nothing to do with actual business logic but are there for text massage and parsing.

You can't really compare bash and pwsh tho - you have entire dotNet ecosystem there compared to bash where you need jungle of tools. You can do almost ANYTHING in pwsh without relying on external tools. That is consistency - on different flavors of linux, some tools are there, some are not, and some are just different, even the basic ones such as stat. I get nightmares from the fact that grep and sed and awk and perl and rg and whatever each use their own flavor of reg ex... Its just insane :)

pwsh is more comparable to mainstream languages like go or python. What separates it from them is that it is designed for shell. With that power, I can understand a little bit of slower startup time, but I am sure it will be solved eventually.

> Bad habit to have anyway IMO, because there are few tools that support that workflow.

This is absolutely false. Powershell and the Windows console prompt do not support this workflow. Every other shell/terminal emulator combination I can think of supports it fine.

Perhaps you can elaborate on why you consider it to be a "bad" habit?

> cross platform pwsh is just few years old

It's slow on Windows too.