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

Script arguments can't start with a dash #479

Closed
DavidPerezIngeniero opened this Issue Sep 29, 2016 · 12 comments

Comments

Projects
None yet
4 participants
@DavidPerezIngeniero

DavidPerezIngeniero commented Sep 29, 2016

I have a script that has these contents:

#!/usr/bin/env amm

@main
def ini(args: String*) = {
     ...
}

My script can't receive arguments that start with a dash, because they are taken as Ammonite arguments, instead of arguments for my script.

If I try to use e.g.

myScript.sc -?

then this is the ouput:

Error: Unknown option -?
ammonite 0.7.6
Usage: ammonite [options] [<file-args>...] [<args>...]

  -p <value> | --predef <value>
        Any commands you want to execute at the start of the REPL session
  --no-default-predef
        Disable the default predef and run Ammonite with the minimal predef possible
  <file-args>...
        The Ammonite script file you want to execute
  -c <value> | --code <value>
        Pass in code to be run immediately in the REPL
  -x | --execute
        Shim for backwards compatibility - will be removed
  <args>...
        Any arguments you want to pass to the Ammonite script file
  -h <file> | --home <file>
        The home directory of the REPL; where it looks for config and caches
  -f <value> | --predef-file <value>
        Lets you load your predef from a custom location
  -y | --continually
        Lets you run a file over and over, useful for benchmarking purposes
since it lets you hook up a profiler to the long-lived process and
see where all the time is being spent.

  -s | --silent
        Make ivy logs go silent instead of printing though failures will still throw exception
  --repl-api
        Lets you run a script with the `repl` object present; this is
normally not available in scripts and only provided in the
interactive REpl
@lihaoyi

This comment has been minimized.

Owner

lihaoyi commented Sep 29, 2016

What if you try myScript.sc -- -?? The -- would tell Ammonite to just forward any subsequent arguments to the script, and not try to parse them itself

In general, I would like a better system to distinguish Ammonite args vs script args, but haven't come up with a good one yet

@DavidPerezIngeniero

This comment has been minimized.

DavidPerezIngeniero commented Sep 29, 2016

My proposal is simple: arguments before the script file belong to Ammonite.
Arguments that come after the script file, belong to the script.

Example:

amm -s myscript.sc arg1 arg2 --arg3
  • -s belongs to amm.
  • arg1, arg2, --arg3 belong to myscript.

Do you like the idea?

In this way, there is no need to use --.

@DavidPerezIngeniero

This comment has been minimized.

DavidPerezIngeniero commented Sep 29, 2016

In addition, my script cannot receive arguments that begin with double slash, even when using --.

Example:

amm myscript.sc -- --mylongoption
@lihaoyi

This comment has been minimized.

Owner

lihaoyi commented Oct 4, 2016

Having "pre-file" args be passed to the runtime, and "post-file" args be passed to the script seems like a good compromise to me.

This would require some rewriting of the main method: I don't think the scopts library we're using supports this, and trying to identify the script is probably harder than trying to identify the -- that we're doing now. Overall shouldn't be too much work and if someone wants to implement it (e.g. hint hint @DavidPerezIngeniero) I'll happily merge it

@DavidPerezIngeniero

This comment has been minimized.

DavidPerezIngeniero commented Oct 5, 2016

OK. I'll try to, when I have time.

@DavidPerezIngeniero

This comment has been minimized.

DavidPerezIngeniero commented Oct 6, 2016

Any hint please of the related source files to modify?

@DavidPerezIngeniero

This comment has been minimized.

@lihaoyi

This comment has been minimized.

Owner

lihaoyi commented Oct 6, 2016

yep that's the place

@jatcwang

This comment has been minimized.

jatcwang commented Dec 31, 2016

Hey @lihaoyi,

I've been trying to write 'standalone' scripts with ammonite, such that I can write an arbitrary program without the user needing to know that it's ammonite running it.

Currently ammonite will always try to parse everything after --, but there are no option to disable that. This means this will blow up with an exception

amm myscript.scala -- --hello

because ammonite's argument parser is expecting another string after --hello (keyword args) . Therefore we should add an option to disable ammonite's command line parsing

What do you think? I've started on this and planning to name the flag -n (--no-arg-parsing)

@hubertp

This comment has been minimized.

hubertp commented Apr 26, 2017

@lihaoyi Any chance this PR could be reviewed, or anything along the lines could be implemented? I had a quick look at the the commits that @jtcwang did (https://github.com/hubertp/Ammonite/tree/issue/479) and fixed some simple failing tests. I'm happy to clean it up more if there is a will, because I need that feature.

@lihaoyi

This comment has been minimized.

Owner

lihaoyi commented May 19, 2017

Fixed in c605d86#diff-d624941e18d4c528c725d4c3c0bd0517R1089

This lets @main methods with varargs properly slurp in everything, allowing you to then use your own custom argument parser. The only caveat is you cannot use -- in your own argument list, since that is reserved to separate Ammonite's arguments from your script's arguments.

Please take a look at the changelog entry which describes this and let me know if this satisfies your requirements

@lihaoyi lihaoyi closed this May 19, 2017

@lihaoyi

This comment has been minimized.

Owner

lihaoyi commented May 21, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment