4 ms·

Too bad the "worst areas" list didn't include the UI. I cannot recall the number of times I've spent looking through the docs, which flag was it again? -s? -S?

Too bad the "worst areas" list didn't include the UI. I cannot recall the number of times I've spent looking through the docs, which flag was it again? -s? -S? -q? Every. Single. Time. But it's a minor annoyance. Great great tool.

laumars 12y ago
I personally think curl is one of the better examples of CLI tools as it follows the pipe metaphor by default (which wget doesn't), supports both long and short flags (so if -s isn't memorable, then use --silent) and doesn't require a flag for it's core mandatory input (ie a URL). You can even slide flags in after the URL, if you wanted - which is something you generally only see supported by GNU utilities. I could see curl being a little daunting to someone who is normally uncomfortable with the command line, but that's not really the fault of curl having a bad UI, that's more a paradigm preference of the user.
- matt-attack 12y ago
  > it follows the pipe metaphor by default Completely agree. As a novice 15 years ago, this bugged me, especially coming from arguably simpler tools like wget. But over the years I can to appreciate how it works. And now, wget seems kinda dirty.
- nothrabannosir 12y ago
  as it turns out (just had to look it up again, incidentally!) the correct form when piping it to an output tool is -s -S. E.g.: $ curl -s -S http://example.com/some.json | python -m json.tool I want errors, but I don't want that annoying status bar to mess up the output. I don't use curl often enough to even remember I need two flags at all (e.g. I remember now, but didn't know when I wrote the original comment). It can follow any philosophy it wants: when a user is consistently confused, I personally consider it bad UI. EDIT: This is not the only bad / confusing default. Another popular one is -L. Not following redirects should be the exception; I almost never want curl to choke on 3xx. Result, I could practically alias curl="curl -L". Great software, but the UI is unfortunate.
  - laumars 12y ago
    Firstly, every CLI HTTP client I've used outputs a status to console, even when it detects standard out is being redirected / piped. It can be very annoying at times, but isn't a curl specific thing. And it's hardly a great ordeal to remember --silent (or quickly curl -h | grep silent / do a find inside man, should you need a memory jog). Perhaps a little tip here is to force yourself to use the longer flags as they're much more memorable? Secondly, have you ever considered that there are just as many people who might not want curl to automatically follow redirects? Personally I happen to use curl a lot to check that redirects work (eg sending the right HTTP status code) so I'd find your preference more annoying than intuitive. Lastly, I get that you might not like some of curls default behaviours, but given curl's command structure follows the same idioms as most POSIX / GNU command line programs do, it's a bit far reached to say curls UI is bad or "unfortunate". Particularly when where's other people that do prefer the default behaviour you dislike. And since curl does follow POSIX idioms, you can just create that alias you discussed to force curl into your preferred default behaviour (you don't get much more user friendly than a tool you can customise the default behaviour of). This is why I say that curl follows the standard CLI UI pretty well - it doesn't throw much in the way of unexpected behaviour and anything specific that you may dislike can easily be tuned via the usual methods.
  - deleted 12y ago
    [deleted]
  - pmh 12y ago
    What situation were you running into that required "-s -S"? I'm able to pipe the output of curl to something else (or just consume it via IO redirection) just fine without either switch. The status bar is output on stderr.
jkbr 12y ago
> Too bad the "worst areas" list didn't include the UI. I cannot recall the number of times I've spent looking through the docs, which flag was it again? -s? -S? -q? Every. Single. Time. Complete agree. That's why I created HTTPie[1], a modern take on CLI HTTP to address those usability issues. [1] http://httpie.org http://httpie.org
teh_klev 12y ago
I agree, I use curl once or twice a week and need crib sheet to remember what switches to use and when. I feel it pushes the UNIX tool "do one thing, do it well" thing a bit far.
bch 12y ago
You can prepare a ~/.curlrc to take of these personal defaults for you: ~/.curlrc: location show-error silent
- bch 12y ago
  Additionally 1) if you supply -q as the first switch on the command line, the curlrc file will not be used. 2) you can use -K <config_file> or --config <config_file> to pick a specific configuration.

