Gradlew could be more portable if it didn't require bash


(Dave Syer) #1

The standard gradlew script starts #!/usr/bin/env bash but “bash” is not available on many systems, including a large class of docker containers that people like to use for building Java projects these days (anything based on busybox or alpine). It would be very convenient if someone would rip out the bash-specific bits and make it a plain #!/bin/sh.

Use /bin/sh instead of bash in "startScripts" generated by the "application" plugin
(davidmichaelkarr) #2

Can you even install ANY packages on busybox? I’d always thought it’s too primitive to do anything real with. Alpine, on the other hand, uses “apk” to install packages, and bash apparently installs perfectly fine. It takes a couple of seconds max to install bash in a container. It would be nice if gradlew scripts were “more minimal”, but it seems like you have a reasonable strategy to make Bash available, on Alpine at least.

(Dave Syer) #3

Yeah, but then I have to be in the business of creating my own Docker images, whereas there are some perfectly good “official” images that I would be able to just use, if gradlew supported vanilla sh. The point of those images and distributions is that they are minimal. I don’t really want to mess with them and install additional packages, just to run a shell script.

(davidmichaelkarr) #4

This is a little off-topic here, but I suggest you start to think about changing that strategy. You will rarely find the “perfect image” that has everything you need, and only what you need. It’s very straightforward to start with a base image and write a Dockerfile in a few lines that produces the reusable image that you need. Once you have that cached ideal image, you can reuse it as much as you like.

(Dave Syer) #5

Let me put it a different way then. Why is it a problem to change the wrapper script to make it more portable? The Maven wrapper is a vanilla /bin/sh. Surely we can do the same thing here, and it will have the benefit of making the script more inclusive.

(Luke Daley) #6

Hi Dave,

There’s no problem in doing this, we just need to make the change. Do you happen to know what we’d need to change? That is, do you have any suggestions as to how we go about porting the script to sh?

(Dave Syer) #7

I’m not really a sh ninja, so I’m not sure, but at a quick glance I’d say it might be only the array-handling for JVM_OPTS that uses bash features.

(Lucas Neiva) #8

The array with the arguments is definitely an issue.

There seems to be a workaround in there already, for CYGWIN. I think something similar would work for /bin/sh too.

(Stefan Wolf) #9

There is already a pull request trying to implement this:

It looks like there is a problem with escaping and quoting command line arguments - so if anybody can give a hint that would be great!