Elasticsearch version: 5.2.2
OS version: Any OS that has bash not in /bin like FreeBSD for example.
Description of the problem including expected versus actual behavior:
Starting elasticsearch results in an error about bash not being found:
./bin/elasticsearch: bad interpreter: /bin/bash: no such file or directory
Steps to reproduce:
/bin/elasticsearchA solution would be to replace the shebang #!/bin/bash with #!/usr/bin/env bash. This affects several scripts.
Any OS that has bash not in
/binlike FreeBSD for example.
To be clear about expectations here: we do not support FreeBSD. While that does not automatically exclude #23444 from being considered, it does mean that even if we integrate it we offer no guarantees that future changes will not break this, nor break usage on FreeBSD in general.
A solution would be to replace the shebang
#!/bin/bashwith#!/usr/bin/env bash. This affects several scripts.
It's a solution, but I am not sure if it's the solution that we should make. In some circles, using #!/usr/bin/env bash is a security concern as it picks up the first bash in the path instead of the system installed bash.
Additionally, it only pushes the portability concern back a level to assuming that env is in /usr/bin. For example, on older Red Hat systems, env is not in /usr/bin/ but instead in /bin (they do however to provide a symlink from /usr/bin/env to /bin/env).
And that would be my inclination here: I would suggest that you establish a symlink from /bin/bash to your bash installation in /usr/local/bin/bash.
This also gives us some flexibility in the future if we ever need to change the shebang to #!/bin/bash - to avoid interpreter spoofing (I do not see this need arising, it's only another consideration as we think through this issue); with #!/usr/bin/env bash this is not an option since on Linux-based systems only a single argument can be presented to the shebang interpreter.
Lastly, just one point for future reference: there is no need to open an issue and a pull request. As long as the pull request clearly describes the issue, it will get the attention that it deserves.
Thanks for the detailed answer. I actually never ran into a system where env was not in /usr/bin ;-)
Because of the limitations of env under linux I guess that path and argument issues cannot be circumvented which is sad. However it would be great to mention the fact that bash is assumed to be available under /bin in the readme or docs. Maybe together with the reasons stated here why it cannot be changed.
This would leave the option of symlinking or patching the start scripts manually after installation to the affected users.
However it would be great to mention the fact that
bashis assumed to be available under/binin the readme or docs.
This is a good suggestion. I opened #23464.
Looks good. Shall I close this issue and my pull request?
Looks good. Shall I close this issue and my pull request?
Yes, I think so. Thank you for your understanding. :smile:
Most helpful comment
To be clear about expectations here: we do not support FreeBSD. While that does not automatically exclude #23444 from being considered, it does mean that even if we integrate it we offer no guarantees that future changes will not break this, nor break usage on FreeBSD in general.
It's a solution, but I am not sure if it's the solution that we should make. In some circles, using
#!/usr/bin/env bashis a security concern as it picks up the firstbashin the path instead of the system installedbash.Additionally, it only pushes the portability concern back a level to assuming that
envis in/usr/bin. For example, on older Red Hat systems,envis not in/usr/bin/but instead in/bin(they do however to provide a symlink from/usr/bin/envto/bin/env).And that would be my inclination here: I would suggest that you establish a symlink from
/bin/bashto yourbashinstallation in/usr/local/bin/bash.This also gives us some flexibility in the future if we ever need to change the shebang to
#!/bin/bash -to avoid interpreter spoofing (I do not see this need arising, it's only another consideration as we think through this issue); with#!/usr/bin/env bashthis is not an option since on Linux-based systems only a single argument can be presented to the shebang interpreter.Lastly, just one point for future reference: there is no need to open an issue and a pull request. As long as the pull request clearly describes the issue, it will get the attention that it deserves.