scala-cli icon indicating copy to clipboard operation
scala-cli copied to clipboard

Natural command-line arguments handling

Open martin-ockajak opened this issue 3 years ago • 1 comments

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.

martin-ockajak avatar Feb 01 '22 18:02 martin-ockajak

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())

philwalk avatar Oct 18 '22 16:10 philwalk

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

Gedochao avatar Jan 05 '23 13:01 Gedochao