Yes
Yes
Yes
my website's backend is made with bash, it calls make for every request and it probably has hundreds of remote arbitrary code execution bugs that will get me pwned someday, it's great
edit: to clarify, it uses a rust program i made to expose the bash scripts as http endpoints, i'm not crazy enough to implement http in bash
it behaves like a static file server, but if a file has the others-execute permission bit set it executes the file instead of reading it
it's surprisingly nice for prototyping since you can just write a cli program and it's automatically available over http too
For my own sanity, I choose to believe you're lying
I pity the hacker who ends up in your system
I designed a chip architecture that runs bash code on silicon.
I reimplemented x86 assembly in purely bash script.
Seek help.
Set -e, please for the love of god, set -e
lord forgive me for I have sinned.
you do realize that you can just use Apache instead of writing your own rust program for this, as this is more or less the CGI standard?
Before nginx was a thing, I worked with a guy who forked apache httpd and wrote this blog in C, like, literally embedded html and css inside the server, so when he made a tpyo or was adding another post he had to recompile the source code. The performance was out of this world.
Does a file lookup really take that long? Id say the trick was to have just plain old html with no bloat and you're golden.
Blog content was stored in memory and it was served with zero-copy to the socket, so yea, it's way faster. It was before times of php-fpm and opcache that we're using now. Back then things were deployed and communicated using tcp sockets (tcp to rails, django or php) or reading from a disk, when the best HDDs were 5600rpm, but rare to find on shared hosting.
The answer is no. The more file is used the longer it sits in kernel filesystem cache. Getting file from cache versus having it in process memory is few function calls away all of which takes few microseconds. Which is negligible in comparison to network latency and other small issues that might be present in the code.
On few of our services we decided to store client configuration in JSON files on purpose instead of running with some sort of database storage. Accessing config is insanely fast and kernel makes sure that file is cached so when reading the file you always get fast and latest version. That service is currently handling around 100k requests a day, but we've had peaks in past that went up to almost a million requests a day.
Besides when it comes to human interaction and web sites you only need to get first contentful paint within one second. Anything above 1.5s will feel sluggish, but below 1s, it feels instant. That gives you on average around 800ms to send data back. Plenty of time unless you have a dependency nightmare and parse everything all the time.
This reminds me of one of my older projects. I wanted to learn more about network communications, so I started working on a simple P2P chat app. It wasn't anything fancy, but I really enjoyed working on it. One challenge I faced was that, at the time, I didn't know how to listen for user input while handling network communication simultaneously. So, after I had managed to get multiple TCP sockets working on one thread, I thought, why not open another socket for HTTP communication? That way, I could incorporate a fancy web UI instead of just a CLI interface.
So, I wrote a simple HTTP server, which, in hindsight, might not have been necessary.
Nothing good old cache can't solve. Compile JS and CSS. Bundle CSS with main HTML file and send it in batches since HTTP2 supports chunkifying your output. HTTP prefers one big stream over multiple smaller anyway. So that guy was only inviting trouble for himself.
What if, get this, we put the bash scripts in yaml. And then put it in kubernetes.
I'm currently trying to relearn all my advanced bash in python.
i already learned how to use my operating system, now you're telling me I have to learn 30 new libraries that do the exact same shit?
no, you'll also have to learns each libraries special quirks on your OS
Just don't call it with #!/bin/sh
. Because that's POSIX shell, not bash.
but effectively it's bash, I think /bin/sh
is a symlink to bash on every system I know of...
Edit: I feel corrected, thanks for the information, all the systems I used, had a symlink to bash. Also it was not intended to recommend using bash functionality when having a shebang !#/bin/sh
. As someone other pointed out, recommendation would be #!/usr/bin/env bash
, or !#/bin/sh
if you know that you're not using bash specific functionality.
No no no no no, do not believe this you will shoot yourself in the foot.
Beginning with DebianSqueeze, Debian uses Dash as the target of the /bin/sh symlink. Dash lacks many of the features one would expect in an interactive shell, making it faster and more memory efficient than Bash.
From DebianSqueeze to DebianBullseye, it was possible to select bash as the target of the /bin/sh symlink (by running dpkg-reconfigure dash). As of DebianBookworm, this is no longer supported.
It is a symlink, but bash will automatically enable posix compliance mode if you use it. So any bash specific features will bomb out unless you explicitly reset it in the script.
Wut that is not even the case for Ubuntu. You're probably thinking of dash
example:
sh -c '[[ true ]] && echo ya' # sh: 1: [[: not found bash -c '[[ true ]] && echo ya' # ya
i thought most unix-like systems had it symlinked to a shell like dash
. it's what i have on my system (void linux), of course not as an interactive shell lol
i use #!/bin/sh
for posix scripts and #!/usr/bin/env bash
for bash scripts. #!/bin/sh
works for posix scripts since even if it's symlinked to bash, bash still supports posix features.
macOS
Debian
Ubuntu
I feel like this with Python these days.
Me when micropython isn't fast enough to give my microcontroller complex real-time responses
You're not at scale unless you're deploying OpenStack to run a WordPress site.
Which is hilarious since PHP scales incredibly well on its own.
Regrettably, it does do that
No I swear, I was gonna do more than that.
Maybe like, a static site as well. And a backup server. Y'know, things you need openstack for.
*looks away guiltily*
All you need are Bash scripts with chroot and cgroups and some ssh access.
Never sed when you can bash.
99% and maybe even 100%
i feel this
The dude on the right is some neckbeard who yells "RTFM" and "i use Arch btw ;)" IRL.
wow
d