The Dune Shell
adam-mcdaniel.github.io
adam-mcdaniel.github.io
Powershell makes some things possible or easier that weren't possible or easy, but only at the expense of making other things either impossible or at least vastly less practical, and all in all it's a bad trade off and a wrong set of priorities for the job it claims to fill, or at least for the job bash currently fills. It's not that bash is a gold standard, just that it's not fundamentally wrong.
[0] It's from a version of the Python ethos that code is read way more often than it is written, so when you are polishing PowerShell code to share with others you expand all the aliases so that it is easier to read.
Every single command starting with `Get-` or `Set-` adds so much noise and makes things really hard to visually distinguish too. I don't want overly verbose commands in scripts for the same reason I don't want them in the terminal, it's still a pain to write and even if you have some autocomplete it makes editing harder. I don't think `ls` is any less clear or harder to learn than `Get-ChildItem` really, that name doesn't even actually give me any clue what the command does.
B) PowerShell doesn't care as much about the first part because shells have always had aliases and macros, but it does care about the second half "obvious way to do it". The other reason for starting with verbose names and aliasing them for day to day REPL use is to aid discovery. It's often very easy to discover which command or cmdlet does the thing you need simply because it is right there in the name. Sometimes you can just guess the name because there are only so many "allowed" verbs and you just need the noun you want to "verb". `Get-Help` can be quite powerful, `Get-Verb` can help explain some bits about what the verbosity is meant to mean. You can search for commands with `Get-Command`.
There's experimental new IntelliSense available in the VS Code terminal: https://code.visualstudio.com/docs/terminal/shell-integratio...
It sounds to me that you're unfairly putting your existing knowledge about Linux shells into your criticism of PowerShell. If you want to be fair that criticism should come from the POV of someone who does not now both and now wants to memorise it. And whether or not commands are short or long does not matter. People memorise lyrics, or names of hundreds of people. Length is not a factor, objectively.
And alias do exist.
Make an alias like sctl. Takes 5 seconds.
Or an abbr if you are using fish. They are more like text-expanders than aliases.
Putting that stuff aside, it is/was one of the first command shells/REPLs outside of SQL DBMS ones in a long time to support manipulation of structured information. For a smoother transition, shells like nu that can straddle structured and file-/line-/word-oriented will be more successful than leaping to too radical of upheaval.
I switched to zsh because at the time I thought it had better autocomplete, but honestly I use it as I would bash. And I don't think it was worth it to change a little bit.
To change shell I think the change _should_ be radical.
Like, i can't even construct the abstract model of how it's supposed to work
$env::Path (the semicolon? so Path is not quoted here? But when I assign a value it's quoted?)
Dir -r | %($_.Name.ToLower) ( what is this? statement dreamed by utterly deranged)
They took us for absolute fools
Get-ChildItem -Recurse | ForEach-Object { $PSItem.Name.ToLower() }
This might be a better mix of both worlds:
gci -r | foreach { $PSItem.Name.ToLower() }
Imagine your shell's model not being a command line console but a spreadsheet!
I mean, there's a reason text was selected, it's the lowest common denominator. What you're asking for is universal FFI, which we already have that for the most part: C. The problem ultimately turns into runtime and resource management issues when crossing language boundaries, that is, unless you use OS primatives (pipes, sockets, shared memory, processes, etc.) and use message passing/pipelines exclusively. Then we're back to plaintext.
There's a ton of non-printable characters in ASCII that are useful as delimiters for non-keyboard interactive programs that are largely vestigial. One could at least consider reusing them for delimiters and special control sequences for message passing, but without some sort of standardization it's limited in practical use.
The reason csv exists is because you can actually see and type all parts of it, on anything, any platform, any hardware, any software, any age, even a mechanical typewriter, even a pencil. That is not merely nice, it's essntially priceless, infinitely, incalculably valuable. The utility outweighs the problems as big as they absolutely are. Actually the same is true for json, yaml, xml...
Did you read my post? Like, every word of it? Being able to type a control sequence is not particularly useful for ephemeral data in a message-passing between programs context. It's absolutely important for persistent, editable data. It seems like more of a feature to me to use these special characters for special contexts and not have escaping typeable characters be load-bearing.
Further, my editor seems to print control characters just fine, though entering them would be a bit of a pain and the behavior is likely configurable.
Was that not VMS?
Ones that support data structures out-of-the-box (like any et al) but also work perfectly fine with existing UNIX commands (like Bash).
> ls -t *.js | head -n 10 | foreach { echo $_ ; Get-ChildItem $_ | fl Name, Length } product_original.js
Name : product_original.js Length : 3353
gulpfile.js
Name : gulpfile.js Length : 382
That's a neat idea, and sounds like something that could be built on graalvm.
My Ph.D. advisor Olin Shivers created this. It's more pulling bash into Lisp than Lisp into bash.
It doesn't seem to be maintained anymore, but some of its ideas live on in Racket.
In particular the attention to detail, when they showed a bead of sweat running down its optimally shaped ear, whereupon it was pawed into its mouth.
I loved that little scene so much.
edit: just leave '>>' as append and make '>>>' destructive instead.
They should at least make it an option to prompt the user when interactively redirecting to an already existing file. ZSH has this, except for the prompt (you'll need to run the command again using `>!`)
Dune seems to take a step in that direction which is great.
Using a non POSIX shell is much easier to write (e.g. fish xonsh - and possibly Powershell or rash but I have not used the last two)
sh and derivatives are difficult for me to follow the syntax is impenetrateable - and I was a professional APL programmer.
With my last shell, Atom, I had accomplished some of the coziness that bash was missing, but I also introduced a lot of really fatal flaws in the syntax and the type system.
I would be interested to read more about this -- what the author learned from that experiment.
What are the affordances needed for a "scripting" language (or for interactive use) vis-a-vis more "production use? Is it just about having minimal boilerplate, and a large corpus of ready-to-use functions in the namespace?
That's a lot of it, but I think people don't realize how every keystroke counts with shell.
There's only a handful of languages where the "apply function" operator is space. Shell is one of them. (Haskell & Forth are the other two I know off the top of my head, possibly Factor (concatenative in general tends this way).) Most new shells that are successful copy this. I don't think that's a coincidence. Lisp's abundance of parens is something that people will have trouble with, even Lisp programmers, because this is not the usual whining about a foreign language paradigm and not being used to reading parens... this is literally about the effort required to physically enter them with a keyboard.
I've tried a couple of times to switch to things like IPython as my shell. And what nukes it every time is that while it may be better at the complicated commands I run maybe 1% of the time if you actually look at an unmodified history,
cd("some dir")
cd som TAB ENTER
It doesn't look like it when you're doing it once, but when you're doing it dozens of times a minute it adds up fast.
Granted, if you're saying why can't we have the shell also... well, now you're talking about Emacs.
What would `foo | bar | baz` look like in a lisp?
(-> (foo) (bar) (baz))
x = !ls # capture the output of `ls` into x
x[0] # the first filename
...Also, can I make it use a 24h clock and non-US date formatting?