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

Research how other tools handle scripts in the top-level command #154

Open
epage opened this issue Apr 19, 2023 · 6 comments
Open

Research how other tools handle scripts in the top-level command #154

epage opened this issue Apr 19, 2023 · 6 comments

Comments

@epage
Copy link
Owner

epage commented Apr 19, 2023

Say we allow cargo in the #!, what inspiration can we take?

@epage
Copy link
Owner Author

epage commented Apr 19, 2023

dub: https://github.com/dlang/dub/blob/master/source/dub/commandline.d#L374,L432

  • Checks for - in the subcommand
  • Checks if subcommand ends with .d
  • Checks if subcommand exists
  • Check if <subcommand >.d exists (making the extension optional)

Key points

  • Specifying the extension when calling cargo is optional
  • Gives higher precedence to scripts than commands dub run could execute a script called run.d which would get cyclical)

Implementation note: dub just invokes argv[0] run ... to execute the script

@epage
Copy link
Owner Author

epage commented Apr 19, 2023

Did a first pass with Groovy but the code base was too enterprise-y for me to find: https://github.com/apache/groovy/

@epage
Copy link
Owner Author

epage commented Apr 19, 2023

If I'm understanding stack correctly, they fallback to running the subcommand as a script if the subcommand is not recognized.

See https://github.com/commercialhaskell/stack/blob/master/src/main/Stack/CLI.hs#L111,L117

@epage
Copy link
Owner Author

epage commented Apr 19, 2023

Didn't quite find it for elixir but my guess is its in or around https://github.com/elixir-lang/elixir/blob/59bf2247b4e0b9821ed5d56f91bc51bb2a7a5747/lib/elixir/lib/kernel/cli.ex

@ijackson
Copy link

(Hi. I came here via TWIR and the blog. I hope this is the right place to put this.)

I think the right answer is to require an option to say "this is a script invocation". That makes things unambiguous.

Prior art:

  • To write a script for jq, use the -f/--from-file option. (#!/usr/bin/jq -f) The default is to treat the argument as jq filter text (ie, source code in the jq language, rather than a filename). awk has similar behaviour.
  • To run a file containing Emacs Lisp as a script, use emacs --script. So #!/usr/bin/emacs -script. (The default behaviour is of course to run emacs as an interactive text editor and treat the argument as a file to edit.)
  • Debian's debian/rules is a Makefile. make's default behaviour is to treat the arguments as targets and look for a Makefile in the cwd (which is analogous to cargo's default behaviour). So, debian/rules starts #! /usr/bin/make -f.
  • To run a file containing a PostgreSQL script, use psql -f, since the arguments are the database name etc.
  • If you want to write a #! script for execution by gdb, you must write #!/usr/bin/gdb -x or similar. (By default the argument is the program to debug.)

Conflating the cargo subcommand namespace with the cargo script namespace is highly undesriable and I bet it would cause trouble. I think this should be sorted out before the feature is stabilised.

The precise option doesn't matter very much, but there should be a one-letter alias since #! lines sometimes have annoying length limits.

@epage
Copy link
Owner Author

epage commented May 15, 2024

Note that this was linked to as past research and this Issue has no bearing on the feature at this time. All development has shifted to RFCs and the Cargo repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants