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.<p>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.<p>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.<p>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.
mine is:<p>find . -name '*.md' -type f -exec sh -c '<p><pre><code> for file do
out="docs/${file#./}"
out="${out%.md}.html"
mkdir -p "$(dirname "$out")"
pandoc --quiet --template template.html "$file" -o "$out"
done </code></pre>
' sh {} +
A single <i>1200 line</i> bash script to create blogs.<p>I love bash for quick hacks. I abhor it for things like this.
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.<p>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.<p>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.<p>You can source bash scripts so if it's lines of code, break them in to chunks.
Note that I didn't say anything about "If it works and gives you the features you require", you added that.<p>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.
> If it works<p>It often <i>doesn't</i> work.<p>> 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.<p>There's no problem with 1200 lines of code. The problem is 1200 lines of <i>Bash</i>. The difference is that Bash is <i>incredibly</i> awkward and error prone compared to almost every other language out there.
> It often doesn't work.<p>I supposez my bash scripts 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 in Linux, so, prone to failure.<p>I am not disagreeing of course and I would agree, Bash is designed for the odd system function 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.<p>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.
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.
Not a bash script, but I built my own small blog generation engine to use with AI agents if anyone is interested <a href="https://github.com/trebaud/let-an-agent-build-your-blog" rel="nofollow">https://github.com/trebaud/let-an-agent-build-your-blog</a>
Mmm, good ol’ bash. I like it.
Glorious.<p>I used a similar system back in the day, nanoblogger:<p><a href="https://nanoblogger.sourceforge.net/" rel="nofollow">https://nanoblogger.sourceforge.net/</a>
Oooh..reminds me of something similar I did earlier for own blog a few years back: <a href="https://github.com/proxygeek/publish/" rel="nofollow">https://github.com/proxygeek/publish/</a><p>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
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.<p><i>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.</i>
> This is a good example of a program I would like to use if it was distributed in the standard repo of my OS<p>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.
What?
That's how open source works
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 <i>interesting</i>, or <i>insightful</i>, or <i>informative</i>, or otherwise tickle our <i>curiosity</i>. 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.
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.<p>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.<p>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!
You're wrong.<p><i>"Users should vote and comment when they run across something they personally find interesting—not for promotion."</i><p><a href="https://news.ycombinator.com/newsguidelines.html#:~:text=Users%20should%20vote,not%20for%20promotion.">https://news.ycombinator.com/newsguidelines.html#:~:text=Use...</a>
Its time to invent something lightweight and good which runtime is so small that it becomes a system default.<p>like a microvm with normal language features. Something you can and want to actually attach a debugger onto it. Something independent of architecture too.<p>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.<p>Is this what you have in mind?
It's definitely not a system default (unless it's a system I've had access to for more than ten minutes!), but:<p>I use Janet[0] for this.<p>[0] <a href="https://janet-lang.org" rel="nofollow">https://janet-lang.org</a>
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
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).
Yeah but its not scripty enough and has not enough easy stuff build in.
Nice idea but I don't understand why people write bash scripts more than a few lines long.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.
[dead]
I used to do that.
Them move to a NodeJS script.<p>Because bash is maybe worst than C for this task.