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.
Its very niche. This is a static site generator so you could run something a lot heavier and then rsync the output to the server. Even lighter on the server than running bash there.
It is also limited so you might have to add other things. The README suggests using markdown.pl for markdown support.
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.
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
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.
Why? If it works and it gives you the features you require that where's the issue? If all 1200 lines of code are utilised and provides you with the blog stack then that's pretty efficient.
How is this any different of someone including multiple python modules to create the same stack for which probably amount to more lines of code if you were to copy and paste in to a single document.
It's like react, a stack with stupid amount of LoC only for the developer to use 1% of and the rest sits unused and bugs the site.
You can source bash scripts so if it's lines of code, break them in to chunks.
> How is this any different of someone including multiple python modules to create the same stack for which probably amount to more lines of code if you were to copy and paste in to a single document.
There's no problem with 1200 lines of code. The problem is 1200 lines of Bash. The difference is that Bash is incredibly awkward and error prone compared to almost every other language out there.
I suppose my main bash script on BSD, ~400 lines for backup, compilation and other admin tasks including a portable static text/plain web server have never failed me but never tested them interchangeably, so, prone some truth to failure.
I am not disagreeing of course and I would agree, Bash is designed for the system functions and that this is niche. However if it's all you got, eh, go for it.
Systems admin for 15 years and have handled some very hosed systems. Maybe the python binary got hosed and you were really desperate to share your lasagna recipe with your mother and the internet, it does have a purpose. Not ideal, sure.
I'd rather a single unruly page of code to do the whole thing rather than multiple modules that do multiple things half-efficiently that require multiple thought to uncover.
Awesome! I’m the author and I created that project as a way to teach myself Bash at the time. I called it NanoBlogger because it was inspired by MicroBlogger, yet another Bash blog.
I still have fond memories of the open source community’s warm welcome and amazing contributions to the project.
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 the wrong choice for truly complex software but I still find it really hard to pick anything else for the sort of tasks where I'm mostly manipulating text files and shelling out to other tools. My general instinct for when its time to reimplement a script in Python or similar is when I've got a ton of conditionals or function calls, at that point its also time to start writing unit tests.
shellcheck is a huge help in the middle sized shell script space and will regularly shout at me about missing all the random gotchas like not quoting file paths.
> Nice idea but I don't understand why people write bash scripts more than a few lines long.
From a pragmatic perspective I agree. But I think you’re missing the point here. A lot of the most entertaining, and dare I say inspiring content, found on Hacker News is about exactly things like this. Things that seem silly, but are also very intentionally pushing the boundaries to the extreme/absurd.
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.
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.
> This is a good example of a program I would like to use if it was distributed in the standard repo of my OS
So why are you waiting? Be the change you seek. Simply become a maintainer of a distro, and publish the package there. Repeat for all the major distros.
Things that end up in curated package repositories like those of the various significant distros, have usually spent time growing on the random developer's own page (most common in the past) or said random developer's account on a forge like github (most common in more modern times).
Standard repos might be were many discover things, but those things don't normally get there until they've build a following, so the random developers page is the more significant vector overall.
Fair enough. It would be nice if more developers would at least consider using the forges that don't belong to an ethically compromised big-tech oligopolist. The options are there.
This reads like parody! In a sane world (and I believe the HN community rules are fairly sane) we should be upvoting things that are interesting, or insightful, or informative, or otherwise tickle our curiosity. Not just because we agree with them! After all, who cares that I agree with something? Everyone has an opinion on everything, opinions in themselves are cheap and uninteresting.
So one cannot have or express an opinion on hosting as it is a priori and uncontestably lacking in insight and universally uninteresting?
And HNN requires either or both: opinions must be insightful or interesting.
And what is either of those is objective, self-evident, and not even slightly subjective.
Right? How is this not merely a blanket way to assert opinions that are themselves boring and un-insightful ("hosting opinions are forbidden" is the de facto claim)?
Hosting on Github has been an up voted story several HNN times. Yet here its not interesting or insightful.
If the point is "potshots" why not ask or suggest more developed opinions instead of potshotting the potshots? Why not clearly note that "potshot comments on any topic are not optimal" instead of making this seem to be about hosting or what is insightful?
A down vote is not meaningful feedback and clarity tends to work better.
It's downright intolerant to downvote (as opposed to not upvote) a comment which simply advocates values in line with FOSS. I even said I would like to use this program.
I can't speak for others, but I downvote to recommend other readers that the post is not worth reading. Not because I disagree with it, but because it's off topic in a way or another.
If TFA is about a tool, I tend to downvote comments that don't talk about the merits of tool but rather about the hosting website, the language it's written in, whether or not it "smells AI", English mistakes in the readme, and so on.
On the other side, if I reply to a comment I always upvote it, even if my reply is to refute it. In fact if I felt the need to add anything to it, it was by definition worth dealing with it!
Some people like to claim that using a pretty esoteric language with lots of weird footguns, lack of basic features and data types, and spawning subprocesses for everything, is somehow keeping it simple.
Weird footguns don't matter if you stick to using shell for control flow, composition, and interpolation, and don't use all the weird things you have to look up every time. It's also very easy to do something in the commandline then just
tail -n 8 $HISTFILE > script.sh
and very little to no editing is needed to make that useful. Shell is not a programming language, it's an interface to the OS, and thinking about it like a programming language is just asking for frustration.
Shell exists to give users a way to run programs. It was the user interface for UNIX, C was the programming interface. Yes, it's technically a programming language by any reasonable definition, but it's not meant to be used in the same way at all so that's not helpful.
I honestly think that's the contrary: it's the laziest choice possible when you want something to work immediately without thinking too much about it. Till like 7 years ago I made literally every script to do "personal" stuff in bash, because I wasn't quite good with any programming language and bash... was just there in my Linux machine, and I was already familiar with it because I was a long time Linux user.
Sometimes you end up committing it on github and people start issuing feature requests, and at the beginning you are just happy that your work fits the need of other people and you don't want to rewrite it from scratch with a better programming language and end up over-scripting it.
That's basically the story of a little program I made years ago. Now I don't log in on github anymore because I'm afraid people is still requesting new features...
It probably started as a helper script and grew from there. The script seems quite focused and doesn't grow, so a rewrite might not be warranted.
It also has no other dependency, which is also good. I have written helper script to run coding agents in a container. And you guessed it, it's in bash. For the reasons I just wrote down. Should it have to grow I would rewrite it, but not currently.
Known system dependency that's (almost) always on the system you're on.
I remember somebody once telling me that they had learned vi because "it was always installed". Well, no, technically, the only editor you can be sure is there is ed. So, you know, learn that. I was surprised that they actually did.
Bash is syntactically not perfect, I agree. However it's a well known, mature, stable environment. LLMs can write it well if you need them to. If it was perfect, we'd never have had Perl, and as a result we'd never have had Ruby, Python and other scripting languages.
But I like it's a tool that doesn't require me to go reach for a package manager and some build tools I don't always have on every system.
I’ve been down this path (it was a script for scraping and extracting text). You write your text utility in bash. It works. Then you need a regex so you use sed.
Then you wonder why it doesn’t work in your other environment. Then you find that GNU vs BSD sed have different syntax.
Better to start with Python once you’re doing more than coordinating well known other tools.
I'd presume it's quite common with NixOS. At least I don't have python linked to my environment. It might be different would I use the REPL, but I do not, so for me python is a program (or script) dependency, not something I need to carry around. It's actually quite common for many setup scripts to fail when python is not installed, but not all of them list python as a dependency either.
To be fair, qualifying bash as on (almost) every system and then poo-pooing vi as being also on (almost) every system seems odd. Had you said sh instead of bash the analogy would have worked better.
True, I'll take that. I haven't been on a machine without bash in ~25 years though, but I have been on machines without vi. But yeah, from a "what can I expect from a POSIX-like environment bare-bones minimum install" perspective, you're right.
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'm sure that there are still Python 2 codebases there running an unsupported interpreter, but for most people that has been at least 5-10 years ago. Also, the Python project learned a lot from the messy transition, that I think it's unlikely to happen again.
Because a shell is an ergonomic programming language. If you compile a binary then you're implementing another programming language interpreter.
AFAIK the Go jupyter kernel does something like this but it sequentially links previous compilation results to the current cell. Memory use is probably not great for a shell care though (since each linked Go library is a whole separate Go runtime).
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
Would be interested if OP had wrote, AI built me my own blog engine. Instead of saying "I built". If person wrote 90% of code and used AI for only 10% that's only for refactoring or commenting or optimizing then it won't be wrong to say "I built". But when 90% is written by AI and user just makes minor edits its not ethical.
An on the contrary AI has itself been written by other humans and Its been trained over millions of code/work written by other humans. So essentially when AI writes some code, its those humans who were writing. If we can't credit all those humans, atleast make your statement rightfullt
Who cares seriously? Its obvious in the repo that claude code is a contributor.
I dont have time to play these ego games and prefix everything with "AI wrote 90% of this codebase" instead "I built". I just thought this would be useful to share. If you dont think this is useful then dont use it, it's that simple...
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.
Its very niche. This is a static site generator so you could run something a lot heavier and then rsync the output to the server. Even lighter on the server than running bash there.
It is also limited so you might have to add other things. The README suggests using markdown.pl for markdown support.
Bash gets way more hate than it deserves, in ways that are like "this kitchen knife is terrible for cutting down trees!"
Like, yeah, why are you mad? And also, if a dude wants to cut down a tree with a kitchen knife that's actually pretty impressive.
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.
mine is:
find . -name '*.md' -type f -exec sh -c '
' sh {} +The only issue is pandoc is a pretty heavy dep. A fantastic tool, but a very heavy one.
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
A single 1200 line bash script to create blogs.
I love bash for quick hacks. I abhor it for things like this.
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.
Why? If it works and it gives you the features you require that where's the issue? If all 1200 lines of code are utilised and provides you with the blog stack then that's pretty efficient.
How is this any different of someone including multiple python modules to create the same stack for which probably amount to more lines of code if you were to copy and paste in to a single document.
It's like react, a stack with stupid amount of LoC only for the developer to use 1% of and the rest sits unused and bugs the site.
You can source bash scripts so if it's lines of code, break them in to chunks.
> If it works
It often doesn't work.
> How is this any different of someone including multiple python modules to create the same stack for which probably amount to more lines of code if you were to copy and paste in to a single document.
There's no problem with 1200 lines of code. The problem is 1200 lines of Bash. The difference is that Bash is incredibly awkward and error prone compared to almost every other language out there.
> It often doesn't work.
I suppose my main bash script on BSD, ~400 lines for backup, compilation and other admin tasks including a portable static text/plain web server have never failed me but never tested them interchangeably, so, prone some truth to failure.
I am not disagreeing of course and I would agree, Bash is designed for the system functions and that this is niche. However if it's all you got, eh, go for it.
Systems admin for 15 years and have handled some very hosed systems. Maybe the python binary got hosed and you were really desperate to share your lasagna recipe with your mother and the internet, it does have a purpose. Not ideal, sure.
> However if it's all you got, eh, go for it.
Mercifully, it isn't all we've got!
Note that I didn't say anything about "If it works and gives you the features you require", you added that.
If you remove that from your reply you're on your way to understanding why I don't like an absolute unit of a bash script.
I did yes, got ahead of myself there. I get it.
I'd rather a single unruly page of code to do the whole thing rather than multiple modules that do multiple things half-efficiently that require multiple thought to uncover.
For what it's worth, I bet this opinion literally doesn't matter anymore.
Write your thing in whatever you want, AI it into another language, done.
Glorious.
I used a similar system back in the day, nanoblogger:
https://nanoblogger.sourceforge.net/
Awesome! I’m the author and I created that project as a way to teach myself Bash at the time. I called it NanoBlogger because it was inspired by MicroBlogger, yet another Bash blog.
I still have fond memories of the open source community’s warm welcome and amazing contributions to the project.
Ah, sourceforge!
I've been using shell to blog for a while.
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)
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 the wrong choice for truly complex software but I still find it really hard to pick anything else for the sort of tasks where I'm mostly manipulating text files and shelling out to other tools. My general instinct for when its time to reimplement a script in Python or similar is when I've got a ton of conditionals or function calls, at that point its also time to start writing unit tests.
shellcheck is a huge help in the middle sized shell script space and will regularly shout at me about missing all the random gotchas like not quoting file paths.
> Nice idea but I don't understand why people write bash scripts more than a few lines long.
From a pragmatic perspective I agree. But I think you’re missing the point here. A lot of the most entertaining, and dare I say inspiring content, found on Hacker News is about exactly things like this. Things that seem silly, but are also very intentionally pushing the boundaries to the extreme/absurd.
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.
if you like bash web apps, you'll love https://github.com/cablehead/http-sh
I like it .. its an interesting take ...any plans of adding a on page editor ?
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.
> This is a good example of a program I would like to use if it was distributed in the standard repo of my OS
So why are you waiting? Be the change you seek. Simply become a maintainer of a distro, and publish the package there. Repeat for all the major distros.
The response I was expecting and deserved. That still leaves the residual whine about Github.
What? That's how open source works
Package management in the distro is also how FOSS works?
Things that end up in curated package repositories like those of the various significant distros, have usually spent time growing on the random developer's own page (most common in the past) or said random developer's account on a forge like github (most common in more modern times).
Standard repos might be were many discover things, but those things don't normally get there until they've build a following, so the random developers page is the more significant vector overall.
Fair enough. It would be nice if more developers would at least consider using the forges that don't belong to an ethically compromised big-tech oligopolist. The options are there.
[dead]
for what we need downvoting and upvoting? I thought: - upvote if you like/agree - downvote if you dont like/disagree Am I wrong?
This reads like parody! In a sane world (and I believe the HN community rules are fairly sane) we should be upvoting things that are interesting, or insightful, or informative, or otherwise tickle our curiosity. Not just because we agree with them! After all, who cares that I agree with something? Everyone has an opinion on everything, opinions in themselves are cheap and uninteresting.
It's not interesting or insightful to take potshots at a project because it's hosted on GitHub.
So one cannot have or express an opinion on hosting as it is a priori and uncontestably lacking in insight and universally uninteresting?
And HNN requires either or both: opinions must be insightful or interesting.
And what is either of those is objective, self-evident, and not even slightly subjective.
Right? How is this not merely a blanket way to assert opinions that are themselves boring and un-insightful ("hosting opinions are forbidden" is the de facto claim)?
Hosting on Github has been an up voted story several HNN times. Yet here its not interesting or insightful.
If the point is "potshots" why not ask or suggest more developed opinions instead of potshotting the potshots? Why not clearly note that "potshot comments on any topic are not optimal" instead of making this seem to be about hosting or what is insightful?
A down vote is not meaningful feedback and clarity tends to work better.
It's downright intolerant to downvote (as opposed to not upvote) a comment which simply advocates values in line with FOSS. I even said I would like to use this program.
You're wrong.
"Users should vote and comment when they run across something they personally find interesting—not for promotion."
https://news.ycombinator.com/newsguidelines.html#:~:text=Use...
I can't speak for others, but I downvote to recommend other readers that the post is not worth reading. Not because I disagree with it, but because it's off topic in a way or another.
If TFA is about a tool, I tend to downvote comments that don't talk about the merits of tool but rather about the hosting website, the language it's written in, whether or not it "smells AI", English mistakes in the readme, and so on.
On the other side, if I reply to a comment I always upvote it, even if my reply is to refute it. In fact if I felt the need to add anything to it, it was by definition worth dealing with it!
See also Shite:
https://github.com/adityaathalye/shite
https://news.ycombinator.com/item?id=34486596
Mmm, good ol’ bash. I like it.
Awful old Bash. I hate it.
Seriously I don't know why you'd do this in Bash. Crazy choice.
Some people like to claim that using a pretty esoteric language with lots of weird footguns, lack of basic features and data types, and spawning subprocesses for everything, is somehow keeping it simple.
I do not understand them.
Weird footguns don't matter if you stick to using shell for control flow, composition, and interpolation, and don't use all the weird things you have to look up every time. It's also very easy to do something in the commandline then just
and very little to no editing is needed to make that useful. Shell is not a programming language, it's an interface to the OS, and thinking about it like a programming language is just asking for frustration.> Shell is not a programming language, it's an interface to the OS, and thinking about it like a programming language is just asking for frustration.
I guess this just isn’t obvious to me. Where do you see the boundary between “interface to the os” and “programming language”?
Shell exists to give users a way to run programs. It was the user interface for UNIX, C was the programming interface. Yes, it's technically a programming language by any reasonable definition, but it's not meant to be used in the same way at all so that's not helpful.
I honestly think that's the contrary: it's the laziest choice possible when you want something to work immediately without thinking too much about it. Till like 7 years ago I made literally every script to do "personal" stuff in bash, because I wasn't quite good with any programming language and bash... was just there in my Linux machine, and I was already familiar with it because I was a long time Linux user. Sometimes you end up committing it on github and people start issuing feature requests, and at the beginning you are just happy that your work fits the need of other people and you don't want to rewrite it from scratch with a better programming language and end up over-scripting it. That's basically the story of a little program I made years ago. Now I don't log in on github anymore because I'm afraid people is still requesting new features...
It probably started as a helper script and grew from there. The script seems quite focused and doesn't grow, so a rewrite might not be warranted.
It also has no other dependency, which is also good. I have written helper script to run coding agents in a container. And you guessed it, it's in bash. For the reasons I just wrote down. Should it have to grow I would rewrite it, but not currently.
Known system dependency that's (almost) always on the system you're on.
I remember somebody once telling me that they had learned vi because "it was always installed". Well, no, technically, the only editor you can be sure is there is ed. So, you know, learn that. I was surprised that they actually did.
Bash is syntactically not perfect, I agree. However it's a well known, mature, stable environment. LLMs can write it well if you need them to. If it was perfect, we'd never have had Perl, and as a result we'd never have had Ruby, Python and other scripting languages.
But I like it's a tool that doesn't require me to go reach for a package manager and some build tools I don't always have on every system.
I’ve been down this path (it was a script for scraping and extracting text). You write your text utility in bash. It works. Then you need a regex so you use sed.
Then you wonder why it doesn’t work in your other environment. Then you find that GNU vs BSD sed have different syntax.
Better to start with Python once you’re doing more than coordinating well known other tools.
Who's updating their blog from a random machine without Python on it, though?
I'd presume it's quite common with NixOS. At least I don't have python linked to my environment. It might be different would I use the REPL, but I do not, so for me python is a program (or script) dependency, not something I need to carry around. It's actually quite common for many setup scripts to fail when python is not installed, but not all of them list python as a dependency either.
It's not python that's the dependency that needs managing. It's pip and the keystone cops it brings along.
To be fair, qualifying bash as on (almost) every system and then poo-pooing vi as being also on (almost) every system seems odd. Had you said sh instead of bash the analogy would have worked better.
True, I'll take that. I haven't been on a machine without bash in ~25 years though, but I have been on machines without vi. But yeah, from a "what can I expect from a POSIX-like environment bare-bones minimum install" perspective, you're right.
> technically... you can be sure there's ed
Unfortunately, ed has been omitted from the default installation of recent debians, at least. I had to install it manually.
WTF?! RIP Debian.
If I wanted an OS without a text editor, I'd use emacs.
Really? I think there's a nice niche for tools like nb that Just Work. Ubiquity is a feature!
https://xwmx.github.io/nb/
...for fun!
Works for me!
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 use Python for that, since I know it will always be on my machine.
Is this what you have in mind?
Yeah but i have Python PTSD from all this Python 2 vs. 3 shit :D
Perl still loves you and will always be there.
And I for one am here for Perl
I'm sure that there are still Python 2 codebases there running an unsupported interpreter, but for most people that has been at least 5-10 years ago. Also, the Python project learned a lot from the messy transition, that I think it's unlikely to happen again.
And then some old debian box comes out of shadow.
I'm sure that ubuntu LTS also extended the life of this disaster + some tool you wanted to use which never upgraded.
GNU Radio took ages
That was almost 20 years ago! We migrated 2 to 3 10 years ago. I'd say I moved on. I doubt there will ever be py4 :)
It's definitely not a system default (unless it's a system I've had access to for more than ten minutes!), but:
I use Janet[0] for this.
[0] https://janet-lang.org
Go has a fast enough compile speed I feel like you could syntactically sugar it to be a command line.
Why would you compile it each time? You would compile the binary once and the use it. This is what Go equivalents of this already do (e.g. Hugo).
Because a shell is an ergonomic programming language. If you compile a binary then you're implementing another programming language interpreter.
AFAIK the Go jupyter kernel does something like this but it sequentially links previous compilation results to the current cell. Memory use is probably not great for a shell care though (since each linked Go library is a whole separate Go runtime).
Yeah but its not scripty enough and has not enough easy stuff build in.
https://www.tcl-lang.org/
Many people have made micro Tcl’s too if you want something even lighter.
It has a built in subst command no need for a template engine!
Nim might be an option. It even has a subset to be used for scripting purposes.
Python already fills this role.
exe.dev does a pretty good job of instantly deployable microVMs
Dude, that's C.
Oooh..reminds me of something similar I did earlier for own blog a few years back: https://github.com/proxygeek/publish/
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
[dead]
I used to do that. Them move to a NodeJS script.
Because bash is maybe worst than C for this task.
Not a bash script, but I built my own small blog generation engine to use with AI agents if anyone is interested https://github.com/trebaud/let-an-agent-build-your-blog
Nobody's interested because everyone is one prompt away from exactly the same thing catered to their specific needs.
Wow that was pretty passive agressive lol, sure you're probably right
I’d argue that was active aggressive, actually.
Would be interested if OP had wrote, AI built me my own blog engine. Instead of saying "I built". If person wrote 90% of code and used AI for only 10% that's only for refactoring or commenting or optimizing then it won't be wrong to say "I built". But when 90% is written by AI and user just makes minor edits its not ethical. An on the contrary AI has itself been written by other humans and Its been trained over millions of code/work written by other humans. So essentially when AI writes some code, its those humans who were writing. If we can't credit all those humans, atleast make your statement rightfullt
Who cares seriously? Its obvious in the repo that claude code is a contributor.
I dont have time to play these ego games and prefix everything with "AI wrote 90% of this codebase" instead "I built". I just thought this would be useful to share. If you dont think this is useful then dont use it, it's that simple...