PowerShell and Markdown(ephos.github.io)
ephos.github.io
PowerShell and Markdown
https://ephos.github.io/posts/2018-8-1-PowerShell-Markdown
60 comments
I get sick of all the downplaying that PowerShell gets. I find interacting with the console a breeze, and just as usable as Bash. I can easily perform an ad-hoc API call into an Object, explorer it and export it into a well formatted .csv file for a report in minutes.
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.
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.
I find it horrifically verbose. Granted, there are a decent number of aliases, but some pretty basic stuff requires 3 words separated by hyphens.
Way easier to just use bash on WSL on windows 10 machines.
I feel like that makes it readable. Even people who don't know PS very well can read cmdlets and pretty much know what's going on if you use the full verbose cmdlets.
I think when scripts are over 1k LOC the naming of functions can get pretty unwieldly when trying force everything to fit into the approved verb-noun mantra.
Over 1K LOC I'd want to be using a proper programming language rather than shell scripting, whether it was Windows or Linux.
I think it boils down to a lot of people having a fundamental misunderstanding of what makes PS different than Bash, i.e., not understanding how significant it is to have processes communicate through piped objects versus piped text, which is far more brittle.
I think it is simpler than that, it's web and unix devops who just don't want to learn new tooling and are upset that it isn't exactly like bash/core-utils.
Since it is impossible to force all inputs to be well-constructed, text acts as the more predictable interface. Once I learn a bunch of command-line tools for processing text, I know exactly how to compose commands or post-process text from a file or extend the usefulness of a program that doesn’t happen to produce output I want.
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.
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.
> Since it is impossible to force all inputs to be well-constructed, text acts as the more predictable interface.
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.
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.
Robust scripts require diligence appropriate for the environment. If you’ve deployed systems with different default tool versions, you factor this in, e.g. by installing a common version that both can use (or just make scripts that can figure out how to work either way). Two versions of a tool isn’t really any different than two versions of a compiled-in API, except that APIs tend to be more rigid (not always, e.g. some languages allow runtime querying).
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.
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.
Assuming the system is put together correctly, all inputs certainly ought to be correct, because whatever component is producing the corresponding output simply wouldn't have compiled if they weren't...
Powershell deals with text too, it just converts it into regex match objects.
Maybe same reason people going to a restaurant are more likely to write a review if they are disappointed? For every "this is lame" there are probably 50 "oh, neat" opinions but fewer of those bother to write comments.
(The above is just a guess. I have zero scientific backing.)
(The above is just a guess. I have zero scientific backing.)
From past experience conducting data analysis on customer survey responses, I can say that you typically get a "barbell distribution" - most responses are either very negative or very positive, with relatively little in the middle. If people were very disappointed or had their expectations exceeded, they tend to actually respond, if the experience is "meh", not so much.
That could be.
I also have zero scientific backing for it but for me, I would probably not have commented and indeed thought "oh, neat!" had it not been for the negative comments already made. That is also because "oh, neat!" on its own is not a very useful comment to make on a site like this, imho.
[deleted]
For me it's no so much a "Microsoft is inferior because linux did this first" as it is "Why the hell are they only just copying this now?"
> "Why the hell are they only just copying this now?"
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 (!).
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 (!).
But terminals 11 years ago were already more advanced. So, yeah, I'd echo the "wtf took so long?"
All the resources in the world but absolutely glacial progress.
All the resources in the world but absolutely glacial progress.
[deleted]
> Using Show-Markdown you can take markdown and display it as a VT100 encoded string right in the console.
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.)
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.)
Recent comparison of pwsh to bash - finding out if you have the compromised eslint plugin. It's a bit apples-to-oranges, also I would have used 'find -exec {}' in the bash example, but it's still interesting:
bash (by Feross):
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
You can use $psitem instead of $_. I think (don’t quote me on it) it’s shorthand for CLI use. Kind of like `?` being `where` and `%` being `foreach`/`foreach-object`.
It's interesting how different opinions on the syntax are --- the extreme verbosity and "general bureaucracy" of PS is one of the things that puts me off using it unless there's really no other way. It feels like a weird mix of C#/Java, perl, and bash. Reading-Lots-OfWords_With-CapitalisationLike-This is just plain annoying. Perhaps because it reminds me of posts on various forums from users who would capitalise the first letter of every word.
You're being unnecessarily mean.
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 :)
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 :)
When powershell 1.0 came out I LOVED the concept of piping objects like so much streams. In my experience there were two camps of powershellers, the scripters and the programmers.
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.
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.
The various Unixes had growing pains there, too. They took 20 to 40 years to get at a state where all greps behaved more or less the same, and they haven’t even reached a state where regular expressions are standardized.
I think that Powershell lacks right now most an up-to-date free resource. I remember back in 2011-2012 I was working a lot with it and there was a Mastering Powershell e-book which sadly is now gone, except as random PDFs on sites. But it hasn't been updated.
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.
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.
I have much less serious, but similar issues. I do à bit of installing software on third party windows servers (when clients don't have in-house Linux competence sufficient for them to have Linux servers in production).
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...
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...
At least the Powershell doesn't have the incomprehensible argument soup, but that's more the fault of ancient Unix utilities that arose in the days when characters were precious.
I don't do much actual Powershell scripting, but I can tell pretty easily what this should be doing without going to man files.
I don't do much actual Powershell scripting, but I can tell pretty easily what this should be doing without going to man files.
Characters are still precious. I spend my life typing commands and hate poweshell's verbose syntax.
It just doesn't flow.
This really needs a 'ConvertTo-Markdown' to match 'ConvertFrom'. In the same way we have ConvertTo-Json, ConvertTo-Html, ConvertTo-Csv, etc.
That would allow your powershell script's object to be shown as pretty markdown tables.
That would allow your powershell script's object to be shown as pretty markdown tables.
There's a great tool called mdv on macOS if you're interested in using this in the mac terminal
https://github.com/axiros/terminal_markdown_viewer
https://github.com/axiros/terminal_markdown_viewer
In a more general tone, is anyone using PowerShell on Linux?
Indeed it has some good ideas going on and its syntax seems well received from its Windows users, but since having gone cross-platform I haven't seen any comments on using it on Linux besides plain comparing it to bash.
koalalorenzo(1)
It's 2018 and microsoft is still re-inventing the wheel in the most useless way possible. As a linux-user, I almost take it as a given that I can just display markdown in the terminal (in my case, using vim) and in the windows world it's apparently a totally new concept.
In Windows there's been a lot less emphasis on the terminal since most functionality has only been configurable using the UI. This is changing now.
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.
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.
I'd agree with that if windows was less bloated. If it was an acceptable position that it never had good terminal support because it did one thing and did it well, and that thing happened to be GUI, then yes, why bloat it with useless shell features that their user base doesn't need. Instead, windows has always been filled with features nobody wants or needs (looking at you, Internet Explorer 10), and most of them are way larger and probably took more development effort than it would have been to just build a good terminal emulator.
You are crazy if you think that more people would prefer a terminal emulator than a built in web browser in Windows. There's a reason most home users use Windows and not Ubuntu, and it's not spelled terminal.
You're rather missing the fact that Windows does not have a terminal I/O model. It has a console model. Consoles are what the 1960s terminal model evolved into during the 1980s; from firmware-mediated access to CGA, through the VIO+KBD+MOU subsystems of OS/2, to Windows NT console objects.
* http://jdebp.info./FGA/tui-console-and-terminal-paradigms.ht...
* http://jdebp.info./FGA/tui-console-and-terminal-paradigms.ht...
So you're saying they're bringing feature-parity to Windows, and improving the situation there, and that's useless? Run that by me again?
The argument is that they should adopt existing widely used tools not create their own walled garden which is an inferior copy in order to lock people into their system.
"Inferior copy"? You're delusional. PowerShell is better in almost every possible way. It's more discoverable, more consistent, easier to script with, easier to read, and doesn't require error-prone text parsing in its pipeline.
It's what you'd expect from 30 years of hindsight.
It's what you'd expect from 30 years of hindsight.
The spittle-flecking above is not great, but calling people delusional because they disagree with your choices about ultimately meaningless technical crap is a profoundly shitty thing that you should feel some measure of shame for doing.
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.
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.
A) Shorthand for commands in powershell are many and customizable
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
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
https://github.com/PowerShell/PowerShell for "every" system (values of any include linux and OSX).
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.
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.
[deleted]
I don't understand the usefulness of Microsoft investing time in writing a built in half finished markdown rendering engine. With Linux these things just pop up and get popular as people get used to them. Feels like Microsoft is trying to just woo developers on the fence.
This a preview version so half-baked features are to be expected. More to point, from the PR, according to one of the collaborators "[t]he goal here is to open the way for native supporting help files in Mardown format. So currently [they] only need "convert from Markdown" and rendering. Later [they] could add other cmdlets." It seems Microsoft plan is to make a `man` (or `info`?) system but using a sane language instead.
Thank you for the thorough explanation.
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.
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.
Why is this getting down voted? I'm giving a valid point, and no one seems to have a rebuttal. Why would they make this?
So PowerShell has an integrated dingus[0] now eh?
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”?
[0]: https://daringfireball.net/projects/markdown/dingus
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”?
[0]: https://daringfireball.net/projects/markdown/dingus
Apparently.
* 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.
* https://daringfireball.net/projects/markdown/
* https://unix.stackexchange.com/questions/43669/
* 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.
* https://daringfireball.net/projects/markdown/
* https://unix.stackexchange.com/questions/43669/
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).