I've thought about this a lot, but assuming you want to be pleasant for interactive use, you're subject to a tremendous number of constraints. Just to start with:

    rm foo bar
    rm -rf *

You need bare strings, you need variable interpolation, you need redirects.

I think there's some room to break a few idioms and make something nicer, but it really is a hard problem. The choice to break things has to be based on how common an idiom is, how painful it is to not use it, and how much benefit you can get.

I think you've hit the nail on the head there. I've been experimenting with writing my own shell and the original syntax was a lot more like Javascript but having to encapsulate parameters in parentheses, comma delimited and quotation was a massive pain in the arse. So I dropped the requirement for quotation marks, then made commas optional, then I dropped using periods to pipe (ala methods in OOP) and then eventually ended up rewriting the entire parser to follow a more traditional POSIX syntax. As it turns out, as ugly as Bash et al is, it actually makes a lot of sense for writing one liners in an interactive shell (as you stated yourself)

So where I decided to deviate was areas I felt could be enhanced without breaking the POSIX syntax too significantly:

* shell configuration,

* error handling (something traditional shells are appallingly bad at)

* and support for complex data structures (eg so you can grep through items in a minified JSON array as smartly as you can with a traditional stream of lines.

I always respected the power of POSIX shells even before embarking on my pet project. However I never quite appreciated just how sane it's ugly syntax was until I attempted to replace it with something more readable. I mean sure there are still some specific areas I really don't agree with but that can always be argued as personal preference.

As an aside note, one thing I didn't quite appreciate until writing my shell is just how much shells have in common with functional programming. Yes I know it's a far cry from LISP machines; but if you take away the variable interpolation and environmental variables then you're left with a functional pipeline that take something from STDIN and write it to STDOUT and STDERR and does so in a multi-threaded, concurrent, workflow by default. Weirdly this still makes POSIX shells more efficient for some types of data processing than writing a monolithic routine in a more powerful (or should that be "more descriptive"?) programming language.

So there is some surprising elegance amongst all that ugliness.

So how is your shell coming along? Are you planning to release it as open source, or at all? I remember you mentioning it a few times before on HN.

Pretty well thank you. I now use it everyday as my primary shell, but the documentation isnt where I'd want it yet so I can imagine it would trip new users up in areas I've chosen to break from POSIX / "Bashisms". There are also a few areas of subtle bugs I'm still running into, but that is to be expected with anything on this kind of scale.

It is already open source but I'm the only contributer currently. Which is fine as it's a personal project anyway. So anything beyond that is a bonus.

The readline API I wrote for it is pretty nifty though. I'm thinking of spinning that off into its own repo since I've been a little disappointed with the existing realine APIs for Go so I think other people might genuinely benefit from that even if they're not particularly interested in a semi-Bash compatible alternative $SHELL.

Cool. Good luck with it. Interesting about the readline stuff. Can you share the link to the shell project? I'd like to look at the code, with a view to learning something about the techniques involved, as command-line tools and shells is an interest of mine.

The source can be found at https://github.com/lmorg/murex

Happy to discuss any questions or comments you might have on it.