Hi maintainer of Hurl here, thanks for the link; Hurl is using libcurl as its HTTP engine (you can for instance use --curl to get an export of curl commands). In a few words, if you just use Hurl, you just use curl also...

Emacs had something like this long ago (of course it did).

https://github.com/pashky/restclient.el

I also like httpie but they seem to have gone commercial.

Basically a shell script with a curl invocation in it, except you need to install extra software to execute it. Misses the point of the article.

For the record, since version 7.82.0.

Just fyi: the writing style is a meme. I think it's following the "just use html"[0] format (though, that may be its own riff on the meme).

Not to detract from you point; just to say that the author is probably not as angry as this could make them seem.

[0] https://justfuckingusehtml.com/

Not to mention saving headers, tokens, doing multiple requests using the results from the previous, etc.

This guy would say "just use bash" and ignore the average user experience.

> This whole piece also reads like someone is quite angry at people

It’s a meme that originated with https://thebestmotherfucking.website/ or one like it.

The Google style guide is a good reference: https://google.github.io/styleguide/shellguide.html#s1.2-whe...

  - If you are writing a script that is more than 100 lines long, or that uses non-straightforward control flow logic, you should rewrite it in a more structured language now. Bear in mind that scripts grow. Rewrite your script early to avoid a more time-consuming rewrite at a later date.
  - When assessing the complexity of your code (e.g. to decide whether to switch languages) consider whether the code is easily maintainable by people other than its author.

I think you misinterpret the text you're quoting (but it's hard to tell since you didn't include a link).

-X POST is not wrong, it's just superfluous when using other flags like -d where the method can be inferred.

POST requests are often sent with no data (anything that is not idempotent should, unless there's another verb that could fit better).

That may be true for a tool that's not used often. For professional tooling, muscle memory and response time beat discoverability any day of the week.

GUIs are (usually) slow and break the flow. They cater for the bottom of the pile of users, in detriment of the top.

Yeah, hence why no one uses terminals for doing work with git, codex, claude-code, neovim and curl, everyone and their mother are using desktop GUIs for those things, clearly.

Yeeeep.

My response to this article is the same one I have to anyone out here screaming "it's so easy to just do it my way!": if it's so easy, then do it for me!

The ffmpeg fans are the loudest screechers I've found, in this area. They'll point to the trainwreck of a UX that is Handbrake as an example of GUI for terminal commands. And, look - command line utilities are great and Handbrake is a super good product that functions well and does more than I'd ever want it to. But neither of those things are the same thing as having good UX.

If it's so easy to compile a bunch of shell scripts and store them in a directory in a git repo, then package together a bunch of them that every dev would need, sprinkle in a few with placeholders that most devs would need (with some project-specific input), and then serve them to me in a composable GUI that, in real time, builds the command to be run in my shell. Let me watch the clicks edit the command, and then let me watch the "submit" execute the command. There's no surer way for me to learn exactly what commands I need than to see them all the time. And if I have to learn them (so that I can use them) BEFORE I've seen them - in context - a few times at least, then I'm going to have a much harder time remembering. UX, when done right, helps the user.

Put simply: if I can do everything I would be able to do with postman using curl, then I should also be able to wrap curl in a thin DearImgui window that is reactive to user input. And if it's as easy as the author says, their time would have probably been better spent just making the GUI wrapper app and presenting it as a way to get better with curl, rather than writing an edgelordy article about it.

define "user"

people needing/using curl would have been a very distinct subset of users.

I actually completely agree. I am learning OpenBSD and the man pages are very good, but all too often I find myself reading them, beating my head against the wall, and then googling or using tdlr or gippity.

For example, I just was digging into BSD_auth and authenticate, and I don't know much about how auth works generally. I found it pretty tough to grok from the man page. I love the idea of learning everything from directly within the system and man pages, but I might just not be smart enough for that.

Add this to the end of .bashrc

function cheat() { curl cht.sh/$1 }

Then in terminal you can use the following to see the examples: $ cheat curl

> Does anyone have tips for how to make it more useful? Maybe I could grep better for options? For example in the link, the author lists out common curl commands like making a POST request or adding a header. If you tried to look through the manpage for this, this would take a long time.

You can search a man page by pressing the '/' key, typing in what you want, and pressing 'enter'. 'n' jumps to the next instance of your search string 'N' jumps to the previous instance.

I often find it easier to read man pages in the browser. Use `man --html=<browser executable>`.

Ask your AI tool of choice - it’s great at reading manpages. I also add my most favourite prompt instruction “be succinct”. :)

This person is my spirit animal. "You can remember 400 Kubernetes commands but not curl -x POST?"

That was exactly what I needed this morning.

What i do is assign the token to a variable. I typically copy the secret to my clipboard, and then use the pbpaste command in macos terminal when assigning it to avoid secrets in my command history.

