unixStartScript.txt

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Fix whitespace error in gradlew unix start script (#13293)

Signed-off-by: Frieder Bluemle <frieder.bluemle@gmail.com>

Support Java modules in Java application start scripts

  1. … 15 more files in changeset.
Support Java modules in Java application start scripts

  1. … 15 more files in changeset.
Support Java modules in Java application start scripts

  1. … 15 more files in changeset.
Support Java modules in Java application start scripts

  1. … 16 more files in changeset.
Use HTTPS for links to Apache license in wrapper scripts

Using HTTP when HTTPS is available is generally discouraged. Moreover,

builds of projects using the io.spring.nohttp plugin in its default

configuration now fail.

  1. … 1 more file in changeset.
Merge branch 'rv/issues/2903' of https://github.com/robinverduijn/gradle into sg/merges/pr-2904

  1. … 1 more file in changeset.
Merge branch 'fix-msys-script' of https://github.com/zemian/gradle into sg/merges/pr-8679

Use https in start script template

  1. … 1 more file in changeset.
Fix start script to run in MingW shell properly #2

We should compare string expression with -op explicitly.

Signed-off-by: Zemian Deng <zemiandeng@gmail.com>

Fix start script to run in MingW shell properly

This fix will allow classpath conversion from Unix to Windows under

CYGWIN or MINGW platform.

Signed-off-by: Zemian Deng <zemiandeng@gmail.com>

Clarify licensing in connection with the Application Plugin

This adds ASL 2.0 to the application start scripts (Unix and Windows) and also

clarifies that the plugin does not affect what license you can use for an

application that's packaged with them.

Resolves issue #8151.

  1. … 2 more files in changeset.
OSX: don't try to infer Finder invocation

== DETAILS

When an application packaged by Gradle is executed from a user's

home directory, the working directory is unexpectedly changed to the

script directory.

One consequence of this is that relative paths given on the command line

will fail to resolve. Other consequences would vary from one app to the next.

To the best of my knowledge, there's no way to reliably distinguish between

a terminal invocation and a Finder invocation:

- simply assuming "pwd==$HOME -> Finder" is too broad and caused #5978

- "pwd==$HOME and $0 is absolute path" has the same risk of false-positive,

except now the root cause is even harder to spot

- environment variables are exactly the same, terminal vs Finder

If there's actually a compelling use-case for being able to execute

scripts via Finder, my recommendation is to build a proper Mac OSX

Application bundle (`project_name.app`).

Signed-off-by: Nathan Strong <nstrong@tripwire.com>

OSX: don't try to infer Finder invocation

== DETAILS

When an application packaged by Gradle is executed from a user's

home directory, the working directory is unexpectedly changed to the

script directory.

One consequence of this is that relative paths given on the command line

will fail to resolve. Other consequences would vary from one app to the next.

To the best of my knowledge, there's no way to reliably distinguish between

a terminal invocation and a Finder invocation:

- simply assuming "pwd==$HOME -> Finder" is too broad and caused #5978

- "pwd==$HOME and $0 is absolute path" has the same risk of false-positive,

except now the root cause is even harder to spot

- environment variables are exactly the same, terminal vs Finder

If there's actually a compelling use-case for being able to execute

scripts via Finder, my recommendation is to build a proper Mac OSX

Application bundle (`project_name.app`).

Signed-off-by: Nathan Strong <nstrong@tripwire.com>

Fix `gradlew` execution for non-standard systems

On older Solaris versions and other systems where `/bin/sh` is not

a POSIX-compliant shell, the shell syntax used by the wrapper

script fails on certain constructs.

Fix those cases where the wrapper script was doing some things not

supported on the older non-POSIX shells: using backticks instead

of `$()`, changing the syntax of the `case` statement, and using

`expr` instead of arithmetic expansion.

Resolves: #2903

  1. … 1 more file in changeset.
Fix `gradlew` execution for non-standard systems

On older Solaris versions and other systems where `/bin/sh` is not

a POSIX-compliant shell, the shell syntax used by the wrapper

script fails on certain constructs.

Fix those cases where the wrapper script was doing some things not

supported on the older non-POSIX shells: using backticks instead

of `$()`, changing the syntax of the `case` statement, and using

`expr` instead of arithmetic expansion.

Resolves: #2903

  1. … 1 more file in changeset.
Fix `gradlew` execution for non-standard systems

On older Solaris versions and other systems where `/bin/sh` is not

a POSIX-compliant shell, the shell syntax used by the wrapper

script fails on certain constructs.

Fix those cases where the wrapper script was doing some things not

supported on the older non-POSIX shells: using backticks instead

of `$()`, changing the syntax of the `case` statement, and using

`expr` instead of arithmetic expansion.

Resolves: #2903

  1. … 1 more file in changeset.
Remove space between parenthesis which is interpreted by `zsh`

  1. … 1 more file in changeset.
Do not escape JVM options when reading them from environment variables

This changes the interpretation of line breaks. This corresponds to how

we accessed them in Gradle 3.1 and earlier, which was:

`eval splitJvmOpts $DEFAULT_JVM_OPTS $JAVA_OPTS $GRADLE_OPTS`

  1. … 2 more files in changeset.
Do not escape JVM options when reading them from environment variables

This changes the interpretation of line breaks. This corresponds to how

we accessed them in Gradle 3.1 and earlier, which was:

`eval splitJvmOpts $DEFAULT_JVM_OPTS $JAVA_OPTS $GRADLE_OPTS`

  1. … 2 more files in changeset.
Allow double quotes to be used inside start script arguments

The new argument handling in start scripts introduced with Gradle 3.2

(#621) uses double quotes (") to escape arguments. This breaks the usage

of double quotes inside of an argument. E.g.: `'-DFOO="bar < baz"'`

This is fixed by checking if either (") or (') is already used and

using the corresponding other character for escaping. The solution is

adopted from: www.etalabs.net/sh_tricks.html (Working with arrays)

Issue: #865

  1. … 5 more files in changeset.
Allow double quotes to be used inside start script arguments

The new argument handling in start scripts introduced with Gradle 3.2

(#621) uses double quotes (") to escape arguments. This breaks the usage

of double quotes inside of an argument. E.g.: `'-DFOO="bar < baz"'`

This is fixed by checking if either (") or (') is already used and

using the corresponding other character for escaping. The solution is

adopted from: www.etalabs.net/sh_tricks.html (Working with arrays)

Issue: #865

  1. … 5 more files in changeset.
Fix optsEnvironmentVar name in unix script template

There was a copy and paste error leading to a `gradlew`-specific part

in the script template.

Use eval only for de-escaping arguments

This restores the original behaviour of using `exec` to call the `java`

command. Still, the use of a custom array is a voided by collecting

all arguments for `java` (including JVM options and Application

arguments) directly into the argument array $@ (`set --`).

  1. … 2 more files in changeset.
Remove unnecessary quotes in unix start script

In particular the additional quotes of the $JAVACMD caused the script

to continue evaluation after the actual Gradle run. In the Gradleception

CI job, where the gradlew script was replaced by a new version of it

during the run, this caused an evaluation syntax error after the

(successful) build.

+review REVIEW-6284

  1. … 2 more files in changeset.
Do quote escaping in unix start scripts the right way around

+review REVIEW-6284

  1. … 2 more files in changeset.
Escape java command in unix start script

The command can contain spaces, as it can contain the path set

as JAVA_HOME. Because the script now uses 'eval' (instead of exec), the

'double escaping' is needed.

+review REVIEW-6284

  1. … 2 more files in changeset.
Fixes for unixStartScript: escape app name (may contain spaces), fixed env var name $JAVA_OPTS, updated test to provide 'sh' instead of 'bash'

+review REVIEW-6235

  1. … 1 more file in changeset.
Unix Start Script: do not escape VM options which are read from properties (and are therefore already escaped strings)

+review REVIEW-6235

  1. … 2 more files in changeset.
Limit ourselves to /bin/sh (#621)

+review REVIEW-6235

  1. … 3 more files in changeset.