relax requirements for recognizing valid scala hashbang lines - fix for #13670

[philwalk]

This PR changes the current strict requirement that a hashbang line MUST end with "scala" in order to be recognized as a valid scala script.

The problem will only manifested if the script filename extension is neither .scala nor .sc, and the hashbang line has characters following "scala".

For example, if the hashbang line also provides a -classpath argument following "scala", the script name is not recognized as a valid script, and the REPL is entered.

Example:
A valid scala script named finder with these contents:

#!/usr/bin/env scala -classpath "/opt/lib/find.jar"
import foo.bar
def main(args: Array[String]): Unit =
  bar.finder(args)

Rather than executing the script, the current behavior is to enter the REPL.

The proposed fix is to consider a file to be a valid scala script if the first line of the file has these features:

1. the line starts with "#!"
2. the line contains the string "scala"

Although a workaround is to rename the file (e.g., to finder.sc rather than finder), this is restricive, because it prevents scala scripts from from shadowing command line tools written in other languages.

This regression was introduced after scala3-3.0.2.

[BarkingBad]

Looks good to me

[philwalk]

Do we know if this fix will be included in the scala3-3.1.0 release? I'm not surprised that it didn't make it into RC3, although I notice that neither did #13618, which merged 1 week ago.

[BarkingBad]

I guess it will be available from 3.1.1. If you want to set up this runner easily, you can use coursier to install it using cs install scala3 command. The coursier descriptor uses latest.release tag, so it should use the nightlies.

[BarkingBad]

Maybe we could backport it to 3.1.0, but it would require us to backport all the changes to MainGenericRunner since it has changed a lot recently.

[philwalk]

Maybe we could backport it to 3.1.0, but it would require us to backport all the changes to MainGenericRunner since it has changed a lot recently.

My concern is that scripting in scala3-3.1.0-RC3 is largely unusable. My manual testing of more than 500 scripts suggest that between a large percent of them (upt to 25%) are now failing due to one or more of these regressions, compared to scala-3.0.2.

[BarkingBad]

I understand your problem. The 3.1.1-RC1 is scheduled to be released in 3 weeks. I know it's not fulfilling your requests, but backporting or introducing 3.1.0-RC4 would bring much more overhead.

[Kordyjan]

@philwalk to clarify: once we release RC-1 for any version X, all PRs merged after that will end up in version X + 1. This means that anything merged after 7th September will be released in 3.1.1 and first available for testing in 3.1.1-RC1. Rarely, we are doing exceptions and backporting selected PRs to the version that already has a release candidate and then releasing further RCs.

If this issue indeed is a regression introduced between 3.0.2 and 3.1.0-RC1 we can consider backporting this fix. On the other hand, it would require releasing RC4. Moreover, 3.1.1-RC1 is just around the corner so I cannot tell if it is worth it.

@anatoliykmetyuk @smarter WDYT?

[philwalk]

Thanks, I understand your point. I think we should proceed by the normal process.

…

On Mon, Oct 4, 2021, 10:30 Paweł Marks ***@***.***> wrote: @philwalk <https://github.com/philwalk> to clarify: once we release RC-1 for any version X, all PRs merged after that will end up in version X + 1. This means that anything merged after 7th September will be released in 3.1.1 and first available for testing in 3.1.1-RC1. Rarely we are doing exceptions and backporting selected PRs to the version that already has a release candidate and then releasing further RCs. If this issue indeed is a regression introduced between 3.0.2 and 3.1.0-RC1 we can consider backporting this fix. On the other hand, it would require releasing RC4. Moreover, 3.1.1-RC1 is just around the corner so I cannot tell if it is worth it. @anatoliykmetyuk <https://github.com/anatoliykmetyuk> @smarter <https://github.com/smarter> WDYT? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13671 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYGLFUBAKKB7VTNHM5GRHDUFHJDPANCNFSM5FICHVMA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.