This is a good example of a program I would like to use if it was distributed in the standard repo of my OS, rather than totally unvetted on the Microsoft Github page of a random developer.
PS: I don't know why HN allows downvoting seeing how it is always so abused. Nothing I wrote here is factually false, and what remains is just my personal opinion as a principled user of FOSS. A bit of tolerance for others' viewpoints is in order.
Its time to invent something lightweight and good which runtime is so small that it becomes a system default.
like a microvm with normal language features. Something you can and want to actually attach a debugger onto it. Something independent of architecture too.
I just hate bash :| Even just using bash and curl and checking if its a website or an error page...
I have moved away to Jekyll again but there's always something alluring about single file things - single file webapps, single file LLMs (llamafile) and others
Nice idea but I don't understand why people write bash scripts more than a few lines long.
There's absolutely 0 advantage, especially when AI can write simple code like that easily, over using any other language. It makes reading and maintaining much more complex.
Hell, even GitHub's syntax highlighting (and VS Code's) breaks in many places throughout the script. It's just a terrible developer experience, even for your own scripts that nobody else will ever touch.
Some people will say that the advantage is that you don't need to install another runtime, but even this is wrong as the script uses bash, not sh.
I hate Python with a passion, but I'd gladly take it over bash for any of those scripts.
Bash is HN's little punching bag language for some reason. Every post about shell programming or project thereof sees a hoard of comments denouncing the language in vage, unspecific terms, "if you need to write more than $N lines of sh, you should use a REAL language".
I'm truly mystified as to why we're doing this. True, shell programming has footguns, but they're not egregiously numerous compared to the typical suggestioned replacements.
Funnily enough, when the issues with these other languages are brought up—like arbitrary code execution on module import—instead of shallow comments, we often cue an informative and interesting discussion.
Why do we HNers treat the shell language so differently?
One of my working hypotheses is that it's due to shell being both ubiquitous and unfamiliar. Everyone uses it but earnest study is rare. That perhaps make it an easy stress sink for our various sublimated frustrations.
I'm an unabashed (heh) fan of shell programming. It really is a beautiful little language once you learn how to think in terms of data streams, dynamic scope, and DSL design.
It's so interesting to me how people consider writing bash scripts to be some sort of absurdist gimmick. I've made some scripts like this for blogging, as well as many other things.
It's often not the best choice. There are situations where, I'd argue, it is. One of the main reasons, in my experience, is for very lightweight servers. I don't want python or node or anything. I want to run a web server with 128mb of ram and a 1gb disk. Somewhat niche, but it's useful to just use the base system.
The other useful thing about it is knowing your shell in general. Even if you're not on the infrastructure team, being comfortable knowing how to navigate a system is both fun and sometimes critical. You never know when you'll need it, and it's an interesting look into your tools.
It's akin to saying "why know how to use a saw when you can use a chainsaw" or "why know how to make a fire when you can use lighter fluid and a lighter?" Sometimes things come up. And it's fun to know how we got to where we are today.
Another big reason, for me at least, is that the scripts are unlikely to degrade over time.
A process or workflow that involves a 3rd party service or application will have to be modified or reconsidered as the 3rd party's functionality changes, is updated, or disappears.
bash script for blogs is a clever idea but writing in terminal might not be.
an alternative angle : script that reads local .md file and deploys it might work well.
yes true, but I already have it on all my machines, for diverse reasons...it wouldn't be hard to implement a markdown support, but it would be worse to maintain that
21 comments
[ 1738 ms ] story [ 1271 ms ] threadI used a similar system back in the day, nanoblogger:
https://nanoblogger.sourceforge.net/
PS: I don't know why HN allows downvoting seeing how it is always so abused. Nothing I wrote here is factually false, and what remains is just my personal opinion as a principled user of FOSS. A bit of tolerance for others' viewpoints is in order.
Because bash is maybe worst than C for this task.
like a microvm with normal language features. Something you can and want to actually attach a debugger onto it. Something independent of architecture too.
I just hate bash :| Even just using bash and curl and checking if its a website or an error page...
I have moved away to Jekyll again but there's always something alluring about single file things - single file webapps, single file LLMs (llamafile) and others
There's absolutely 0 advantage, especially when AI can write simple code like that easily, over using any other language. It makes reading and maintaining much more complex.
Hell, even GitHub's syntax highlighting (and VS Code's) breaks in many places throughout the script. It's just a terrible developer experience, even for your own scripts that nobody else will ever touch.
Some people will say that the advantage is that you don't need to install another runtime, but even this is wrong as the script uses bash, not sh.
I hate Python with a passion, but I'd gladly take it over bash for any of those scripts.
I love bash for quick hacks. I abhor it for things like this.
I'm truly mystified as to why we're doing this. True, shell programming has footguns, but they're not egregiously numerous compared to the typical suggestioned replacements.
Funnily enough, when the issues with these other languages are brought up—like arbitrary code execution on module import—instead of shallow comments, we often cue an informative and interesting discussion.
Why do we HNers treat the shell language so differently?
One of my working hypotheses is that it's due to shell being both ubiquitous and unfamiliar. Everyone uses it but earnest study is rare. That perhaps make it an easy stress sink for our various sublimated frustrations.
I'm an unabashed (heh) fan of shell programming. It really is a beautiful little language once you learn how to think in terms of data streams, dynamic scope, and DSL design.
It's often not the best choice. There are situations where, I'd argue, it is. One of the main reasons, in my experience, is for very lightweight servers. I don't want python or node or anything. I want to run a web server with 128mb of ram and a 1gb disk. Somewhat niche, but it's useful to just use the base system.
The other useful thing about it is knowing your shell in general. Even if you're not on the infrastructure team, being comfortable knowing how to navigate a system is both fun and sometimes critical. You never know when you'll need it, and it's an interesting look into your tools.
It's akin to saying "why know how to use a saw when you can use a chainsaw" or "why know how to make a fire when you can use lighter fluid and a lighter?" Sometimes things come up. And it's fun to know how we got to where we are today.
A process or workflow that involves a 3rd party service or application will have to be modified or reconsidered as the 3rd party's functionality changes, is updated, or disappears.
find . -name '*.md' -type f -exec sh -c '
' sh {} +https://github.com/adityaathalye/shite
https://news.ycombinator.com/item?id=34486596
Engine: https://github.com/alganet/alganet.github.io/blob/master/bui...
Result: https://alganet.github.io/
Does RSS, updates old pages when index.html changes, dual-language.
My local test server is also shell: https://github.com/alganet/alganet.github.io/blob/master/ser... (good old https://gist.github.com/alganet/140c7c12d1603c244a01 from 2015)