Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You can read my blog posts using curl

mahdi.blog

Post reply on HN
Print view View original

11–20 of 73 posts

Re: You can read my blog posts using curl

#11

Post by bronikowski »

dxuh wrote: post #10

In these comments people have suggested to check for the User-Agent, but wouldn't it make more sense to check if the Accept header mentions text/html? I realize that curl sends "Accept: / ", but if you wanted to see a page in plain text, you would have to pass -H "Accept: text/plain". I think that uses HTTP much more like it was intended.

When I was hacking that for my blog I went with user-agent detection because of the UX. I don't consider this feature to be anything more that "look at his cool stuff I did" and telling random friend to copy and paste an url prefixed by curl is much easier proposition.

Re: You can read my blog posts using curl

#12

Post by mdibaiee »

tgv wrote: post #2

Cute idea, but the first one I picked didn't work very well: https://mahdi.blog/raw/mathematical-induction-proving-tiling...

ah! that one includes a JavaScript I used to draw a canvas in the post body, hence the script showing up in the curl result. Might try to think of a solution for that.

Edit: fixed it by moving the script to its own file.

Re: You can read my blog posts using curl

#13

Post by mdibaiee »

bronikowski wrote: post #8

Two months ago I hacked something like that for my blog: curl https://fuse.pl/beton/10print.html # with code highlighting curl https://fuse.pl/beton/cegla.html # just prose

the code highlighting is really cool, well done! pretty sure it's possible to do something like that with jekyll by updating the `highlight` liquid tag to be able to render ascii highlighting in case of raw pages.

Re: You can read my blog posts using curl

#14

Post by chrismorgan »

dxuh wrote: post #10

In these comments people have suggested to check for the User-Agent, but wouldn't it make more sense to check if the Accept header mentions text/html? I realize that curl sends "Accept: / ", but if you wanted to see a page in plain text, you would have to pass -H "Accept: text/plain". I think that uses HTTP much more like it was intended.

(Editorial correction: “Accept: /” → “Accept: */*” by backslash-escaping the asterisks.)

Re: You can read my blog posts using curl

#17

Post by nstart »

If you know basic vim movements (j/k for down/up kind of basic stuff), you can pipe the output into less to read it in a more convenient way. Nothing major, just found it nicer to not have to scroll back up when the article loads

Example:

curl https://mahdi.blog/raw/self-hosted/ | less

Re: You can read my blog posts using curl

#19

Post by eddieroger »

dxuh wrote: post #10

In these comments people have suggested to check for the User-Agent, but wouldn't it make more sense to check if the Accept header mentions text/html? I realize that curl sends "Accept: / ", but if you wanted to see a page in plain text, you would have to pass -H "Accept: text/plain". I think that uses HTTP much more like it was intended.

That definitely seems closer to the intent of the header - User Agent is (kind of) who you are, Content Type is what you're sending, and Accept is what you'd like back. If you want plain text, you should be able to ask for it. It's super cool to see a plain text blog option show up, but I would have hoped it would be at the same route, not namespaced `/raw`, and using HTTP conventions. This sounds much more like a dig than it is - it's awesome to have a plain-text version of the author's content.

Re: You can read my blog posts using curl

#20

Post by mxuribe »

Sheeny96 wrote: post #15

A cool add-on to this would be a plugin that automatically redirected /latest to the latest blog post. That way, if the blogger were to publish say once a week every Tuesday, the user could alias the curl for maximum ease of use.

I once suggested this kind of strategy at a previous job...and internally, everyone liked it. But what ended up happening was: our fans of the content kept complaining that they were sharing the /latest url but "the website kept breaking" (in their mind) because last week it pointed to the blog post they wanted to share, and this week, its pointing to a different blog post, and please fix the website, etc. Clearly, our fans misunderstood about redirects...and our fans were vastly, overwhelmingly non-techies...so try as we did to educate them, it became a lost cause...and we stopped employing that tactic. Our fans as i call them were real estate agents who affiliated with the real estate company that i worked for...and these guys i called fans because they were the most fervent, avid followers of the company's brand, and they sold million-dollar plus homes...so they had plenty of pull with the senior leasders at the company, but to be fair they did follow the brand religiously...so like i've heard poeple say: support your most ardent fans. In any case, since that time, i'm careful to set expectatins about expected behaviors as it pertains to links, web resources, redirects, and such. (Of course, such a tactic might work for other audiences too.)

EDIT: typo fixings.

Post reply on HN