Rename script to wait-for-it.bash about wait-for-it

[kolomenkin]

sounds reasonable except I never met .bash scripts before. All bash scripts were had .sh extension

[deiga]

@kolomenkin It is very common to see .zsh or .fish scripts everywhere. Using .bash for script only supporting BASH makes perfect sense. The only time I would be fine with a script which has a bash shebang, but an .sh extensions is when the script is POSIX compliant but wants to run on bash

[garethrandall]

Genuine question: Is this problem solved by the fact that the first line of the script is:
#!/usr/bin/env bash
since this means the system will either find bash or fail immediately (not half-way through the script)? I'm not sure what the POSIX view is on this.

[robertp-indeed]

The shebang only happens if the script is marked executable and executed like ./wait-for-it.sh. If you explicitly run sh wait-for-it.sh on a system where sh is posix sh (or behaves like it), it fails partway through.

Now, one obvious solution is "ok so don't do that" but the convention is that if it's named .sh, it should be runnable with .sh.

This is, of course, incredibly minor.

[lesinigo]

And this is so much more confusing given that the typical usage of this script will be in docker containers and many of them start out based on Alpine Linux which does have ash as preinstalled shell and it is expected to be fully compatibile with POSIX sh but then wait-for-it.sh fails because it's actually a Bash-only script.

[atkrad]

Another solution, use a tool Wait4X that has binary version. 😃

[deiga]

Another solution, use a tool Wait4X that has binary version. 😃

Please stop spamming the issues here. You posted the same comment multiple times now.

[atkrad]

Another solution, use a tool Wait4X that has binary version. smiley

Please stop spamming the issues here. You posted the same comment multiple times now.

I just mentioned a solution. Using a binary tool is a solution, so it doesn't matter if you run on which environment. 😉