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

31–40 of 73 posts

Re: You can read my blog posts using curl

#31

Post by mxuribe »

Sheeny96 wrote: post #28
mxuribe wrote: post #20

Earlier quoted context omitted.

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, o…

Interesting. It's easy to fall trap to the tech mindset - my big ideas to change the lives of your average person are often humbled whenever I have to explain the difference between a web browser and the internet, to my averagely tech literate mid 20s friends.

You and me both! :-)

Re: You can read my blog posts using curl

#32

Post by IanCal »

mort96 wrote: post #27
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.

Browsers send "Accept: text/html" explicitly. For my pastebin[1], I send an HTML document when "text/html" is in the list of accepted formats, and I just send the plain data otherwise. This seems to work in practice, doesn't hard-code knowledge about curl, and doesn't require curl users to add custom headers. [1]: https://sr.ht/~mort/coffeepaste/

I feel that neatly meets the kind of thing these params are for - if you ask a server for content and say "Accept: */*" the server should be free to return that content in whatever format it likes.

Re: You can read my blog posts using curl

#33

Post by dfbsdfbwe2ef2e »

IanCal wrote: post #32
mort96 wrote: post #27

Earlier quoted context omitted.

Browsers send "Accept: text/html" explicitly. For my pastebin[1], I send an HTML document when "text/html" is in the list of accepted formats, and I just send the plain data otherwise. This seems to work in practice, doesn't hard-code knowledge about curl, and doesn't require curl users to add custom headers. [1]: https://sr.ht/~mort/coffeepaste/

I feel that neatly meets the kind of thing these params are for - if you ask a server for content and say "Accept: */*" the server should be free to return that content in whatever format it likes.

Why do you feel that way?

Re: You can read my blog posts using curl

#34

Post by dfbsdfbwe2ef2e »

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

Damn that looks really polished.

How does the server know what characters to send so that my specific command line interprets it in a nice way? Sorry if I'm not being very articulate.

EDIT: doesn't work when piping to less.

Re: You can read my blog posts using curl

#35

Post by bronikowski »

dfbsdfbwe2ef2e wrote: post #34
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

Damn that looks really polished. How does the server know what characters to send so that my specific command line interprets it in a nice way? Sorry if I'm not being very articulate. EDIT: doesn't work when piping to less.

I'd be honest, my approach is "everything is utf-8, right? And every terminal has at least 16 colors at the ready?". It does not degrade gracefully, I checked. It's more of a party trick than something reasonable, but nothing stops you from doing it correctly, it would just be a hassle to serve in a static way (every variation would require a different txt file to be generated and sent).

> EDIT: doesn't work when piping to less.

try -R

Re: You can read my blog posts using curl

#36

Post by bawolff »

dfbsdfbwe2ef2e wrote: post #33
IanCal wrote: post #32

Earlier quoted context omitted.

I feel that neatly meets the kind of thing these params are for - if you ask a server for content and say "Accept: */*" the server should be free to return that content in whatever format it likes.

Why do you feel that way?

That's literally what the header means according to the rfc.

Re: You can read my blog posts using curl

#39

Post by dfbsdfbwe2ef2e »

bronikowski wrote: post #35
dfbsdfbwe2ef2e wrote: post #34

Earlier quoted context omitted.

Damn that looks really polished. How does the server know what characters to send so that my specific command line interprets it in a nice way? Sorry if I'm not being very articulate. EDIT: doesn't work when piping to less.

I'd be honest, my approach is "everything is utf-8, right? And every terminal has at least 16 colors at the ready?". It does not degrade gracefully, I checked. It's more of a party trick than something reasonable, but nothing stops you from doing it correctly, it would just be a hassle to serve in a static way (every variation would require a different txt file to be generated and sent). > EDIT: doesn't work when pip…

> try -R

works :-)

Re: You can read my blog posts using curl

#40

Post by bronikowski »

dfbsdfbwe2ef2e wrote: post #39
bronikowski wrote: post #35

Earlier quoted context omitted.

I'd be honest, my approach is "everything is utf-8, right? And every terminal has at least 16 colors at the ready?". It does not degrade gracefully, I checked. It's more of a party trick than something reasonable, but nothing stops you from doing it correctly, it would just be a hassle to serve in a static way (every variation would require a different txt file to be generated and sent). > EDIT: doesn't work when pip…

> try -R works :-)

I'm guessing you're on BSD (or maybe Apple)? Their version requires you to tell less there's a raw data at the input.
Post reply on HN