Why should I bother with POSIX compliant scripting?

[CaffeineAddict]

I have a lengthy script (780 lines) that is a bash script used to deploy firewall rules on my system.
There are recommendations to get rid of bash scripting and instead write scripts that are POSIX compatible, so I should convert my script to run with sh

But why should I bother with that recommendation?
I'm Debian user and bash is the default shell on Debian so my script will work on Debian system no matter what and no matter which release of the distro.

Why should I bother rewriting my script to be POSIX compatible?
I find bash scripting constructs to be easier to write and read and more powerful in terms of syntax used than naked sh script.

Maybe one day I'll consider making my firewall open source and share it on GitHub, in that case my script may not work on non Debian systems,
but I think this is not going to happen anytime soon because I did that mistake of open sourcing my Windows firewall HERE, I didn't achieve anything other than making my setup world wide known for anyone to exploit provided they are able to access my system somehow, e.g. ISP or government could find holes without reporting them to me.

So if I'll be using the script for my self only in private repo that's guaranteed to work Debian why should I bother and listen to recommendations?

Give me 1 sane reason why should I bother?

 

[f33dm3bits]

So if I'll be using the script for my self only in private repo that's guaranteed to work Debian why should I bother and listen to recommendations?

Just do what works for you. I always thought that POSIX complaint applied to shells. So if your script runs in a POSIX compliant shell it will work on any system because every Linux distribution has coreutils installed. I could be wrong about this but I haven't spent a lot of time thinking about this.

These two might be useful the first one applying to shells and the second one is probably answering your question.

What makes a shell "POSIX compliant"?

I am getting quite tired of how Shells on Windows work - and, there aren't that many options. So I have considered just writing my own shell. However, whilst reading some documentation about the sc...

stackoverflow.com

Why should I care about POSIX if I'm writing bash scripts?

Looking for suggestions/edits I can make to this question to get it reopened. A lot of these answers seem objective to me and they are the type of answers I'm looking for. I've read four articles ...

unix.stackexchange.com

 

[dos2unix]

I actually agree with this. Bash is bash, I don't bash cares too much which flavor of Linux it is running on.

...except...

when it does.

I would say the main thing about Posix is compatibility, portability, and maintainability. Having said that, I don't think I'm Posix compatibile most of the time. The biggest problem for me is calling external applications in my bash shell scripts. A lof of them are Posix compatibile. (awk, sed, cut, grep, etc... ). But I also use double square brackets for conditionals a lot (not Posix). I use process substitutions sometimes (not Posix) . The big one for me is arrays (not Posix) ... I use those a lot.

The good thing about Posix is that the standards really never change. This makes it easy to run on HP/UX, AIX, Solaris, BSD, and even MacOS are all Posix compatible.

 

[dos2unix]

I always thought that POSIX complaint applied to shells. So if your script runs in a POSIX compliant shell it will work on any system because every Linux distribution has coreutils installed.

Yeah, you have to include to Posix apps also. A lot are in coreutils, but some aren't.

POSIX - Wikipedia

en.wikipedia.org

1. Shell Utilities:
   • sh (Bourne shell)
   • echo
   • cat
   • cp
   • mv
   • rm
   • ls
   • grep
   • awk
   • sed
   • find
   • xargs
2. Text Processing Utilities:
   • cut
   • paste
   • sort
   • uniq
   • tr
   • wc
3. File Manipulation Utilities:
   • chmod
   • chown
   • touch
   • tar
   • gzip
4. Networking Utilities:
   • ftp
   • telnet
   • rlogin
   • rcp
5. Programming Utilities:
   • make
   • cc (C compiler)
   • lex
   • yacc

 

[f33dm3bits]

Yeah, you have to include to Posix apps also. A lot are in coreutils, but some aren't.

Someone also told if you are writing long scripts or a script that does a lot it's better to use bash internals instead of using installed commands as it makes your script faster.

One reason why I use zsh on my desktop is because it's a POSIX compliant shell.

 

[CaffeineAddict]

Yeah, you have to include to Posix apps also. A lot are in coreutils, but some aren't.

We can use all these commands in bash script just fine, because bash is backward compatible with POSIX?
I mean they're not limited to POSIX scripts.

One reason why I use zsh on my desktop is because it's a POSIX compliant shell.

Are you sure about that, zsh shell is backward compatible with bash, e.g. bash scripts will work in zsh just fine, I didn't know if zsh is POSIX compatible unless you exclude bash constructs.

 

[f33dm3bits]

Are you sure about that, zsh shell is backward compatible with bash, e.g. bash scripts will work in zsh just fine, I didn't know if zsh is POSIX compatible unless you exclude bash constructs.

