Someone beat me to it. When I think of pure bash, I don't really think of invoking anything that isn't a builtin or a grammatical feature of bash. If socat is fair-play, almost anything you can spawn on a shell should count then.
I think I'll just write something similar and wrap Apache with a shell scrip, claim that it's a web server written in bash, post it here and see what reaction I get, just for shits and giggles.
Here: https://github.com/remileduc/sherver/issues/1
that way you can have HTTP/1.1 support even with arbitrary output lengths. I was planning on sending this to the linked repo so the owner doesn't need to use HTTP/1.0.
EDIT: changed link to the github issue I created with inlined utility.
~~Right. "Pure" bash would mean they somehow got sockets working in the scripting language itself, which is not possible unless you're on a system with `/dev/tcp` (which isn't many these days).~~
They reinvented CGI scripts but didn't actually implement CGI. Could have implicitly supported a lot of apps by default. There's some pretty decent CGI libraries for Bash, too.
Personally I use busybox's httpd (which does support CGI) for a small portable web server.
> I didn't want to install and configure Apache or nGinx. In fact, I didn't want any configuration.
If you ignore all of the manual installation instructions and any dev time you took to create this, then sure.
I’m not going to argue that the author should have used something else instead though. It’s a personal project used purely on an internet system of his house. For those kinds it projects “because I could” is as good a reason as any. I just think more authors should be honest and say “I just did it because it seemed fun at the time”
Manual instructions and dev time doesn't necessarily pollute the state of the machine though and are harder to replicate, which is how I would interpret it.
Not having your application packaged up for quick removal strikes me as more polluting. And I don’t really see how an independent solution with almost no documentation and zero configuration management support (eg Ansible) is easier to replicate than a battle tested industry standard with widespread support.
Don’t get me wrong, I have nothing against building things for fun. But the technical arguments made for why this is preferable over an established solution doesn’t stack up.
Just as I would use this (would look into it more first though), the netcat trick mentioned here or python3 -m http.server over ever considering installing Ansible and/or nginx/apache.
If I was rolling my own and concerned about polluting, I’d favour a language like Rust or Go because I then don’t need to install the Python runtime, have random undocumented dependencies for the bash etc.
Or I’d use Docker.
But as said before, there’s no wrong answer here since it’s just a hobby project running on a HTPC.
It achieves multiline block text in bash, which is otherwise a PITA to reason about. It can keep certain scripts cleaner, especially since `cat` is often inlined, without process spawning.
Cat is not a specified built-in but many implementations do build it in to speed up scripts that use it quite heavily.
Other examples include `which`, `time`, `echo`, etc. They're usually promoted to built-ins when it's clear that's the intended command to run, but there are still analogs on the PATH if need-be - I'm not sure exactly how bash would detect a non-standard executable there to know when it's unsafe to promote to a built-in, though.
In fact for me, `cat` always gets inlined, even if I call it with its full path or with `which cat`.
There are cases where the built-in and the actual executable differ - the most prominent case being `time`. The built-in does not have the command line arguments to print out things like pre-empted scheduling (forced context swiches).
$ time --help
--help: command not found
$ /usr/bin/time --help
Usage: /usr/bin/time [-apvV] [-f format] [-o file] [--append] [--verbose]
[--portability] [--format=format] [--output=file] [--version]
[--quiet] [--help] command [arg...]
Something seems off. strace(1) prints the trace to stderr not stdout, so you should need |& not | to catch it with grep. At least, that's how it works here.
Yeah good catch, I forgot it since I didn't copy 1:1 the command line into vim when I formatted it for HN. I use fish + powerline so the command line doesn't copy correctly. In fish, it's `&|`, which would look weird anyway. I just forgot to add the `&` after the `|`.
The output was copied 1:1 though.
The inlining is an implementation detail and I've seen it happen differently across different platforms.
> The inlining is an implementation detail and I've seen it happen differently across different platforms.
Do you have more information on this? I would be interested to read more about it. As far as I was aware (and my knowledge is certainly not exhaustive), the only thing kinda related is as noted in the bash man page:
> The command substitution $(cat file) can be replaced by the equivalent but faster $(< file).
I don't, sorry. I just know it's something some implementations opt-in to (especially drop-in replacements to bash). It's behavior I've observed quite a bit and have leveraged it in some cases to improve the performance of some critical bash scripts over the years. I'd also be interested in some prose about it.
Yep, I'm sure. It's not a guarantee (nor is it specified, to my knowledge) that the inlining happens. You also used a subshell there, which might make a difference.
The original poster is using a subshell. Your example uses echo, which is both a built-in AND an external program.
They are not comparable. I've never seen a shell inline cat, probably because it would make no sense given there are POSIX builtins to do exactly what cat does.
It of course makes sense since `cat` is widely used for the purpose of the original code, just not in a subshell. It's used often to output blocks of text to stdout/err for multiline output, namely --help text.
strace doesn't lie here, and I've seen it substitute cat in trivial cases quite often.
Indeed strace doesn't lie but you have yet to provide an example of a system where what you're saying about cat is true. You've shown a number of examples which do not actually back up the claim you are making, and have not responded to other posters pointing out the flaws in the examples you did provide.
I'm genuinely curious to see an implementation but I suspect you've misunderstood something in the past and your statement was incorrect.
Yes this is indeed simpler, however I noticed in some of the code single quotes were also used [0] so I wanted to use an example that would work for that.
Windows Terminal shows a "visual bell" in the tab bar whenever BEL is emitted (even though I have it set to "audible" in advanced settings of the profile, hmm).
Edit: Uhm, right. I have also silenced all system sounds in Windows.
Why does firefox shows the "chose an application to open this link" when you access the http://localhost link, but shows the content correctly when you access the 127.0.0.1/0.0.0.0 ip-based version?
Browser expects to see some HTTP headers before the content.
Adding HTTP version with response code, content type declaration and empty line dividing headers and content should do the trick:
HTTP/1.1 200
Content-Type: text/plan;
1st line of content
There are many similar options. I think that awhile ago there may have been a list of one liner web servers posted to HN. Either way, I've been using python's for years and it's just muscle memory now.
That's my goto solution for a simple server if I'm testing something locally but it has issues dealing with concurrent requests in its simple form.
For example I ran a simple hello world test service on Kubernetes once using Python's http.server.
Just having 3 Kubernetes health checks happen on regular intervals would routinely cause the server to respond with errors. I think what ends up happening is if you have 2 requests coming in within a short enough period of time one of them will fail. You have to use a more complicated threaded http server if you want a zero dependency solution.
Just an idea, along the lines of a single binary webserver: one may use Fossil SCM [1] to easily spawn a webserver ('fossil server', or even 'fossil ui'), no need for root (port 8080 by default).
The pages could be served as part of a project (all version-controlled), or as documentation pages, or as wiki. Styling is somewhat limited, but could still be done creatively.
Additionally, a static website or even a whole application (PHP or the likes) could be rolled out via /ext, the 'extension' path.
70 comments
[ 4.7 ms ] story [ 144 ms ] threadDefinitely not “pure”.
edit: on top of that, I already found a perl script utility in the repo: https://github.com/remileduc/sherver/blob/master/scripts/uti...
EDIT: changed link to the github issue I created with inlined utility.
I am wrong! See response.
Thanks for correcting me :)
Personally I use busybox's httpd (which does support CGI) for a small portable web server.
If you ignore all of the manual installation instructions and any dev time you took to create this, then sure.
I’m not going to argue that the author should have used something else instead though. It’s a personal project used purely on an internet system of his house. For those kinds it projects “because I could” is as good a reason as any. I just think more authors should be honest and say “I just did it because it seemed fun at the time”
Don’t get me wrong, I have nothing against building things for fun. But the technical arguments made for why this is preferable over an established solution doesn’t stack up.
Just as I would use this (would look into it more first though), the netcat trick mentioned here or python3 -m http.server over ever considering installing Ansible and/or nginx/apache.
Totally different use case though.
Or I’d use Docker.
But as said before, there’s no wrong answer here since it’s just a hobby project running on a HTPC.
Since the title reads "pure bash" however I was expecting to see an implementation using builtin bash features such as /dev/tcp.
Have you considered solving this problem using BASH builtin support for TCP?
``` caddy file-server --browse --listen :80 ```
That would be surprising. How would that work? `cat` is definitely not a bash built-in.
Other examples include `which`, `time`, `echo`, etc. They're usually promoted to built-ins when it's clear that's the intended command to run, but there are still analogs on the PATH if need-be - I'm not sure exactly how bash would detect a non-standard executable there to know when it's unsafe to promote to a built-in, though.
For example with echo:
In fact for me, `cat` always gets inlined, even if I call it with its full path or with `which cat`.There are cases where the built-in and the actual executable differ - the most prominent case being `time`. The built-in does not have the command line arguments to print out things like pre-empted scheduling (forced context swiches).
Also, cat does not appear to be inlined for me:
The output was copied 1:1 though.
The inlining is an implementation detail and I've seen it happen differently across different platforms.
Do you have more information on this? I would be interested to read more about it. As far as I was aware (and my knowledge is certainly not exhaustive), the only thing kinda related is as noted in the bash man page:
> The command substitution $(cat file) can be replaced by the equivalent but faster $(< file).
They are not comparable. I've never seen a shell inline cat, probably because it would make no sense given there are POSIX builtins to do exactly what cat does.
strace doesn't lie here, and I've seen it substitute cat in trivial cases quite often.
I'm genuinely curious to see an implementation but I suspect you've misunderstood something in the past and your statement was incorrect.
Your second strace is misleading, you didn't trace child processes.
There’s no runtime “promotion”. You can read about it all in bash(1).
[0] https://github.com/remileduc/sherver/blob/master/scripts/ind...
https://www.go350.com/posts/finding-a-hacked-server/
Two comments:
- using "ping -a" creates an audible ping so you can find the server if you're by yourself without having to look at the screen.
- No need for cat:
Edit: Uhm, right. I have also silenced all system sounds in Windows.
Why does firefox shows the "chose an application to open this link" when you access the http://localhost link, but shows the content correctly when you access the 127.0.0.1/0.0.0.0 ip-based version?
https://github.com/jneen/balls
Personally, in that case, I'd use:
python3 -m http.server
https://gist.github.com/willurd/5720255
For example I ran a simple hello world test service on Kubernetes once using Python's http.server.
Just having 3 Kubernetes health checks happen on regular intervals would routinely cause the server to respond with errors. I think what ends up happening is if you have 2 requests coming in within a short enough period of time one of them will fail. You have to use a more complicated threaded http server if you want a zero dependency solution.
Also works great (but a bit bulkier sure).
darkttpd: When you need a web server in a hurry.
https://github.com/emikulic/darkhttpd
It can also run on Unix via plan 9 port (p9p) or derivatives.
https://github.com/9front/9front-test/blob/master/rc/bin/rc-...
The pages could be served as part of a project (all version-controlled), or as documentation pages, or as wiki. Styling is somewhat limited, but could still be done creatively.
Additionally, a static website or even a whole application (PHP or the likes) could be rolled out via /ext, the 'extension' path.
[1]: https://www.fossil-scm.org