vishnubob / wait-for-it

Pure bash script to test and wait on the availability of a TCP host and port
MIT License
9.33k stars 2.27k forks source link

POSIX compliant shell #8

Open Vanuan opened 8 years ago

Vanuan commented 8 years ago

Is it possible to make this shell-independent?

/wait-for-it.sh: line 70: syntax error: unexpected "(" (expecting ";;")

This would be particularly useful to run it with alpine, which uses busybox.

Vanuan commented 8 years ago

@iturgeon have you looked into this too?

iturgeon commented 8 years ago

Strange, I don't think my alpine 3.3 container complained about this line.

Update: looking at my build, I added the bash package to get by.

Vanuan commented 8 years ago

Yes, I've added this too as a workaround.

scarlac commented 8 years ago

To be a bit more explicit about the workaround that @iturgeon suggested, I also fixed this issue by replacing sh /code/wait-for-it.sh .... with bash /code/wait-for-it.sh ...

maxcnunes commented 8 years ago

Since this issue is open for while. Let me share a tool I have written in Go with cross platform support and which has the same purpose of this project (even the name is the same) https://github.com/maxcnunes/waitforit.

Vanuan commented 8 years ago

What's great in shell script is that you just add one file to your directory and if you have bash that's it. Since your script is written in go, and go is a part of docker, it can be executed even without a shell, right?

maxcnunes commented 8 years ago

For UNIX systems the approach of this project is really straight forward. But it may start to be a bit complicated to maintain this approach once:

PS: The built binary does not need Go installed in the machine to be able to run. It is a totally self contained executable.

Vanuan commented 8 years ago

I meant you can build it using a Dockerfile, without the need to download anything, right?

Vanuan commented 8 years ago

It would be great if it was shipped with alpine, so that it's even less code to write to start using it.

Vanuan commented 8 years ago

OS support is irrelevant, since bash would be supported in windows and Docker doesn't currently support any other platform except linux (windows 2016 is still not released).

maxcnunes commented 8 years ago

I don't think so you have access to Go from the Dockerfile. Because the Docker running the build on the Dockerfile is already a built binary. Does not have all the Golang support to build a new binary. OS support is relevante if you think it depend on third party tools. For instance bash itself is not available in all images by default. You would still need to install that at least. And as I said before, if it start to include new features such as the http status checking, it may start to depend on other tools as well. Which means, you have to include in your image more things than a single binary.

But if the these points I am bringing up does not concern you and the solution of this project works for you. Please than just use this one. It is a small and straight forward solution. 😄

Vanuan commented 8 years ago

I'm open to new solution. It's just that while it solves one problem (not having to install bash) it adds another (having to build or download a binary)

maxcnunes commented 8 years ago

@Vanuan Just a reminder. If you don't want to your Dockefile be responsible to download the binary. You could also use COPY do add the binary from your file system. Actually even with this tool you would end up with the same "problem": download or copy the script from the file system.

Vanuan commented 8 years ago

Sorry, I never commit binaries to a git repository. With shell scripts I don't hesitate to do it.

It would be great to have it included in alpine repository.

Vanuan commented 8 years ago

@maxcnunes please, don't be defensive, I think your project is great! I'm just sharing my thoughts

maxcnunes commented 8 years ago

I'm not 😄 Just sharing some thoughts as well.

aviau commented 8 years ago

You guys are hijacking this thread, please stop.

dborncamp commented 5 years ago

Has anyone found a workaround for this? I just hit it in a python:3.7.2-alpine3.9 image.

ChadLei commented 5 years ago

im also getting this with a openjdk:8-jre manifold image