Just recently, Microsoft open-sourced PowerShell, and released a Linux version. As a long-time Linux user who gave up Windows for anything other than gaming long ago, this only holds vague interest. I’ve never used PowerShell intentionally, the limit of my experience was when flailing around trying to find something not cmd.exe.
I’ve had coworkers say good things about it, enough that I’ve decided to give it a look through now. I’ve really only given it a cursory glance so far, but it does seem to have interesting bits here and there.
Perhaps the thing that I’ve seen cited the most as a selling point is the structured nature of the shell, especially around pipes. And I think it’s a good point. Don’t get me wrong, having the tools to munge any text is still indespensible, even if all the common tools have structured output.
But the important thing is that it has made me think about shells again, and what I would like to see. I think most people (even those comfortable with CLIs) would agree that most (if not all) of the shells available have serious ergonomic issues and/or language issues. It probably all stems back to shells having a dual nature of programming language and UI.
I’ll probably write more of my thoughts on that down later, but for now, I want to sketch down a few points on areas where I think shells (particularly the Bourne family, as that is what I’m most used to) could use improvement or experimentation.
- Control flow: I don’t know what to do here, but control flow in a shell is a mess. Part of that probably stems from the overload of exit codes, but that may not be the only source.
- Error handling: Oh boy, is that one not fun. Between set -e and pipefail, it’s obvious that error handling was never a major concern of shell design.
- Reifying output: I think this could go a long way towards fixing the above
two issues. By this, I mean actually build in some sort of understanding and
preservation of output of functions, builtins, and external commands into a
consistent, easily referred to output. Right now, if you assign something
like
foo=$(cmd), you get only the stdout of the process, stderr is lost (at a minimum, with redirection you’ll lose that it was stderr), and the exit code is a pain in the ass (god forbid you run a command immediately after). - Everything is a file: This may take some explanation, but this is an area I’ve wanted to poke around with more than once. I’d like to see every part of the shell available through tmpfs: variables, environment, function definitions, history, output of every history command as above, everything.
- Arcane syntax: Let’s be honest, who knows all of the special characters in
bash and all of their interactions offhand? I know I don’t. I’d like to see
all of that condensed down into precisely one special character:
$. It can start sequences, eg$( .. )for command substitution,$" .. "for strings, and so on. This way, you don’t have to worry nearly as much about interactions or nesting rules or whatever, and it would be trivial to write a tool to escape (or unescape?) all of the output from commands. - Structure: Related to the “Reified output” above, and similarly to what PowerShell provides, I think there could be a lot of good to be had in giving shell scripters the ability to use real structure, hell this could even work alongside the “Everything is a file” to allow for convenient structured filesystem access of everything. Now, granted, really pushing it through the shell would be a massive undertaking, as no external tools would support it, and writing adapters for everything would be a huge amount of work. But in an ideal world where all of that came ex nihilo, for free, would it be useful? Definitely. I don’t know how many intermediate steps could be made that would be useful, though. I’ve used Python-based shells, and it’s a real mixed bag. In large part because of:
- Consistency: This really ties into everything, but I think the real issue with every shell I’ve ever used is that it never feels consistent. Little things pop up with surprising behavior all over the place, as systems new and old grind against each other in frustrating, emergent patterns. How would one make a shell consistent for the future? Dunno, but it’s probably worth thinking about.
This is a lot more words than I originally intended, but it feels good to get all of these out into writing. I don’t really have anything more than idle thoughts at this point, but it seems likely I’m going to make a more consistent effort in the near future to learn as many shells as I can get a hold of in order to sort my thinking out.
We’ll see what happens.