Use POSIX sh

[nomicode]

Bash is not portable.

POSIX sh would ensure portability across UNIX-like architectures.

[xymostech]

It's called "bashttpd". Presumably, if you don't have bash, you shouldn't be able to run it.

[nomicode]

Making architectural decisions because of pre-existing nomenclature is a poor way to write software. If the design goal was specific to Bash, then that is something else. But if the design goal was to have a "shell web server" then I recommend that the project switches to POSIX sh for portability.

[ghost]

So, this is a question of the underlying goals of this project. Is it to be a portable shell-based httpd? Or, is it to be a httpd written in bash specifically?

Being totally POSIX sh compliant adds a rather significant restriction on how its written, and I would also argue, the speed at which the project can evolve. There are nice features in bash that make it much easier to write in (array operations, associative arrays, lastpipe, process substitution...etc).

How would you intend on enforcing POSIX sh compliance? I could see this breaking easily in the future unless there are tools to help enforce compliance (set -o posix?). Which version of POSIX are you arguing bashttpd comply to?

Bash is omnipresent enough, and provides a set of useful enough features, to justify its use to me.

[nomicode]

Actually, bash is surprisingly non-standard, and certainly not omnipresent. Across multiple arches, and especially on the server. Unless you're using POSIX sh, you're going to run into problems with people running on Solarix, HP-UX, etc. Many distros allow you to strip down binaries and use things like dash or ash as even smaller replacements for sh.

Portability is hard.

Can you clarify "significant", or is it just a hunch? Ultimately, I guess it depends on the sorts of stuff that this project needs to do. It may be insurmountable, or it may be just a few tweaks here and there. And of course, being POSIX sh compatible means that it will work with bash too. It wouldn't be removing compatibility.

Enforcing POSIX sh is a little hard. Knowing the differences yourself is the best step. But there are tools like checkbashism that can alert you to any obvious problems.

I don't think the version of POSIX is particularly relevant.

[avleen]

I'm neither pro-bash, nor opposed to being completely POSIX compliant. However, if you're keen on seeing it happen: patches welcome :-) I would recommend forking Josh's branch at becd2ba (which I will be merging as soon as I can review it), as that will likely be the future base.

Isn't open source great? :-)

[ghost]

Note, the merging of my pull request will add more bash-specific features. For example, I make use of Herestrings and associative arrays. So, you may consider a merge to be an implicit acceptance of a bash-centric philosophy :-).

nslater wrote:

Actually, bash is surprisingly non-standard, and certainly not omnipresent. Across multiple arches, and especially on the server. Unless you're using POSIX sh, you're going to run into problems with people running on Solarix, HP-UX, etc. Many distros allow you to strip down binaries and use things like dash or ash as even smaller replacements for sh.

Portability is hard.

I agree, portability is difficult to pull off properly. Bash, in my opinion, is a de-facto standard these days. I'll modify my use of 'omnipresent' to mean 'either exists on all platforms, or can be easily built and installed on all platforms'.

Not requiring POSIX compliance allows us freedom to use some very nice bash features, but at the cost of not working out-of-the-box on less-common Unices (Solaris, HP-UX, etc). I think that it is reasonable to expect that those minority of users that want to use bashttpd would have to install bash to get things running.

[jallspaw]

IIRC, this commit does have a very bash-ism conditional: https://github.com/avleen/bashttpd/commit/ac19008f7efcfc458fb2820a35c4375bbc7e1984

IMHO, if it's going to be in bash, then let's not half-ass it; let's milk bash for everything we can, and throw portability to the wind.

In all honesty, I'm starting to think this project has more educational value than anything else. I'm keeping an eye on this for commits that would indicate to me that they'd be a decent Ops Engineer candidate for job at Etsy. Things like:

• logging (Apache Combined Format?)
• /server-status scoreboard-like feature
• all status code support
• init.d/sysconfig/daemontool support, including netcat/socat/xinetd handling
• log to syslog/spread/etc.
• verbose debugging
• rewrite/redirect support via included config files

you know, that sort of thing. also: it's a webserver in bash. I say screw standards other than RFC2616.

[ab]

I go back and forth on this one. Usually what gets me in POSIX sh are the lack of [[ and set -o pipefail. Solaris does ship with bash, fwiw. Are there other major operating systems lacking it? Is HP-UX worth it?

[avleen]

POSIX also tends to be the bare minimum that should work between platforms. There's really no real reason NOT to use the advanced features of bash, given how prevalent it is.

Bash 3 comes with every Linux and OSX (10.4+ has Bash 3 iirc). Solaris has it too now.. what we have left are the bare edge cases like HP-UX and maybe AIX?

On Sun, Sep 16, 2012 at 7:56 PM, Andy Brody notifications@github.comwrote:

I go back and forth on this one. Usually what gets me in POSIX sh are the lack of [[ and set -o pipefail. Solaris does ship with bash, fwiw. Are there other major operating systems lacking it? Is HP-UX worth it?

— Reply to this email directly or view it on GitHubhttps://github.com/avleen/bashttpd/issues/6#issuecomment-8602296.

[nomicode]

@joshcartwright if "omnipresent" is adjusted to mean "either exists on all platforms, or can be easily built and installed on all platforms" then, practically, it is a useless adjective. As @avleen points out, POSIX sh tends to be the common denominator between default shells across architectures and distros. If your shell script is in POSIX sh, you can be almost certain that the user will never have to worry about what shell they use, or have installed.

That's sort of cool, if you ask me.

As a data point, Debian and Ubuntu will not ship a shell script (as part of the packaging) unless it is POSIX sh compatible. I know this from my time as a packager there. I learnt the hard way how many bashisms I was using. Again, they do it because Debian and Ubuntu are designed to work in lots of different places.

As far as dependancies go, bash is hardly the worst. Try depending on SpiderMonkey and OpenSSL (like we do with CouchDB) and you will know the meaning of pain. But it would be cool to eliminate it, if possible.

@ab would set -e allow a workaround for set -o pipefail?

@avleen, stripped down systems likely do not have bash installed. That applies across distros and arches. bash is pretty big. That's why people choose dash or ash, when space is tight, as I mentioned before. (Another thing to think about. Would it be cool if this fit on one of the micro Linux distributions?)

[avleen]

It certainly would be VERY cool! In my mind I'm trying to balance what is a cool and fun project, with the potential actual application of this.

When I wrote the first version I never expected anyone to actually run it, but now it looks like people either already are, or want to! I guess that makes sense :-)

How about this: We don't intend to use a ton of bashisms, right now they're helpful to fast development because most of us are comfortable with them and they get the job done quickly. Let's use them, but with an eye on not going overboard, and trying to be POSIX compatible later. At some point in the mid-future when things settle down or we have more contributors, we can see about either:

1. removing the bashisms, or
2. adding checks so that if you have something that is not-bash, we run POSIX compatible bits of code. The advantage of two code pathways is that the bashisms are probably more performant. The disadvantage would then be code complexity. But given that it's shell and we're not talking about that much code, it might be manageable. Just stick an if..else around each bit that needs two pathways.

How's that?

[ghost]

The middle ground is the least appealing choice to me. Having to maintain sh-compliant/non-compliant codepaths in parallel seems like an awful lot of work, and I see bashttpd easily becoming a tangled mess of complicated if/else everywhere. It's just not worth it.

[nomicode]

I'm inclined to agree.

The project should choose one, and then maximise the choice.

[avleen]

Bash it is :-)