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: <i>/</i>", 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.
Two months ago I hacked something like that for my blog:<p><pre><code> curl https://fuse.pl/beton/10print.html # with code highlighting
curl https://fuse.pl/beton/cegla.html # just prose</code></pre>
Wow, this is a nice feature! I'd much rather implement it by having a .txt or .raw file just in the same folder as the HTML page though, rather than having to go in the middle of the URL. I feel like it is more convenient to do so.<p>Example, rather than <a href="https://mahdi.blog/raw/raw-permalinks-for-accessibility/" rel="nofollow">https://mahdi.blog/raw/raw-permalinks-for-accessibility/</a>, it would be <a href="https://mahdi.blog/raw-permalinks-for-accessibility.raw" rel="nofollow">https://mahdi.blog/raw-permalinks-for-accessibility.raw</a><p>It's a minor nitpick really, but I quite like this idea! I think I'll try to implement this for my website too.<p>As for the other people here wondering why User Agents weren't used for this:<p>- Using static website hosting goes out the window, which is quite a shame because it makes everything so much easier<p>- User agents are pretty terrible for determining capabilities and intent (what if someone was using curl to get an actual webpage?)<p>- It will never cover all types of HTTP clients (a whitelist is pretty terrible as we have seen from various online services restricting Firefox users or Linux users from certain features for no other reason than their user agents weren't in the list the developers used to check for the presence of certain features).
> To make this easily readable on small screens and terminals, I used vim’s text-width setting to make sure my lines do not exceed 80 characters:<p>I never understand comments like these. Now if my terminal is 78 characters it is a mess or if it is 100 characters it is wasting space. If you just don't wrap the lines my terminal does it at the right width.<p>Hard wrapping doesn't work well. You need to know the target width to wrap and you don't know that until someone actually opens the file. Every viewer I have ever tried is excellent at soft-wrapping. Let it do its thing.
Or use:<p>lynx -dump <regular URL><p>elinks -dump <regular URL><p>(not the same thing of course, but it doesn't require anything from the server other than reasonable HTML)
Fun idea.<p>If the site is not a static one, you could check the request's User Agent server-side, and return the raw version directly (or redirect to /foo/raw) if the UA contains 'curl' or 'wget'.<p>If the site is static and you are able & willing to change your vhost config, you could detect the UA too, and redirect to /foo/raw.<p>Just a few ideas. This is a fun little project you've got here. Well done.
You can read mine using netcat :P<p><a href="https://apitman.com/19/#netcatable" rel="nofollow">https://apitman.com/19/#netcatable</a>
Pretty cool. Short step from here to publish the blog via Gemini. That protocol uses Gemtext as the core hypertext, and it’s basically markdown.<p><a href="https://gemini.circumlunar.space/software/" rel="nofollow">https://gemini.circumlunar.space/software/</a>
Cute idea, but the first one I picked didn't work very well: <a href="https://mahdi.blog/raw/mathematical-induction-proving-tiling-methods/" rel="nofollow">https://mahdi.blog/raw/mathematical-induction-proving-tiling...</a>
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<p>Example:<p>curl <a href="https://mahdi.blog/raw/self-hosted/" rel="nofollow">https://mahdi.blog/raw/self-hosted/</a> | less
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.
If you use glow[1] you can even format/color the markdown nicely `<a href="https://mahdi.blog/raw/raw-permalinks-for-accessibility/" rel="nofollow">https://mahdi.blog/raw/raw-permalinks-for-accessibility/</a> | glow -`<p>[1]: <a href="https://github.com/charmbracelet/glow" rel="nofollow">https://github.com/charmbracelet/glow</a>
Why not use user agent detection (and maybe have a header/footer that says "This page has been formatted for readability based on your User Agent: curl").<p>I'm guessing the blog is made by a static site generator, so the above is harder than it seems. I suppose one could add a reverse proxy that redirects to /raw/$PAGE when it sees "curl".