3 ms·
The relevant point is that all systems running bash should also be POSIX compliant. So, taking some care to avoid bash-only constructs in a shell script can re
by Goladus 9y ago
The relevant point is that all systems running bash should also be POSIX compliant. So, taking some care to avoid bash-only constructs in a shell script can reap substantial gains in portability at fairly minor cost.
- v_lisivka 9y agoWhy I should care about all systems? If targeted systems have bash4.x and GNU tools, why I should write scripts in sh? If you care about all systems, ANSI C is better choice, IMHO.
- Goladus 9y agoIf you're targeting a limited set of systems and can reasonably assume the requirements won't change in the future, obviously use whatever tools you know will be available. I write Bash and Python all the time for those reasons. But it's silly to think that there's nothing in between "complete control over target environment" and "use ANSI C so it can be compiled to any architecture and platform under the Sun." POSIX compliance will cover a lot. Try browsing /usr/bin on any Unix system you'll see plenty of use cases. I just looked at /usr/bin on my laptop and saw that mysqld_safe is a Bourne shell script, for just one example.