I think curl can load headers or other data from a file. And you can always $(cat token.txt) in the cli.

curl may be outdated but at least it's a survivor. the alternatives (esp. the suspicious httpie grift) won't make it.

https://news.ycombinator.com/item?id=9224 "you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software." -- on why Dropbox should not exist.

People absolutely will pay for software rather than reading or thinking, if it makes doing the work easier. You may have heard of this thing called chatgpt.

(not being a web developer, I've only lightly used Postman, and it is definitely handy for things like authentication. Especially once you touch OAuth. But I uninstalled it once they went unnecessarily cloud)

Because it's convenient. I use curl often, but admit to using Bruno even more often. And yes, I could have some organized scripts or something, but for playing with various APIs daily, sometimes importing whole .json collections, or even setting up credentials in one place and reusing them across all the requests from a collection - that's just fast, easy and convenient. Same for responses - yes, I could work with jq and analyze in the console, but often I don't really know what exactly I'm looking for, so it's just easier to have it visually parsed and click through items

I use both. It's quite convenient to have all the collections available and just send the request with a couple of clicks.

I’m also a CLI old timer, but there’s undeniable utility in having a Postman-like collection to test drive a mobile app API. You can save state from responses and use it in subsequent requests. E.g. log in, save the access token, create a post, save the id, post a comment under the post using the id. It’s all very useful, to say nothing of the fact that you can give said collection to non-technical stakeholders and they can solve a lot of their own problems without going to get one of the engineers to Do A Command Line(tm).

All that said, I wouldn’t touch Postman. Last time I needed something to fit this bill I looked around to find the open source equivalent and found Bruno.

I am new to curl. We use secure connection to Visa and Maactercard API. We have the certificate in a jks file.

Is there a way to send the json request that one sends in Postman but in curl while also using the jks file?

Similarly, we use SoapUI to send XML requests. Is there a way to send those XML requests using curl while also using the jks file?

Greatly appreciate your help.

Some people like to think about the problems related to the actual work instead of looking up CLI tool manpages when they need to do something once in a blue moon.

I use curl liberally and also tend to create scripts around it to perform common tasks, but I still get why someone would prefer a GUI.

If you're doing a lot of requests for testing or some other purpose I could see an argument for a graphical interface. Curl is a masterpiece but it's not that simple to use. But again, we're in $current_year and I'd be surprised if "hey Claude, can you cook up a curl request to do this and that" doesn't work.

> ... literally requires a little bit of light RTFM?

This is why, people do not want to bother with the docs.

cURL is an amazing tool, but it's more "HTTP client" and less "full blown API client".

The page even sort of acknowledges this... saying you manage your environments with environment variables. It doesn't mentioned how to extract data from the response, just jq for syntax highlighting. No explanation of combining these two into any sort of cohesive setup for managing data through flows of multiple requests. No mention anywhere on the page of working with an OpenAPI spec... many of the tools provide easy ways to import requests instead of manually reentering/rebuilding something that's already in a computer-readable format.

So the tl;dr here is "use cURL, and then rebuild the rest of the functionality in bash scripts you idiot".

I went down this path of my own accord when Insomnia was no longer an option. I very quickly found myself spending more time managing bash spaghetti than actually using tools to accomplish my goals.

That's why I use a full blown dedicated API client instead of a HTTP client. (Not Postman though. Never Postman.)

Using curl, how would I send a collection of frequently used requests to a coworker?

Plain text file?

postman used to be a relatively lightweight client with a tolerable UI to quickly set up and test what you needed.

Then it turned into a monstorsity.

I like it. It makes me smile. Don't take it personally.

Foul language has never really bothered me, and I think it's effective in communicating a relatable (to me) frustration with people ignoring the answer staring them in the face.

> The tools you need are simple. They're fast. They're reliable. They've been battle-tested by millions of people for years. Just fucking use them.

It's a very millennial flavor of Reddit-coded edginess that appeals mostly to other Reddit millennials.

I like reading it sometimes. It doesn't make me more likely to do what it suggests though, if anything potentially less likely. Like a "Haha, what a guy. Now let's get on with my day" kind of vibe.

13 years old me, back when Maddox offered a very fresh and novel form of content you could grab on your way through the Information Superhighway

It takes me back. This was normal discourse in the 80s and 90s in the development community, especially the BBSs and telnet communities. I think the entire development community back then was afflicted with Tourette's Syndrome!

As long as I agree to what is being said, I like this style :)

Me, I have a dark and immature sense of humor.

What a weird place to try and raise moral panic.

Do you ask people "Do you actually enjoy talking like that?" every time you hear a curse word?

I do, dipshit.

Uhm, yes.

xh is mandatory Rust rewrite of httpie :)