SoylentNews is people
SoylentNews
Well, that didn't take long: within a week of applause for Microsoft's decision to open-source PowerShell, a comment-war has broken out over
curlandwget.For those not familiar with these commands: they're open source command line tools for fetching Internet content without a browser. Apart from obvious applications like downloading whole sites (for example as backup), they're also under the hood for a lot of other toolsets (an example the author is familiar with – GIS tools use
curland/orwgetto fetch maps from Web services).For some reason, Microsoft's team decided to put aliases for
curlandwgetin Windows PowerShell – but, as this thread begins, those aliases don't delivercurlandwgetfunctionality.The pull request says the aliases should be spiked: "They block use of the commonly used command line tools without providing even an attempt to offer the same functionality. They serve no purpose for PowerShell users but cause confusion and problems to existing
curlandwgetusers."
-- submitted from IRC
(Score: 1, Insightful) by Anonymous Coward on Tuesday August 23 2016, @01:28PM
Interesting problem.
Best case: Microsoft is stuck with what turned out to be a stupid thing that a bunch of it's customers depend on.
Worst case: Microsoft did an intentional Embrace, Extend and Extinguish and got called on it.
There are definitely at least 2 separate user camps here. Both need to be supported.
Possible way out:
A unix shell has a PATH variable to specify the order to look for finding the command to execute.
These internal shell aliases bypass this mechanism.
Perhaps they should add an explicit 'ALIAS' to the path string so the user can pick the search order.
PATH = /usr/bin:ALIAS works the Linux way
PATH = ALIAS:/usr/bin works the Microsoft way
If their corporate governance is actually worth anything it should do two things;
1) prevent killing working things for current paying customers.
2) let their RFC process provide a broader community review of if this (or something else) is a good idea BEFORE they get stuck with it.
(Score: 2) by NotSanguine on Tuesday August 23 2016, @02:12PM
Apparently, this is only an issue on Windows, not on Unix/Linux [github.com] (unfortunately, there doesn't seem to be a way to reference specific comments in the discussion thread. :( ) :
The issue with these aliases on Unix/Linux is discussed here [github.com].
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by NotSanguine on Tuesday August 23 2016, @02:20PM
As an aside, using bash, perl, python and/or a myriad of other tools on Windows systems creates portable tools which can run, unmodified, pretty much everywhere.
I guess the use case for a cross-platform powershell is if you only know powershell and/or have a large library of PS scripts.
However, powershell (IMHO) is pretty painful to use compared with other scripting languages. Better to learn Perl or Python, and shell (Bourne, Korn, C or other), methinks.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 3, Informative) by NCommander on Tuesday August 23 2016, @03:07PM
PowerShell's programming model is better than bash but its got a fundamental design flaw that makes it unpleasant to work with.
Basically, in PS land, every cmdlet is an object. So I can call for a NS lookup, and then work with that as an object; for scripting that's far better cleaner than shell scripts (and PowerShell is essentially a bash alternative on Windows). The problem is the pipeline. If you don't catch objects, they can "leak". Basically, if I do "Resolve-DNSName" or something similar, and don't catch the return code, the object leaks into the pipeline, and can be retrieved by something completely unrelated and unexpectedly. The behavior is incredibly uninutive when it happens, and its gotten me to the point that I have to catch everything to make sure the pipeline is pristine in all cases.
Still always moving
(Score: 0) by Anonymous Coward on Wednesday August 24 2016, @01:23AM
there doesn't seem to be a way to reference specific comments in the discussion thread
#issuecomment-241046950 [github.com]
Mark the text where you think the good stuff might be hiding within the page's source code.
Right click.
Click View Selection Source.
Look for _id= or _name= (where _ is a whitespace).
Append a crunch|hash mark|number symbol|pound sign to the URL.
Mark what is in the quote marks following the tag mentioned above and paste it at the end of the URL.
N.B. I use SeaMonkey.
-- OriginalOwner_ [soylentnews.org]
(Score: 2) by NotSanguine on Wednesday August 24 2016, @02:23AM
Thanks!
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by Marand on Wednesday August 24 2016, @06:05AM
It's easier than that. If you look at a comment's heading, it says something like "$NAME commented $TIME ago", right? The $TIME portion of that heading is a link to that specific comment.
It just has absolutely no visual indication that it's a link because Github's designers all became pants-on-head retarded at some point. Which is also why everything on Github is bold for me in Linux, because they did a terrible hackjob attempt at using "system fonts" by default, and as a result, it defaults to using Roboto because I happen to have it installed...
(Score: 2) by NotSanguine on Wednesday August 24 2016, @08:06AM
Even better! Thank you kindly, sir or madam.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 3, Funny) by NotSanguine on Wednesday August 24 2016, @08:09AM
It's better because now I know how to link to specific comments. But you're right, the design (if you can call it that) is quite poor.
How does that old saw go again? "I may be slow, but my work is poor." Yes, I think that's it.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by Marand on Wednesday August 24 2016, @12:37PM
Glad I could help.
Seems like lately Github's website is more trouble than it's worth. Some random things that come to mind:
• The poorly displayed comment links that require treating the webpage like an old-style adventure game where you blindly hover over anything that might be interesting in the hopes of finding the macguffin needed to continue
• Huge waste of space on comments for the damn +1 emoji bullshit
• If you're viewing a repository, the search box now searches within the repository, with no clear way to search site-wide again. Know how you do it? You hit backspace on the empty search box... How's that for fucking stupid, hidden, magic UI bullshit?
• The Roboto thing I mentioned, where it tries to use system fonts and ends up looking weird. The actual problem is that the CSS used for text now is -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";, in a misguided attempt to use system-default fonts instead of browser-defaults. So, if you happen to have a font installed that's from a different system that's closer to the head of the list, you get that font. Here's what it looks like, [imgur.com] along with my Stylish tweak to make it tolerable again on my system.
Probably more, but I usually interact with github through git on the CLI, thankfully. They really went all-in on the "social" bullshit and seem to be determined to make the site as uncluttered and usable as Facebook.
(Score: 0) by Anonymous Coward on Wednesday August 24 2016, @05:58PM
Yeah, the method I described -should- work, even on pages when there is no obvious thing to click (in this case, the date within each post).
We should note here that some page "developers"[1] don't understand the concept of accessibility[2] and especially not the concept of a #FragmentIdentifier.
In the article which spawned one of my recent submissions [soylentnews.org] I found one of those.
In those cases, I add a critique to the URL [insidehighered.com]
(and the editors typically remove those).
[1] ...and a bunch of those "developers" just reuse someone else's page boilerplate without understanding what the tags within it do.
[2] Folks who are blind and use a text-to-audio screenreader as well as folks who use a text-only browser really hate those poorly-educated guys.
(The very first thing on any page that doesn't start its main content at the very top of the page should be a Jump to content link.)
Note: I have special emotions for the guys who include one of those--and don't check to see that it actually WORKS.
-- OriginalOwner_ [soylentnews.org]
(Score: 0) by Anonymous Coward on Wednesday August 24 2016, @07:30AM
Worst of both worlds... The people wanting to use Powershell on Windows are those already familiar with Powershell, and they will expect it to behave like the Windows version. Everybody else prefers bash anyway.
(Score: 2) by NotSanguine on Wednesday August 24 2016, @08:29AM
Just to recap: on linux, on the latest pre-release build (6.0.0-alpha.9) there is no collision between any unix tools and PS aliases. The right thing on linux is already done. This change is windows-only.
Worst of both worlds... The people wanting to use Powershell on Windows are those already familiar with Powershell, and they will expect it to behave like the Windows version. Everybody else prefers bash anyway.
As you mentioned, the folks using Powershell on Windows have been using the 'curl' and 'wget' aliases for many years, so presumably those people *expect* those aliases to call the Invoke-WebRequest cmdlet.
However, the potential solutions being bandied about in the Github discussion thread are mostly along the lines of giving folks the option to disable aliases which have collisions with *nix style utilities rather than doing away with the aliases altogether. Powershell defaulting to parsing aliases in scripts is (IMHO) a poor idea, and Microsoft agrees. In fact, they strongly recommend that users do *not* use aliases in scripts, and call the corresponding cmdlets directly instead.
Those who are used to *nix style functionality (whether on Linux/Unix or with Cygwin/MKS/native tools on Windows) are coming late to the game and are flabbergasted at the perceived arrogance of the Powershell devs aliasing their own, inferior cmdlet to those well-known names.
You are correct in that most of us prefer Bash anyway, on Windows or Unix/Linux. Well, at least I do.
No, no, you're not thinking; you're just being logical. --Niels Bohr