I remember reading it somewhere, it was a long time ago. But there's this.

Z-Shell Frequently-Asked Questions

1.5: What's the latest version?
Note also that as the shell changes, it may become incompatible with older versions; see the end of question 6.1 for a partial list. Changes of this kind are almost always forced by an awkward or unnecessary feature in the original design (as perceived by current users), or to enhance compatibility with other Bourne shell derivatives, or (mostly in the 3.0 series) to provide POSIX compliance.

Close enough for me as I don't do scripting on my desktop but I prefer to not have to figure out how to do something totally different as is the case with fish shell. Also by setting the shebang to "#!/bin/bash" it will run in bash no matter what shell you have installed.

 

[CaffeineAddict]

Also by setting the shebang to "#!/bin/bash" it will run in bash no matter what shell you have installed.

Exactly, bash shell is IMO superior as long as one doesn't deal with a shell that doesn't speak bash, but most popular shells do speak bash.

 

[JasKinasis]

POSIX compliant shell scripts should run on any POSIX compliant shell, without needing modification.
So it should run on Bash, dash, ash, zsh, korn etc etc.
In a POSIX script, you’d usually used the following shebang:

#!/bin/sh

to use the default shell.

If you’re writing a script that might be used on different machines, running different default shells - if you stick to POSIX, you won’t have to write a different version of the script for each shell. You can just write the one script.

You’d have to ensure you’re using only POSIX compliant syntax/commands/options and NOT use any shell specific extensions to the language. Bash, zsh and others add their own extra extensions/features to the language. These extensions can only be used in that particular shell.

Personally, I write all of my scripts for Bash because Bash is usually installed on everything and I use a lot of Bash specific features/extensions. And use #!/usr/bin/env bash.

 

[CaffeineAddict]

And use #!/usr/bin/env bash

How does this work? loads environment variables? but doesn't bash already load them?

When I run env there is no bash variable but SHELL=/bin/bash
I guess that' equivalent to #!/usr/bin/env /bin/bash? but what's the benefit?

 

[dos2unix]

How does this work? loads environment variables? but doesn't bash already load them?

I think one advantage to doing it the "env" way, is that it finds the bash path ( which isn't always /bin/bash ).
But I have noticed, it can sometimes be slightly slower to execute, I assume because it's searching for bash.

 

[CaffeineAddict]

I think one advantage to doing it the "env" way, is that it finds the bash path ( which isn't always /bin/bash ).
But I have noticed, it can sometimes be slightly slower to execute, I assume because it's searching for bash.

So it's helpful only if bash is not in /bin/bash?
Still don't understand the breakdown of the command /usr/bin/env bash and what exactly it and how it does.

 

[dos2unix]

Still don't understand the breakdown of the command /usr/bin/env bash and what exactly it and how it does.

What does this return?

env | grep -i bash

 

[CaffeineAddict]

env | grep -i bash

Output:
SHELL=/bin/bash

 

[dos2unix]

So for you, it is /bin/bash, bit on some systems it isn't.

 

[f33dm3bits]

Exactly, bash shell is IMO superior as long as one doesn't deal with a shell that doesn't speak bash, but most popular shells do speak bash.

It depends what you use it for. I don't find bash superior to zsh when I am using on a daily basis on my desktop, with zsh I can add plugins for auto-completion, syntax highlighting, etc. I haven't found any information that bash supports such features or plugins.

 

[dos2unix]

I guess that' equivalent to #!/usr/bin/env /bin/bash? but what's the benefit?

There is an error in this. The arg after the env is the name of what you are looking for in your environmental variables.
You shouldn't give it a path.

env bash = correct
env /bin/bash = incorrect

 

[dos2unix]

I haven't found any information that bash supports such features or plugins.

bash already does those things by default. I have noticed some distro do have an auto-complete plugin for bash. I'm not sure why it's separate.

sudo apt install bash-completion

 

[CaffeineAddict]

So for you, it is /bin/bash, bit on some systems it isn't.

I assume you were expecting bash environment variable?

whatis env

env (1) - run a program in a modified environment

Therefore env runs bash which must already be resolved to be run, so the whole run trough env makes no sense to me except to load env variables prior running bash, but bash alone already does that, or not?

It depends what you use it for. I don't find bash superior to zsh when I am using on a daily basis on my desktop, with zsh I can add plugins for auto-completion, syntax highlighting, etc. I haven't found any information that bash supports such features or plugins.

zsh adds plugins for CLI from what I've been reading, the scripting itself, IDK.

bash supports autocomplete with readline package.

 

[dos2unix]

which must already be resolved to be run, so the whole run trough env

I agree it slows things down. But at least it usually finds it.