PowerShell and Markdown
ephos.github.io
ephos.github.io
What's wrong with a good idea, even if, especially if, others are already doing it. It's not like stealing IP; it's about making tooling nicer.
I for one actually like this (granted, I use PowerShell regularly).
We use it in tooling for tons of things that would otherwise be done in Python and have no issues. Especially once you get it set up on Server Core and run the jobs in Cron.
I just don't get all the negativity towards it. There's a reason so many vendors are providing great PS modules for their products: VMWare, AWS, etc.
While there may be something “brittle” from time to time, in my experience this just means it was possible to tackle the problem with text when the alternative would have been to have no way to do it at all.
PowerShell feels like it wants everything to be structured perfectly, and “perfect is the enemy of the good” applies. Sometimes, I don’t care if there is a way to perfectly structure a particular input because many use cases just don’t have stringent requirements.
Disagree. If the program decides to change its output formatting even by a small amount (like going from a GNU version of the program to the BSD version, where such things can happen), e.g. changing the column order of two items, whoops, your script is broken. When you deal with object versus textual output the textual representation of a program can change all day long and you're not affected. The only breaking change is a change to the output object format (like renaming or deleting properties).
Writing scripts that rely on text being output in a specific order with a specific format is very brittle in my opinion.
There’s a common rule in Unix-like systems that essentially says “inputs are liberal, outputs are conservative”. It matters to have programs that can adapt, because this makes a lot of things more practical.
(The above is just a guess. I have zero scientific backing.)
What? PowerShell has been around for 11 years already!
Furthermore, a console scripting language was added precisely because many people were bending Microsoft's ear and asking for one. Say what you like about Microsoft, but they've got a long consistent history of responding to customer requests and feedback; granted it took them years to respond to this request, though (!).
All the resources in the world but absolutely glacial progress.
This is an erroneous description (which in fairness originated with Aditya Patwardhan of Microsoft not with the author of the headlined article here, who is just parrotting it). As Thomas Dickey points out, VT100s had no notion of multiple colours at all. This is not VT100.
* https://github.com/PowerShell/PowerShell/pull/6926
* https://invisible-island.net/xterm/xterm.faq.html#what_vt220
> It just feels… odd.
M. Pleau rightly points out the odd division of labour in the commands, here. Oddly, the conversion command not only generates an abstract syntax tree object, it also (but optionally) renders that AST into HTML or text with ECMA-48+T.416 control sequences. The "show" command then picks one of those two renderings from its input.
A more conventional division of labour would have been one tool to create the AST, another tool (or indeed tools) to render the AST into HTML and ECMA-48+T.416 text, and the usual already existing PowerShell tools to paginate/display HTML and ECMA-48+T.416 text.
(I add T.416, by the way, because the examples include T.416 SGR control sequences for indexed colour. Interestingly, they use it for a reverse video effect, for which there already was an ECMA-48 control sequence: SGR 7/SGR 27.)
bash (by Feross):
find . -type d -name "eslint-scope" -print0 | xargs -n 1 -0 -I % sh -c "(cat %/package.json | npx json version) && echo '(at %)'"
$results = @{}
ls -recurse -filter "eslint-scope" | foreach {
$file = "${_}\package.json"
$version = cat $file | convertfrom-json | select -ExpandProperty version $results.Add($file,$version)
}
echo $results | format-list
First of all, there's no _ in sight in regular identifiers (99,99%). They're always CamelCase and Kebab-Case when including the verbs.
Secondly, it's case insensitive so you don't even need to go CamelCase. Just lowercase-itallthewaytothebank :D
Thirdly, it depends on what you want to do. You can use $_ and % and various Perlish shorthands for faster CLI usage, but it's your call. You don't have to mix, you can go full C# and just use the names or go full Perl and use the shorthands, it's up to you.
And fourthly, that bureaucracy makes things very discoverable. Now you're used to bash, but bash & ecosystem suck hard the first few months, until you accumulate the baggage, sorry, the knowledge to use them proficiently :)
The scripters, probably the more experienced folks would use abbreviations, shorthand and all-lowercase. The programmers like myself would predominantly use powershell on less-frequent occasions to glue our apps together and PascalCase and verbosity has already been burnt into our brains.
Powershell, like perl, took that philosophy that welcomed both parties to write code as they pleased.
But then powershells 2 and 3 and 4 came out, and all that stuff I learned in v1 became deprecated. And I wanted a powershell script that would just reliably run on any, say, windows machine 2003 or beyond. But when I google for something like 'how do I invoke an osql.exe query command? how to escape the quotes?', or, 'how to load a dll and having an adjacent config file and run a method?' I get so many different answers ranging from woefully misguided to version-specific to syntax so wildly different to the untrained eye they look completely different yet being effectively equivalent. I inevitably spend hours crawling google and cobbling together the bits that work cross-platform, document heavily and sit in amazement at how much work it took to do something one would think was simple.
It's a shame but my experiences with powershell as an occasional user have shifted from enthusiasm to seeing it as an arcance even punishing experience when I'm used to bash or python.
I hope this doesnt sound mean in any way, its just that when youre talking with a computer, words like grep/sed/awk and regular expressions bear a learning curve but once you get past that barrier it is much easier to communicate succinctly with the computer with what you really want to do.
I'm not sure I understand the thing about deprecation. I don't think Powershell has very many backwards incompatibility issues. What bit you the most?
Also, I think after the recent switch to Powershell Core, they're not going to go for breaking changes. They can't, if they want to have any kind of cross platform adoption vs bash & co.
And I've yet to figure out which version of windows server/powershell (or extra package) come with "grep" and "tail" aliases for Select-String and Get-Content...
I don't do much actual Powershell scripting, but I can tell pretty easily what this should be doing without going to man files.
That would allow your powershell script's object to be shown as pretty markdown tables.
Your post is a little like complaining over a functional programming language adding OO-features or vice versa and saying they are late to the party.
* http://jdebp.info./FGA/tui-console-and-terminal-paradigms.ht...
It's what you'd expect from 30 years of hindsight.
And I don't agree with you, either. While I like the idea of PowerShell (one of my GSoC submissions like a decade ago was to implement consistent coretools interfaces in C# so that another GSoCer's Mono-based shell could consume them) I personally find trying to actually write PowerShell--either in a script or on the command line--to be pretty disappointing. bash/zsh's syntax on the command line isn't great, but it's short and it's something with few enough permutations that writing it by hand is achievable; the hit-or-miss set, or lack thereof, of shorthand for commandlets and flags in PowerShell makes writing it difficult. Remembering the very long names, the strange syntax of stuff like a one-liner loop--it's pretty gnarly. Discoverable? Relatively speaking, yes. But it's not writable, to me. The experience is frontloaded for novices at the expense For a novice going `rm -rf` is surely complex; for an experienced programmer, writing `rm -Recurse -Force` is just gonna always be bad. (Ditto the odd co-opting of `rm` anyway; `grep` sure doesn't act like `grep` in PowerShell, the short aliases exist just to confuse.)
In a script, and as a programming language rather than a shell language...much like any other shell language, I write it literally only when forced to and if it weren't for Microsoft privileging operations inside of it I can't see a situation where I'd write it over Ruby. Its variable scoping is odd and requires more cognitive power than variable scoping should (we fixed that in JavaScript!) and the oddly bash-ish comparison operators have no real place, for me, in writing code. (They're not good in bash, either, but PowerShell doesn't get that excuse--it's supposed to be better and isn't.)
On top of that, there's a pretty good argument, and one I tend to agree with, that consistency is better than marginal improvements (and PowerShell is a marginal improvement over the combination of bash and Ruby or bash and Python). There is an alternate future where WSL has the ability to do everything, without blinking, that PowerShell can without having to get neck-deep in the .NET commandlet universe, and it's a universe where my tooling is drastically and radically simplified because I don't have to have completely separate execution paths just for that one client who actually cares about Windows.
I don't find any of that "delusional", and I think you should fix your tone and apologize to the person you said that to.
2) You realize you can tab complete commandlets, flags, switches, and named parameters in PowerShell right?
I actually agree that aliasing the old core-utils names to PS commandlets that are only kinda similar was a bad move though.
And unless OP literally meant that PowerShell was inferior when judged as a copy of unix shells and core-utils, they are being delusional[0]. I don't know why you feel that's some incredible insult.
[0]based on or having faulty judgment; mistaken
This isn't a walled garden any more than zsh is! It's an alternative shell. If you wanted bash on windows, you could have and still can get it from various vendors. Microsoft simply distributes a linux compatibility layer as a whole.
Still seems odd, as markdown by definition isn't really meant to be displayed in a terminal.
Markup: "the process or result of correcting text in preparation for printing."
This further confirms my suspicions about Microsoft's motives. If they wanted to make a `man` system, they would have made one, instead of working on markdown in the terminal which sounds quite trendy amongst Linux users.
So, where’s the equivalent offline bash script zero dependency sed awk contraption that is the reason we don’t get “nice things” in our trusty workhorse shell.
Or is the answer to “quick” offline markdown to html conversion on Mac/Linux “install pandoc”?
* https://softwarerecs.stackexchange.com/a/172
* https://stackoverflow.com/a/18517404/340790
Even though you and they missed that there is an off-line tool that is the basis for dingus.