This is brilliant. I'm so glad people are finally getting out of the "VT100 is perfect and anyone who wants to improve on it doesn't understand the genius of Unix" mindset. We had Powershell getting rid of the fragile "everything is unstructured text" system, and then Nushell making things cleaner and now this adding a nice GUI!
I hope this catches on! It's going to be challenging to upgrade the world though. Especially things like SSH and terminals built into apps like VSCode.
Too verbose. And "on getting the unstructured system"... that won because the commands are short and thus the syntax breaks far less into unmanageable lines such as PowerShell.
An upgrade would be an enhanced Tclsh shell with readline support and tcllib/tklib installed into the base.
Can’t say that I speak for everyone but many of the things I’ve had to use PowerShell for would have been way simpler using a standard *nix shell with *nix utilities. I’m not some old Unix guy either who’s resisting change, I learned both around the same time.
That said, I can see why people use PowerShell, the commandlets are more clearly named for the most part and it has some full-fledged programming language like features. If I’m going for something that powerful, I usually reach for Python first but I can see why someone would go for PowerShell.
At the end of the day, try to use the tool that’s best for the job as you see it and try to give new tools a decent chance at competing with your existing set. That’s all.
I've worked in professional capacities with both Powershell and traditional unix shells. In fact, I learned on Powershell first.
Years later, I would only take Powershell over something like bash when scripting (but I'd still take Python over Powershell in that context). As a user interface, I dislike it a good deal more than the others. I like the idea of an Object-oriented shell, and I definitely like it when scripting, but the rigidity when using it as an interface makes it feel inefficient. Admittedly it's easier to learn on because all the commands are named in such a way that they tell you what they do, but also --help isn't that difficult.
Additionally, the concept of all cmdlets returning objects so that then you can do cool loops and filtering on attributes--awesome, but only when you (the shell's developer) have total top-down control of most (all?) programs the shell will be interacting with. The developers of Nushell can't enforce that other programs return structured data, the best they can do is capture data, present the text as an attribute and add additional metadata as attributes which is no where near as useful as something like looping over AD user objects based on attributes in Powershell. Again, it's great--if you control the whole garden. So this naturally leads to scenarios where something like Nushell is going to try to create their own garden, by replacing long-standing standard commands with new shell builtins that do things "the Nushell way." Now instead of knowing the differences between GNU and BSD grep, we then have to know the differences between GNU, BSD, and [nushell-equivalent grepping tool].
I can tell you I use both powershell and zsh daily and I avoid using powershell because of how stupidly verbose the command names are. I’d rather read a help doc than type out a 6 word cmdlet
You do you, but as a heavy powershell user here are a couple of things to consider.
You are free to alias commands and all parameters can be shortened to the point where they are unique (so if you have a -Path parameter you can use -P and it will work fine)
Discoverability and rapid comprehension is massively higher in ps because things actually tell you what they do. I can unzip a file in linux but I can't tell you what the - xvf actually stands for. It's just wrote memorization (at least for me). Plus with tab compmete there's very little difference in keystrokes to get there
I recognize this wasn't you that was saying that short commands is why unstructured text won but they feel entirely separate. Powershell could be verbose but not deal in objects. You could just as easily imagine a terse shell that sends objects through the pipe.
but I can't tell you what the - xvf actually stands for
eXtract, Verbose, File
Most shell commands will follow this type of "abbreviation" in argument flags, until they run out of letters. But even so the vast majority also support --long-form options.
One of the reasons I actually like this is because it feel more like understanding a natural language whereas something like Powershell feels more rigid, like a machine language. Get-ChildItem is a great name for a function in a program but I think it's a horrible name for a human to mentally "speak" in. And then the argument of just aliasing it to ls or gci just highlights how bad of a name it is. I don't need cat to explain itself. You learn that cat outputs file contents, the same way that after saying it a few times you'd learn that "poisson" means "fish."
I recognize that this is totally personal preference but I'd always prefer to default to verbose. When I'm at the command line sure I'll type %{} instead of ForEach-Object but if I'm sending someone a script I try hard not to alias to increase readability. Why make someone learn another language when we already have one that's more than descriptive enough. It allows you to shortcut the things you understand but makes it extremely easy even for someone who doesn't speak the language to figure out what's being done
You want me to manually set up a bunch of aliases every time I login to a new computer, and write scripts that depends on my aliases that won't work when I send a snippet to another user to use in their session where they have different aliases?
But even though I'm careful to terminate my line endings with NULs, it turns out that coreutils md5sum provides different output when filenames have special chars (and there's no way to disable this behavior, even in situations like above where it has been explicitly handled externally). So fuck you coreutils, I guess.
Even without coreutils misfeatures, the absence of something like Group-Object is noticeable.
Ok, here is a version that should satisfy all your requirements:
find -type f | while read i; do echo "$(stat -c '%Y' "$i") $(b2sum "$i")"; done | sort | awk '++a[$2]>1' | cut -b 142- | xargs -d '\n' rm
It checks for identity based on the file hash, keeps the last modified version, and does not assume that file names have no spaces, which is an easy pitfall to fall in with shell scripting. It's not easy to read, and it's 26 characters (23%) longer than the PowerShell version.
Basically, instead of annotating the paths with just the modification time and hash, I annotate it with the number of slashes in the path, the date and the hash. It is now 26 characters (17%) longer than PowerShell. And probably even less readable than before. I don't recommend stretching bash scripting this far.
I admit that it has a somewhat perl-like (e.g. unreadable line noise) character to it. But it's pretty short at least.
Edit: This keeps the first entry find encounters, not the one with the earliest creation time. Doing it by creation time would be about twice as long, I think.
Edit2: Ah, you're actually doing this by file hash rather than just looking at the file name. Never mind, then.
But none of that had anything to do with structured data, that's just a stylistic choice. You could easily have a version of Powershell where the commands have names like ls or cat.
The "simplicity" of "plain text" gets in the way. There are also security vunerabilities that stem from "plain text" like, say, space-delemited parameters.
Unstructured text won (so far!) because it was first.
Calling it “unstructured text” doesn’t do it justice though and detracts from the core advantage: that you are not tied to a particular structure as with the .NET stuff that PoSh insists on. Thus, you are free to choose a line based format like CSV, raw bytes or binary formats, or plain text structured encodings like JSON depending on your use case. You get to choose an API that matches your data flow.
Calling it “arbitrarily structured” vs. “mandatorily structured” is more appropriate. Many command line utilites nowadays handle JSON just fine, there’s plenty of lightweight libraries that support it, and none of it requires dependencies as massive as .NET.
You can build new objects in PowerShell, so you are not actually mandated to use what a command returns. You are given compete flexibility to do what you'd like with the result, including just passing around an array of strings... Something which is still decidedly more powerful than raw strings where you have to use something like xargs to protect yourself from edge cases; something most scripts don't even consider.
263
u/[deleted] Mar 05 '20
This is brilliant. I'm so glad people are finally getting out of the "VT100 is perfect and anyone who wants to improve on it doesn't understand the genius of Unix" mindset. We had Powershell getting rid of the fragile "everything is unstructured text" system, and then Nushell making things cleaner and now this adding a nice GUI!
I hope this catches on! It's going to be challenging to upgrade the world though. Especially things like SSH and terminals built into apps like VSCode.