3 ms·
Author of the tool here. I think you raise a good point; and I don't think it overly nit-picky. Personally I don't find myself using the built-in HTTP client
by TomNomNom 9y ago
Author of the tool here.
I think you raise a good point; and I don't think it overly nit-picky.
Personally I don't find myself using the built-in HTTP client at all (and pipe the output of curl instead); but I know people who do. I ummed and ahhed about keeping this functionality for a while, and surveyed the—at the time fairly small—user base to figure out what I should do. What I found was a subset of users whose use-case was very different to my own; they were often running Windows, with no install of curl (which I believe is actually a default on Windows now?), and only wanted very basic functionality.
I'm definitely a proponent of the Unix philosophy, but I try my best to be pragmatic, especially where it can lower the barrier to entry for users.
- kbenson 9y agoI had thought of this after my original comment. Windows provides a slightly different set of assumptions that a traditional UNIX-like platform. Mainly, that piping is not as common and the chances that the operating system the tool is deployed on will be used as a server at much reduced. There are a couple middle-ground solutions which might be worth exploring: - Only build that functionality on windows. Optionally, provide two packages for windows, one with URL fetching and one without it. - Provide a flag that enables/disables the feature. Either default toit off and allow it to be enabled with a flag (and a helpful error message if oyu attempt to use it without a flag) or vice-versa. - Do nothing. In the end, it's an entirely valid decision to leave it as it is unchanged. I thought it was something worth discussing, both for this tool and for the larger trend in general, but that doesn't mean the problem is so large that it makes the tool unusable until addressed. In any case, thanks for making this. The simplicity and obvious usefulness of this tool means that as someone who deals with JSON quite often, generally in an archived form where I care about one or two entries in lists of hundreds, I imagine I'll be finding lots of use for it in the future.
- erric 9y ago>with no install of curl (which I believe is actually a default on Windows now?) Alas, no. It's just an alias to invoke-webrequest, or what ever their equivalent power shell incantation is.
- coldacid 9y agoAs of Spring Creators Update (coming any time this month) both curl and bsdtar are present in the base Windows install. On my Insiders build 17133.1, curl 7.55.1 and bsdtar 3.3.2 are both present in C:\Windows\System32. The problem is that PowerShell 5.x still maintains the "curl" Invoke-WebRequest alias, and that captures `curl` on the PS command line before curl.exe out of the path. However this (and a bunch of other *nix-conflicting aliases) are removed with PowerShell Core, and annoying aliases can be deleted out of the Alias:\ PS-drive on PS 5.x and older.
- erric 9y agoGood to know, Thanks. I’m sure I will be getting more questions from my co-workers, but adding these utilities is a good thing in the long run.
- bradknowles 9y agoI just wanted to say that gron is one of the most useful tools I've seen posted to HN in a very long time. Thanks!
- TomNomNom 9y agoThank you so much! That really means a lot! :)
- coldacid 9y agocurl is out of box with the next Win10 release expected this month (version 1803) but still not present for older releases or older versions of Windows. By the way, do the Windows builds of gron automatically recognize and support UTF-16? If anyone does try piping curl output in PowerShell, that's what gron would receive -- PS automatically converts stdout and stderr output to UTF-16 because of its use of .NET String for stream I/O.