laumars 12y ago

I personally think curl is one of the better examples of CLI tools as it follows the pipe metaphor by default (which wget doesn't), supports both long and short flags (so if -s isn't memorable, then use --silent) and doesn't require a flag for it's core mandatory input (ie a URL). You can even slide flags in after the URL, if you wanted - which is something you generally only see supported by GNU utilities. I could see curl being a little daunting to someone who is normally uncomfortable with the command line, but that's not really the fault of curl having a bad UI, that's more a paradigm preference of the user.

matt-attack 12y ago
> it follows the pipe metaphor by default Completely agree. As a novice 15 years ago, this bugged me, especially coming from arguably simpler tools like wget. But over the years I can to appreciate how it works. And now, wget seems kinda dirty.
nothrabannosir 12y ago
as it turns out (just had to look it up again, incidentally!) the correct form when piping it to an output tool is -s -S. E.g.: $ curl -s -S http://example.com/some.json | python -m json.tool I want errors, but I don't want that annoying status bar to mess up the output. I don't use curl often enough to even remember I need two flags at all (e.g. I remember now, but didn't know when I wrote the original comment). It can follow any philosophy it wants: when a user is consistently confused, I personally consider it bad UI. EDIT: This is not the only bad / confusing default. Another popular one is -L. Not following redirects should be the exception; I almost never want curl to choke on 3xx. Result, I could practically alias curl="curl -L". Great software, but the UI is unfortunate.
- laumars 12y ago
  Firstly, every CLI HTTP client I've used outputs a status to console, even when it detects standard out is being redirected / piped. It can be very annoying at times, but isn't a curl specific thing. And it's hardly a great ordeal to remember --silent (or quickly curl -h | grep silent / do a find inside man, should you need a memory jog). Perhaps a little tip here is to force yourself to use the longer flags as they're much more memorable? Secondly, have you ever considered that there are just as many people who might not want curl to automatically follow redirects? Personally I happen to use curl a lot to check that redirects work (eg sending the right HTTP status code) so I'd find your preference more annoying than intuitive. Lastly, I get that you might not like some of curls default behaviours, but given curl's command structure follows the same idioms as most POSIX / GNU command line programs do, it's a bit far reached to say curls UI is bad or "unfortunate". Particularly when where's other people that do prefer the default behaviour you dislike. And since curl does follow POSIX idioms, you can just create that alias you discussed to force curl into your preferred default behaviour (you don't get much more user friendly than a tool you can customise the default behaviour of). This is why I say that curl follows the standard CLI UI pretty well - it doesn't throw much in the way of unexpected behaviour and anything specific that you may dislike can easily be tuned via the usual methods.
- deleted 12y ago
  [deleted]
- pmh 12y ago
  What situation were you running into that required "-s -S"? I'm able to pipe the output of curl to something else (or just consume it via IO redirection) just fine without either switch. The status bar is output on stderr.

jkbr 12y ago

> Too bad the "worst areas" list didn't include the UI. I cannot recall the number of times I've spent looking through the docs, which flag was it again? -s? -S? -q? Every. Single. Time. Complete agree. That's why I created HTTPie[1], a modern take on CLI HTTP to address those usability issues. [1] http://httpie.org http://httpie.org

teh_klev 12y ago

I agree, I use curl once or twice a week and need crib sheet to remember what switches to use and when. I feel it pushes the UNIX tool "do one thing, do it well" thing a bit far.

bch 12y ago

You can prepare a ~/.curlrc to take of these personal defaults for you: ~/.curlrc: location show-error silent

bch 12y ago
Additionally 1) if you supply -q as the first switch on the command line, the curlrc file will not be used. 2) you can use -K <config_file> or --config <config_file> to pick a specific configuration.