scala-cli
scala-cli copied to clipboard
Natural command-line arguments handling
Motivation
For in scripting or prototyping use-cases for which scala-cli was designed, it is very important to allow of use command-line arguments as conveniently as possible.
Early versions of scala-cli are likely the only opportunity to simplify behavior for such fundamental use-cases.
Current state
When scala-cli is invoked without a specific command, application command-line arguments can only follow after a special '--' argument, for example:
scala-cli hello.sc -- world
This seems to be a consequence of scala-cli defaulting to a run command behavior when invoked without a specific command. This behavior seems to require the '--' argument separator to accommodate possible scala-cli options and multiple source inputs/files.
Disadvantages
Although this is an effective solution it breaks the principle of least surprise in the following ways:
- Runs contrary to the quite well established standard used by other 'script-friendly' languages (e.g. Python, Go) where by default no extra '--' argument is needed
- Invoking a 'Scala script' via scala-cli provides less than optional user experience - one must remember the need for '--'
- Creating a self-contained 'Scala script' requires using a specific command in the shebang - one must remember the shebang command instead of just using
#/usr/bin/env scala-cli
Proposed solution
Overview
Trade the convenience of using multiple source inputs for greater convenience of supplying application command-line arguments.
Examples
Default behavior
scala-cli [scala-cli options] <source input> [application arguments]
Enable multiple source inputs option
scala-cli [scala-cli options] --sources <source input> [source input]... -- [application arguments]
Details
This would define the default structure of scala-cli command-line arguments when invoked without a command as follows:
- Scala CLI options come first
- Single source input in the middle (unless specific CLI option enables multiple sources mode)
- Application command-line arguments follow after
This would require two changes when compared to the current behavior:
- scala-cli options must be specified before anything else. This allows distinguishing them from subsequent application arguments and it is a solution commonly used by many other programming language interpreters.
- Default number of expected plain source input (source file) arguments must be 1. A specific command-line option (-s, --sources) can be provided to lift this limitation. Such an option would enable access to the current 'multiple sources' behavior leveraging the '--' argument separator to separate input sources arguments from the application arguments the way it works now.
Implementation alternatives
Alternative 1
- Change the current behavior of the run command as outlined above
- Make the run command a default 'no-command' behavior in case it already isn't
- Make the shebang command to be a mere alias for a run command for backwards compatibility and possibly depreciate it
Alternative 2
- Change the current behavior of the shebang command as outlined above
- Make the shebang command a default 'no-command' behavior instead of the current one
- Leave the run command unaffected for backwards compatibility and convenience
Comments and additional ideas are very welcome.
I just ran into this problem, and I completely agree with the concerns expressed here.
The following script shebang line works in scala-cli version 0.1.16, so perhaps the shebang command fixes this issue?
#!/usr/bin/env -S scala-cli shebang
//> using lib "com.lihaoyi::os-lib::0.8.1"
// Invoke subprocesses
val invoked = os.proc("cat", "/proc/meminfo").call()
printf("%s\n", invoked.out.trim())
I just ran into this problem, and I completely agree with the concerns expressed here. The following script shebang line works in scala-cli version 0.1.16, so perhaps the shebang command fixes this issue?
Yep, the shebang command is the way to go here.
Closing this, as per discussion in #1743 we will not be making shebang the default way to run things with Scala CLI.
Relevant documentation will be delivered in #1740