Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Natural command-line arguments handling #603

Closed
martin-ockajak opened this issue Feb 1, 2022 · 2 comments
Closed

Natural command-line arguments handling #603

martin-ockajak opened this issue Feb 1, 2022 · 2 comments
Labels
SIP-46 All the issues related to SIP-46 to turn Scala CLI into the official scala runner command.
Projects

Comments

@martin-ockajak
Copy link

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.

@philwalk
Copy link
Contributor

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

@lwronski lwronski added the SIP-46 All the issues related to SIP-46 to turn Scala CLI into the official scala runner command. label Dec 30, 2022
@Gedochao
Copy link
Contributor

Gedochao commented Jan 5, 2023

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 Gedochao closed this as completed Jan 5, 2023
@Gedochao Gedochao added this to Done in Issue Board Jan 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
SIP-46 All the issues related to SIP-46 to turn Scala CLI into the official scala runner command.
Projects
4 participants