Allow executable scripts to not have any suffix (.sc or .scala) at all?

[SethTisue]

When you're using Scala as a scripting language, with #!/usr/bin/env scala-cli shebang, it would be nice if I could just have an executable script called foo and not have to name it foo.sc or foo.scala.

For me as the author of the script having the suffix is not so bad, but for those who are using my script, it might be weird and annoying to have to say foo.sc; they would prefer to just run the script as foo and not even care whether it's written in C or Shell or Scala or what have you. To the user it's just some executable thing. Perhaps it's even on their $PATH.

I've been writing scripts for decades now in Perl, Bash, Scala, and assorted other languages and none of those languages have disallowed me from using a bare filename. (I have Scala on that list because until recently I was using sbt's ScriptMain support, which allowed this.)

[romanowski]

Adding it to the Scala CLI will not be that hard (we can detect if shebang command is used and compile any file provided there as input.

The only problem I see are support in Metals and Intellij since by default both tools looks at file extension. @tgodzik how hard would it be to add support for such scripts in Metals?

[SethTisue]

The only problem I see are support in Metals and Intellij

I wouldn't mind if this wasn't available. But perhaps either or both environments have some way of looking at the contents of the first line?

[ckipp01]

The only problem I see are support in Metals and Intellij since by default both tools looks at file extension. @tgodzik how hard would it be to add support for such scripts in Metals?

Support in Metals core wouldn't really be that much of an issue probably, but the tricky part would be everything around it. Depending on the client, the way Metals is triggered can be dependant on filetype, so it may be hard to actually edit this in isolation since Metals may not even be started when you open it in your editor.

[romanowski]

@tgodzik Can we also trigger metals based on the content of the file? e.g. existence of a shebang with scala-cli?

[tgodzik]

This might be possible but it all depends on how VS Code will pick up the file and whether it will send it to Metals server.

[tgodzik]

Just checked and some basic things work, but it might require a bunch of changes in Metals since we require .scala in the path and now we would need to actually read the file. So an effective way to do that would probably be needed.

[vascorsd]

I think this is the same issues that is triggered when trying to embed scala script in just. Since there's no filename to use anywhere and it's an embedded script it triggers an error on scala-cli:

[error]  /tmp/justhXYLBE/test-embed-2: unrecognized source type (expected .scala or .sc extension, or a directory)
error: Recipe `test-embed-2` failed with exit code 1

Other language sripts (bash, python, perl, etc) all seem to work fine.
This was tested on latest scala-cli version:

scala-cli version
Scala CLI version: 0.1.15
Scala version (default): 3.2.0

A sample project where I tried to use it - https://github.com/vascorsd/simple-scala .

After installing just and trying to run just test-embed-2 the above errors triggers.

[Gedochao]

After discussing it offline, there seems to be 2 potential solutions:

1. allowing no-extension inputs as long as they have the shebang line
2. allowing to pass Scala scripts without extension as an option argument, smth like scala-cli --no-extension-script script

About variant 1

• this would create some inconsistencies/potential clashes with the sub-command system
  • for example, when running scala-cli compile, should we run the ./compile file if it exists and contains the shebang line, or should we run the compile sub-command as normal?
  • for this reason, this variant should require the explicit usage of the run sub-command: scala-cli run no-ext-script
• this would be slightly flaky, as now we'd have to check for the shebang line for, at the very least, all non-recognized-extension inputs; this effectively means reading relevant inputs twice (once for checking the shebang and once for processing it as normal)
  • this feels like a minor concern, but listing it nonetheless
• by default, this should only work for explicitly passed files and not for directories (i.e. when passing a directory containing shebang-containing scripts with no extensions, those would be skipped by default)
  • doing it with directory-nested scripts could later be added behind a flag like --check-shebang-in-dirs
• overall, scala-cli clearly wasn't designed with this variant in mind, as it will always be a bit confusing alongside the sub-command system; nonetheless, it's the closest we can go to mimic the other scripting engines like bash, perl, ruby, etc

About variant 2

• this, in turn, would be very easy to implement
• we potentially wouldn't even have to check for the shebang, actually, since we can trust the argument to the option is a valid Scala script (i.e. if the user uses the option, he knows what he's doing)
• this should work for tools like just, although the user would have to find the relevant piece of the documentation to find out how to do it (instead of assuming scala-cli works just like any other scripting engine would).
  • thus, the main downside being, that this solution is different than what's accepted as standard for other scripting engines

Seems like we should decide which is the lesser evil.

[SethTisue]

Either way sounds fine to me. I really only care whether my single file scripts work and I can name them what I want to name them.

[julienrf]

• for example, when running scala-cli compile, should we run the ./compile file if it exists and contains the shebang line, or should we run the compile sub-command as normal?

I don’t think so, if ./compile is executable and has a shebang, then the intent is to run it with ./compile, not with scala-cli compile. The ability to also run it with an explicit scala-cli run compile or scala-cli --run-script compile sounds fine to me, but I really don’t think we need to provide a way to run that script by invoking scala-cli rather than invoking the script itself.

[Jasper-M]

This might be possible but it all depends on how VS Code will pick up the file and whether it will send it to Metals server.

Isn't it sufficient if the user manually selects the "language mode" for the file?

[tgodzik]

This might be possible but it all depends on how VS Code will pick up the file and whether it will send it to Metals server.

Isn't it sufficient if the user manually selects the "language mode" for the file?

It probably should, though not sure how well that will work. We assume in a lot of places that an extension is needed.