[chubot]

I agree that not just bash, but POSIX shell is beyond salvaging, at least for many use cases where it should be applied.

The way I think of it is that I can't tell my (former) coworkers or my sister to learn to program shell in 2018 "with a straight face". More than 50% of them had Ph.D.'s in some other field like statistics, math, biology, or physics -- i.e. the kind of person who has no problem with Python. But they would struggle with shell or make.

They're the kind of people Mike Bostock (author of d3) wrote this post about Make for [1]. He's absolutely right that they should use Make, because like shell it's a great tool to combine different programs that weren't designed to be combined.

But I feel like this is basically a losing battle -- I don't see that shell or make is an exciting thing for most people to learn, even though it would make them more productive and increase the quality of their work. I think that a language free of legacy would go a long way.

I guess I can see POSIX sh being used when confined to the lower level of an OS, by specialists. But I think it has a lot more potential than that. I'd say it's more important now than 10 years ago, because there's so much more software out there and systems are increasingly built of large heterogeneous parts.

----

FWIW I mentioned Morbig here [2], along with several other shell parsers, like ShellCheck in Haskell and shfmt in Go.

[1] https://bost.ocks.org/mike/make/

[2] https://github.com/oilshell/oil/wiki/ExternalResources

[Sir_Cmpwn]

I don't see sh as a losing battle. I actually think it's quite good for the niche it aims to serve - a niche that very much exists, sh is a square peg and should only go in square holes. I think most folks have had their impression of POSIX shell tainted by bad shells like bash and - sorry - oil encouraging complex, non-portable shell scripts. I intend to write more blog posts in the future helping people gain a closer understanding of POSIX shell and how/where it's useful and how to use it.

[chubot]

Yeah, I think there is a stark difference in how we're thinking about it. I can't imagine dissuading someone from using local variables "with a straight face". I didn't get your solution below because "local_variable" is actually a global.

I could see that perhaps low level scripts need to be portable to different Unixes. But again I would say that's maybe 5% of what shell is good for.

Also, someone once said "it's easier to port a shell than a shell script". So that's why I'm paying careful attention to Oil build dependencies. For example, Rust and Go are significantly less portable than C, and Oil is self-contained C if you look at it the right way :)

----

EDIT: Also I think there's no problem adding local variables to POSIX, since all shells implement the same way as far as I can tell. That would be the much better solution, rather than trying to convince people to use only globals.

There are many useful / real shell scripts that are thousands of lines long, so you really need locals.

[Sir_Cmpwn]

>I didn't get your solution below because "local_variable" is actually a global.

A global in a subshell, so the caller's globals aren't affected.

>Also, someone once said "it's easier to port a shell than a shell script".

Yeah, but it's pretty damn presumptuous to make someone install some random shell on my machine to build your code, imo. The same goes double for e.g. GNU coreutils extensions, since I have to set up some kind of separate root for you where true --version works (ditto for assuming /bin/sh is bash, or even dash so you can use 'local'). It's like encouraging people to use a fucked up version of libc where the args to strcat are reversed. Fuck that. The standard exists to define the environment. Sometimes it's within reason to have dependencies outside of that - but the shell is a good example of where the case for it is very weak.

For the record, my motivations for working on Simon's mrsh project is basically 50:50 between "I want to support POSIX-compatible shell scripts" and "I want a POSIX shell whose interactive mode isn't dogshit". Both are equally important to me.

>EDIT: Also I think there's no problem adding local variables to POSIX, since all shells implement the same way as far as I can tell. That would be the much better solution, rather than trying to convince people to use only globals.

That's all well and good. The Austin Group has public meetings, a public bug tracker, and a public mailing list. Go there and make a case for it! But be prepared for "all shells" to include more than dash, bash, ksh, and zsh.

>There are many useful / real shell scripts that are thousands of lines long, so you really need locals.

Length of shell script is not directly correleated for need for locals.

[willghatch]

> it's pretty damn presumptuous to make someone install some random shell on my machine to build your code, imo

Is it more presumptuous to make people install a language you used than to make them install a library you used? Either way people need to get your dependencies if they want to run your code.

> The standard exists to define the environment.

Standards are great, but not all environments need to be standard. Most shell scripts don't need to be ported to dozens of different platforms, and most shell script authors would be much better served by a language with fewer weird gotchas, saner semantics, and the benefit of a lot of language research that's happened in the past few decades. For instance, as I've been porting my personal shell scripts to Rash (my shell in Racket), I've been able to use all the patterns I use in posix shells but with benefits of better readability, easier reasoning, better means of abstraction, etc. It's been a solid win that I would recommend to anybody. Sure, if someone else wants to run my scripts they need to install Rash. But few people (in practice: nobody) are really interested in running my personal shell scripts besides myself. If somebody does want to run them, installing the dependencies is not very hard.

There is a small set of scripts that needs to be portable and be written in a shell-like language. Until standards catch up, posix is perhaps the best thing we have. But most of the time when people write shell scripts they could be writing in any language but choose shell because they want to automate something they do manually or they really want a processes-and-files DSL. Choosing a better shell that fits the processes-and-files domain and allows easy interactive use with better features and less insanity in these situations is a slam dunk.

[Sir_Cmpwn]

>Is it more presumptuous to make people install a language you used than to make them install a library you used?

A C compiler is also required by POSIX.

>There is a small set of scripts that needs to be portable and be written in a shell-like language

I reject the assumption that the smaller of the two sets is the set which should be portable.

Your Racket-based shell requires a supported Racket platform, which is honestly a pathetic group: Linux, macOS, and Windows, on x86_64, i686, and ARM(?). Maybe if your software is written in Racket in the first place this makes sense, but otherwise it doesn't. It's not about you: it's about everyone. I have a RISC-V machine on my desk and if I wanted to get your stuff working on it I'd have to start by writing a new JIT for Racket. On the other hand POSIX & C runs just about everywhere. You mentioned using these for your personal scripts - fine, whatever floats your boat. You'll regret it if you ever think about playing with BSD, POWER9, or the platform of tomorrow (spoiler: I guarantee you that platform will support POSIX and C).

It's funny that everyone in this thread who's come out against POSIX shell in one breath is pushing their own shell in the next ;) maybe when those shells start to number their users in the double digits, we can talk.

>easy interactive use

A comfortable interactive shell experience is a good thing, and has nothing to do with POSIX.

[willghatch]

>You'll regret it if you ever think about playing with BSD, POWER9, or the platform of tomorrow

But the platform of tomorrow is clearly a resurrected Lisp Machine! In all seriousness, though, I'm pretty sure Racket runs on BSD, and it would probably not be that hard to get it working on any Unix. (In fact, portability is one of the main thrusts right now in core Racket development.)

>Your Racket-based shell requires a supported Racket platform, which is honestly a pathetic group: Linux, macOS, and Windows, on x86_64, i686, and ARM

>It's not about you: it's about everyone.

The same could be said about pioneering new architectures. I think you're doing great work on eg. getting RISC-V available on your build platform. But by the time I will realistically buy a RISC-V machine to replace the server I run most of my shell scripts on a lot more software will be ported to it, probably including Racket. I'm under no delusions that the masses will be flocking to my shell, but there are so many shells that are better than Posix for (at least what I perceive to be) most shell scripting. If any of these better shells becomes very widely used I'm sure it will be ported to $platform_of_tomorrow (oops! I mean "$platform_of_tomorrow"!) before it is very widely deployed.

>A comfortable interactive shell experience is a good thing, and has nothing to do with POSIX.

At least we agree there!

As an aside, I think your projects (sway, wlroots, sr.ht) are really cool, and I like your blog, despite our disagreement about things like sticking to Posix shell and C. Cheers!