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

Docopt based option parsing facility for functions and builtins #478

Open
xiaq opened this Issue Dec 26, 2012 · 54 comments

Comments

Projects
None yet
@xiaq
Contributor

xiaq commented Dec 26, 2012

This is a less aggressive version of issue #447. I did attempt an implementation of syntactically significant options (for the interested it's at https://github.com/xiaq/fish-shell/tree/opt-parse), but I held back and decided that it's not a good idea, since the inevitable inconsistency with external commands feels really bad to me.

Still, as pointed out by @cben, the option parsing facility is orthogonal to the parser changes, and I don't want to throw away all the codes I wrote :-), so I opened this new proposal. The basic idea is:

  • Functions and builtins have signatures, which describe the options they accept, constraints on the options (whether they accept arguments or not, and if they do, how many, etc.) and the descriptions for them. With this information completions can be automatically generated, avoiding a lot of duplicate work.

  • Option parsing is done just before a function or builtin is called, so that recognized options (and possibly their arguments) are removed from $argv and appear somewhere else.

    For builtins, a std::map<wcstring, wcstring_list_t> opts is passed in addition to argv (This also reduces the LoC of builtin.cpp drastically. :). For functions, options are put in corresponding environment variables. For boolean options (aka switches), an empty array is created (and can be tested with set -q); for non-boolean options, the specified values are kept.

Some details, summarized from issue #447:

  • The exact syntax for function signatures still needs some thoughts. I originally proposed

    function foo -o h,help,'Display help' -o c:,count:,'Specify a count'
        ...
    end
    

    which has the advantage of not requiring any special syntax, but doesn't look very nice, and makes it clumsy to write long option lists. @ridiculousfish proposed two forms,

      function history
          function --options
              --save,-s: 'Save all changes in history file'
              --clear: 'Delete all history items'
              --search "command": Searches for the given command
          end
          <body of function>
      end
    

    and

      function history
          option 'prefix:' --description 'Match history items that start with the given prefix'
      end
    

    The former visually resembles option specifications in manpages, but calls for some special syntax for the signature specification. The latter has the advantage of not requiring syntax change. I tried implementing the latter, but after the attempt I'm not in favor of it - it breaks the usual "skipped execution" semantics of commands within functions. It can be misleading for option to look like an ordinary builtin but is actually part of the function declaration. @cben additionally proposed that option can be an ordinary builtin, but it will require option to mangle the $argv in the calling frame, which I found not really good a bit later.

  • How option variables should be named need some thoughts too. The rule I proposed was:

    1. If a short option has an long form, it's canonicalized into the long form.
    2. Options are kept in $opt_optname.

    So calling f -a a -b b --long some, supposing -a is equivalent to --arg and -b having no long form, results in $opt_arg, $opt_b and $opt_long assigned a, b and c, respectively.

    @maxfl proposed that we drop the $opt_ prefix for long options. I was originally for this, but after realizing that this makes it impractical to have --status and --version, which are plausible option names since they will shadow the well-known variables $status and $version , I think it's worthwhile to keep the $opt_ prefix in all cases.

@xiaq

This comment has been minimized.

Show comment
Hide comment
@xiaq

xiaq Dec 26, 2012

Contributor

The function signature syntax should also make it possible to specify whether the signature is authoritative - that is, whether unrecognized options should result in an error or kept in $argv.

The distinction between boolean vs. non-boolean options can be part of more general constraints on the number of option arguments: 0 argument = boolean, 1+ argument = non-boolean. Another common use case can be mandating exactly 1 argument, so that you can rely on some option variable $opt_foo to expands into exactly 1 word.

Contributor

xiaq commented Dec 26, 2012

The function signature syntax should also make it possible to specify whether the signature is authoritative - that is, whether unrecognized options should result in an error or kept in $argv.

The distinction between boolean vs. non-boolean options can be part of more general constraints on the number of option arguments: 0 argument = boolean, 1+ argument = non-boolean. Another common use case can be mandating exactly 1 argument, so that you can rely on some option variable $opt_foo to expands into exactly 1 word.

@xiaq

This comment has been minimized.

Show comment
Hide comment
@xiaq

xiaq Dec 26, 2012

Contributor

Attribution: argument number constraint was proposed by @maxfl.

Contributor

xiaq commented Dec 26, 2012

Attribution: argument number constraint was proposed by @maxfl.

@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Dec 26, 2012

Member

For switches, I think you meant to write set -q instead of test -q

Member

ridiculousfish commented Dec 26, 2012

For switches, I think you meant to write set -q instead of test -q

@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Dec 26, 2012

Member

Sounds good to me so far. Complementary goals here:

  1. Make it easier for functions and builtins to parse their options
  2. Make functions more self-documenting
  3. Allow syntax highlighting and tab-completions to leverage the function signature, eliminating the need for a separate completion
  4. Improve the syntax for specifying completions

The last two are the most ambitious, and also imply we should be able to write a function signature for an external command, not just a function.

I thought it would be useful to list the option properties we may want to support. Global properties for an option specification:

  1. Authoritative: whether there may be more options, or this is it
  2. Files only: the non-option arguments are always files
  3. Files never: the non-option arguments are never files (#379)
  4. Old long options: all long options use one dash ('-foo' not '--foo') (maybe this is a per-option thing instead)
  5. (Maybe) All options must be literal: 'count --help'
  6. (Maybe) Options apply to a subcommand: ('git checkout ...')
  7. (Maybe) Supports two dashes to mean "end of options" (maybe we just always assume this is on)
  8. (Maybe) Alias: use the same completions as this other command (#393)
  9. (Maybe) At least one argument is required.

Properties for an individual option:

  1. Description
  2. Long name: '--foo'
  3. Short name: '-f', with the understanding that these may be combined: ('rm -Rf')
  4. (Maybe) Long name with one dash: '-foo' (what fish calls "old style")
  5. Has argument: whether the option takes a parameter
  6. (Maybe) Argument to option is always a file
  7. (Maybe) Parameter uses equals: ('gcc -std=c99')
  8. (Maybe) Option must be literal ('count --help')
  9. Condition: a shell command that must return 0 if the completion is to be used

I struggle to read completions, so hope the syntax will be highly readable, and as close as possible to the actual command usage so it serves as an example.

A lot of scripting languages have libraries for option specification and parsing, often more than one. We should do a survey to see how they handle it and whether they have any good syntax ideas we could use.

Member

ridiculousfish commented Dec 26, 2012

Sounds good to me so far. Complementary goals here:

  1. Make it easier for functions and builtins to parse their options
  2. Make functions more self-documenting
  3. Allow syntax highlighting and tab-completions to leverage the function signature, eliminating the need for a separate completion
  4. Improve the syntax for specifying completions

The last two are the most ambitious, and also imply we should be able to write a function signature for an external command, not just a function.

I thought it would be useful to list the option properties we may want to support. Global properties for an option specification:

  1. Authoritative: whether there may be more options, or this is it
  2. Files only: the non-option arguments are always files
  3. Files never: the non-option arguments are never files (#379)
  4. Old long options: all long options use one dash ('-foo' not '--foo') (maybe this is a per-option thing instead)
  5. (Maybe) All options must be literal: 'count --help'
  6. (Maybe) Options apply to a subcommand: ('git checkout ...')
  7. (Maybe) Supports two dashes to mean "end of options" (maybe we just always assume this is on)
  8. (Maybe) Alias: use the same completions as this other command (#393)
  9. (Maybe) At least one argument is required.

Properties for an individual option:

  1. Description
  2. Long name: '--foo'
  3. Short name: '-f', with the understanding that these may be combined: ('rm -Rf')
  4. (Maybe) Long name with one dash: '-foo' (what fish calls "old style")
  5. Has argument: whether the option takes a parameter
  6. (Maybe) Argument to option is always a file
  7. (Maybe) Parameter uses equals: ('gcc -std=c99')
  8. (Maybe) Option must be literal ('count --help')
  9. Condition: a shell command that must return 0 if the completion is to be used

I struggle to read completions, so hope the syntax will be highly readable, and as close as possible to the actual command usage so it serves as an example.

A lot of scripting languages have libraries for option specification and parsing, often more than one. We should do a survey to see how they handle it and whether they have any good syntax ideas we could use.

@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Dec 26, 2012

Member

Another syntactic possibility is to make the entire signature a single argument to function, but the argument typically spans multiple lines by using quotes:

function history --options '
        -s, --save: Save all changes in history file
        -c, --clear: Delete all history items
    '
    <body of function>
end
Member

ridiculousfish commented Dec 26, 2012

Another syntactic possibility is to make the entire signature a single argument to function, but the argument typically spans multiple lines by using quotes:

function history --options '
        -s, --save: Save all changes in history file
        -c, --clear: Delete all history items
    '
    <body of function>
end
@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Dec 26, 2012

Member

docopt has some nice syntax. None of the existing implementations use a suitable language, but they might appreciate our contributing a C++ implementation.

Member

ridiculousfish commented Dec 26, 2012

docopt has some nice syntax. None of the existing implementations use a suitable language, but they might appreciate our contributing a C++ implementation.

@xiaq

This comment has been minimized.

Show comment
Hide comment
@xiaq

xiaq Dec 27, 2012

Contributor

@ridiculousfish Fixed: s/test -q/set -q/.

Contributor

xiaq commented Dec 27, 2012

@ridiculousfish Fixed: s/test -q/set -q/.

@xiaq

This comment has been minimized.

Show comment
Hide comment
@xiaq

xiaq Dec 27, 2012

Contributor

@ridiculousfish I'm not sure whether docopt did the correct thing - it is very readable, but I also feel it somehow obscures the structure. I would prefer something a bit more formal.

Contributor

xiaq commented Dec 27, 2012

@ridiculousfish I'm not sure whether docopt did the correct thing - it is very readable, but I also feel it somehow obscures the structure. I would prefer something a bit more formal.

@xiaq

This comment has been minimized.

Show comment
Hide comment
@xiaq

xiaq Jan 16, 2013

Contributor

I'm getting back to this after a few weeks. I have taken another closer look at docopt. Many of its ideas like pattern matching, a single dict for all results (be it an option, option argument or positional argument) are inspiring.

I think a docopt-like solution is viable, but there are two problems I see now. First is how it fits within fish syntax. An easy approach to enclose docopt in single quotes, but that makes syntax highlighting clumsy (if possible at all). If we put it unquoted we'll likely have to introduce a special "docopt block" to alter the usual syntax.

Secondly it would need some extensions. Particularly I wish the syntax for writing completions be a superset aof signature syntax, and supporting completions would require at least the following extensions:

  • Specifying a possibly non-exhaustive list of candidates for arguments, like completion. That's the reason why completions exist, and it can be useful in signatures too (generate completion, check the argument against the list if it's exhaustive).
  • Full programmability. We can hardly cover every possible flavor of option specification; in that case, give the completion writer full control.

The following can be optionally supported, but since I covered "full programmability" they are optional :) :

  • Exotic option leaders. e.g. sh(1p) supports +, so that sh +ab is equivalent to sh +a +b.
  • Where the possible choices are limited, unambiguous prefixes resolve to the full word. Linux ip(8) is an example of this: it has subcommands including link, addr, route, etc. and ip route can be abbreviated to any of ip rout, ip rou and ip ro (ip r is actually an accepted abbreviation, but it's not an unambiguous prefix). When the user has written any of these the completion should acts as if ip route is seen.
Contributor

xiaq commented Jan 16, 2013

I'm getting back to this after a few weeks. I have taken another closer look at docopt. Many of its ideas like pattern matching, a single dict for all results (be it an option, option argument or positional argument) are inspiring.

I think a docopt-like solution is viable, but there are two problems I see now. First is how it fits within fish syntax. An easy approach to enclose docopt in single quotes, but that makes syntax highlighting clumsy (if possible at all). If we put it unquoted we'll likely have to introduce a special "docopt block" to alter the usual syntax.

Secondly it would need some extensions. Particularly I wish the syntax for writing completions be a superset aof signature syntax, and supporting completions would require at least the following extensions:

  • Specifying a possibly non-exhaustive list of candidates for arguments, like completion. That's the reason why completions exist, and it can be useful in signatures too (generate completion, check the argument against the list if it's exhaustive).
  • Full programmability. We can hardly cover every possible flavor of option specification; in that case, give the completion writer full control.

The following can be optionally supported, but since I covered "full programmability" they are optional :) :

  • Exotic option leaders. e.g. sh(1p) supports +, so that sh +ab is equivalent to sh +a +b.
  • Where the possible choices are limited, unambiguous prefixes resolve to the full word. Linux ip(8) is an example of this: it has subcommands including link, addr, route, etc. and ip route can be abbreviated to any of ip rout, ip rou and ip ro (ip r is actually an accepted abbreviation, but it's not an unambiguous prefix). When the user has written any of these the completion should acts as if ip route is seen.
@xfix

This comment has been minimized.

Show comment
Hide comment
@xfix

xfix Feb 12, 2014

Member

I'm wondering about this, and decided to experiment with this a little by making self documenting format. Let's assume something simple, like the following command (if somebody needs something really complex (like options starting with +), they shouldn't have used fish parser to parse the command).

cut --as-well-as-possible --budget=5000 -x --name=Me --name=Him something else

This could be represented as this.

function cut --description 'It cuts!'
    options --as-well-as-possible/-a --budget/-b= -x --name=... rest-arguments...
    if test $x
        echo "You provided $rest_arguments."
    end
end

Alternatively, with documentation.

function cut --description 'It cuts!'
    options --as-well-as-possible/-a: 'Does stuff as well as possible.' \
            --short/-s=: 'Does something important for sure.'
end

The syntax provided here is intended to be simple and self documenting (declaration mimics use, like in C). �... means multiple arguments (in CoffeeScript style), / is alternation (the first variable in it would be final variable name (but the , would work as well)), = means that the option takes arguments, : is documentation, and that's about it. Yes, I'm aware of issue with _ and -, but I cannot think of solution for it, sadly.

Just wondering, what is your opinion about my proposal?

Member

xfix commented Feb 12, 2014

I'm wondering about this, and decided to experiment with this a little by making self documenting format. Let's assume something simple, like the following command (if somebody needs something really complex (like options starting with +), they shouldn't have used fish parser to parse the command).

cut --as-well-as-possible --budget=5000 -x --name=Me --name=Him something else

This could be represented as this.

function cut --description 'It cuts!'
    options --as-well-as-possible/-a --budget/-b= -x --name=... rest-arguments...
    if test $x
        echo "You provided $rest_arguments."
    end
end

Alternatively, with documentation.

function cut --description 'It cuts!'
    options --as-well-as-possible/-a: 'Does stuff as well as possible.' \
            --short/-s=: 'Does something important for sure.'
end

The syntax provided here is intended to be simple and self documenting (declaration mimics use, like in C). �... means multiple arguments (in CoffeeScript style), / is alternation (the first variable in it would be final variable name (but the , would work as well)), = means that the option takes arguments, : is documentation, and that's about it. Yes, I'm aware of issue with _ and -, but I cannot think of solution for it, sadly.

Just wondering, what is your opinion about my proposal?

@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Feb 13, 2014

Member

Seems like a good start! The 'options' command is especially interesting.

A key feature is going to be constraints on arguments. We want to be able to express that arguments are only files, never files, only directories (cd), only commands (sudo), or are determined programmatically (git checkout ...). We also want to be able to name arguments, for the automatic parameter-parsing facility within fish functions. I encourage you to consider how these might fit in to the syntax.

Member

ridiculousfish commented Feb 13, 2014

Seems like a good start! The 'options' command is especially interesting.

A key feature is going to be constraints on arguments. We want to be able to express that arguments are only files, never files, only directories (cd), only commands (sudo), or are determined programmatically (git checkout ...). We also want to be able to name arguments, for the automatic parameter-parsing facility within fish functions. I encourage you to consider how these might fit in to the syntax.

@terlar

This comment has been minimized.

Show comment
Hide comment
@terlar

terlar Jun 3, 2014

Contributor

I just noticed that docops now has a C++ implementation. Might be worth looking into again. https://github.com/docopt/docopt.cpp

Contributor

terlar commented Jun 3, 2014

I just noticed that docops now has a C++ implementation. Might be worth looking into again. https://github.com/docopt/docopt.cpp

@rominf

This comment has been minimized.

Show comment
Hide comment
@rominf

rominf Jun 9, 2014

Contributor

I vote for docopt too. It was fun to use it in Python and even C. I think that it's easier to implement and understand docopt spec enclosed in single quotes. Highlighting is an issue, but I think it can be solved by writing universal vim/emacs/etc. plugin that handles docopt spec in python/c++/fish/etc. sources.

Contributor

rominf commented Jun 9, 2014

I vote for docopt too. It was fun to use it in Python and even C. I think that it's easier to implement and understand docopt spec enclosed in single quotes. Highlighting is an issue, but I think it can be solved by writing universal vim/emacs/etc. plugin that handles docopt spec in python/c++/fish/etc. sources.

@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Jun 13, 2014

Member

I added a wiki page with some samples of what it would look like to write signatures with an extended docopt syntax, and some thoughts on how we would extend it. Contributions welcome.

Member

ridiculousfish commented Jun 13, 2014

I added a wiki page with some samples of what it would look like to write signatures with an extended docopt syntax, and some thoughts on how we would extend it. Contributions welcome.

@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Jun 13, 2014

Member

Reaching out to docopt in docopt/docopt#194

Member

ridiculousfish commented Jun 13, 2014

Reaching out to docopt in docopt/docopt#194

@JeanMertz

This comment has been minimized.

Show comment
Hide comment
@JeanMertz

JeanMertz Oct 21, 2014

@ridiculousfish has there been any progress on this lately?

JeanMertz commented Oct 21, 2014

@ridiculousfish has there been any progress on this lately?

@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Oct 21, 2014

Member

Yes, lots of work in the docopt branch.

Member

ridiculousfish commented Oct 21, 2014

Yes, lots of work in the docopt branch.

@JeanMertz

This comment has been minimized.

Show comment
Hide comment
@JeanMertz

JeanMertz Oct 21, 2014

I missed that branch. Great news 💯 👍

JeanMertz commented Oct 21, 2014

I missed that branch. Great news 💯 👍

@floam

This comment has been minimized.

Show comment
Hide comment
@floam

floam Jun 14, 2016

Member

I wanted to know if this will eventually get merged in the main branch.

It will. The docopt branch is alive (last updated 3 days ago) and that is the plan.

Member

floam commented Jun 14, 2016

I wanted to know if this will eventually get merged in the main branch.

It will. The docopt branch is alive (last updated 3 days ago) and that is the plan.

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Sep 30, 2016

Contributor

Should we implement a getopt() equivalent for fish scripts? This issue has been open for four years. As issue #3403 opened by @floam points out our standard method for option parsing in fish scripts is not compatible with fish builtin commands (or most external commands). Perhaps we should implement a fish getopt builtin for use by fish scripts. Doing so is borderline trivial. It would allow us to make our fish scripts (functions) parse flags in a manner compatible with builtin commands. If and when this is implemented both builtin and function flag parsing can be changed.

Contributor

krader1961 commented Sep 30, 2016

Should we implement a getopt() equivalent for fish scripts? This issue has been open for four years. As issue #3403 opened by @floam points out our standard method for option parsing in fish scripts is not compatible with fish builtin commands (or most external commands). Perhaps we should implement a fish getopt builtin for use by fish scripts. Doing so is borderline trivial. It would allow us to make our fish scripts (functions) parse flags in a manner compatible with builtin commands. If and when this is implemented both builtin and function flag parsing can be changed.

@alphapapa

This comment has been minimized.

Show comment
Hide comment
@alphapapa

alphapapa Oct 1, 2016

Would it be possible to include getopts.fish in Fish itself? It works very well. The only downside I have found is that it treats all arguments after the first non-option argument as non-option arguments, rather than the typical behavior of using -- to end the option list.

I certainly don't oppose a getopt equivalent either. (Note: I think getopt is superior to the Bash getopts builtin, since getopt allows both long and short versions of options.)

alphapapa commented Oct 1, 2016

Would it be possible to include getopts.fish in Fish itself? It works very well. The only downside I have found is that it treats all arguments after the first non-option argument as non-option arguments, rather than the typical behavior of using -- to end the option list.

I certainly don't oppose a getopt equivalent either. (Note: I think getopt is superior to the Bash getopts builtin, since getopt allows both long and short versions of options.)

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Oct 1, 2016

Contributor

@alphapapa, the fact the getopts.fish script you referenced isn't actually compatible with the fish builtin wgetopt() function argues against using it. Unless, of course, it can be easily modified to be compatible with the version used by our builtin commands. Personally I'd prefer to simply expose our wgetopt() function as a builtin command usable by fish scripts. Thus ensuring compatibility. Also, can you provide a link to the script you referred to so we can evaluate its fitness as an alternative solution?

@ridiculousfish, How likely is it that the docopt solution will be made public in, say, the next six months? If the probability is low I'd like to open a new issue to implement a getopt command usable by fish scripts. Implementing that should be almost trivial and would allow commands implemented as functions to behave identically to builtins vis-a-vis flag parsing.

Contributor

krader1961 commented Oct 1, 2016

@alphapapa, the fact the getopts.fish script you referenced isn't actually compatible with the fish builtin wgetopt() function argues against using it. Unless, of course, it can be easily modified to be compatible with the version used by our builtin commands. Personally I'd prefer to simply expose our wgetopt() function as a builtin command usable by fish scripts. Thus ensuring compatibility. Also, can you provide a link to the script you referred to so we can evaluate its fitness as an alternative solution?

@ridiculousfish, How likely is it that the docopt solution will be made public in, say, the next six months? If the probability is low I'd like to open a new issue to implement a getopt command usable by fish scripts. Implementing that should be almost trivial and would allow commands implemented as functions to behave identically to builtins vis-a-vis flag parsing.

@alphapapa

This comment has been minimized.

Show comment
Hide comment
@alphapapa

alphapapa Oct 1, 2016

Oops, I thought getopts.fish was linked here already. It looks like the current home for it is https://github.com/fisherman/getopts and it appears to have been updated since I last looked at it, so I'm not sure if the downside I mentioned still applies.

alphapapa commented Oct 1, 2016

Oops, I thought getopts.fish was linked here already. It looks like the current home for it is https://github.com/fisherman/getopts and it appears to have been updated since I last looked at it, so I'm not sure if the downside I mentioned still applies.

@zanchey

This comment has been minimized.

Show comment
Hide comment
@zanchey

zanchey Oct 1, 2016

Member

... is that a getopt implementation in awk? That's amazing.

Member

zanchey commented Oct 1, 2016

... is that a getopt implementation in awk? That's amazing.

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Oct 1, 2016

Contributor

Let's move the getopt conversation to a new issue.

Contributor

krader1961 commented Oct 1, 2016

Let's move the getopt conversation to a new issue.

@alphapapa

This comment has been minimized.

Show comment
Hide comment
@alphapapa

alphapapa Oct 1, 2016

Er...my mistake, I should have looked more closely at that link. It's by the same author, but apparently he rewrote it in awk. It does seem much simpler, but the one I was referring to is the one here: https://github.com/alphapapa/bucket/blob/master/getopts.fish I don't know if there's a canonical home for the fish-native version...

alphapapa commented Oct 1, 2016

Er...my mistake, I should have looked more closely at that link. It's by the same author, but apparently he rewrote it in awk. It does seem much simpler, but the one I was referring to is the one here: https://github.com/alphapapa/bucket/blob/master/getopts.fish I don't know if there's a canonical home for the fish-native version...

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Jul 12, 2017

Contributor

I've decided the approach advocated in this issue and its predecessor, #447, are not viable. See issue #4190 for a more modest proposal that maintains compatibility with existing builtin commands and makes it trivial to have the same behavior in fish script. I intend to merge that solution in the next day or two unless someone yells "stop".

A DocOpt based solution might be ideal (i.e., perfect) but could only be done in a major release. And since this issue has been open for more than four years it is not obvious it will ever be implemented. Especially since it is now more than three months past the deadline previously committed to for implementing a DocOpt based solution.

I don't see the point of a DocOpt based solution. Practicality and clarity trumps the aesthetics of a DocOpt solution.

Contributor

krader1961 commented Jul 12, 2017

I've decided the approach advocated in this issue and its predecessor, #447, are not viable. See issue #4190 for a more modest proposal that maintains compatibility with existing builtin commands and makes it trivial to have the same behavior in fish script. I intend to merge that solution in the next day or two unless someone yells "stop".

A DocOpt based solution might be ideal (i.e., perfect) but could only be done in a major release. And since this issue has been open for more than four years it is not obvious it will ever be implemented. Especially since it is now more than three months past the deadline previously committed to for implementing a DocOpt based solution.

I don't see the point of a DocOpt based solution. Practicality and clarity trumps the aesthetics of a DocOpt solution.

@krader1961 krader1961 closed this Jul 12, 2017

@krader1961 krader1961 changed the title from Option parsing facility for functions and builtins to Docopt based option parsing facility for functions and builtins Jul 28, 2017

jdxcode pushed a commit to jdxcode/fish-shell that referenced this issue Aug 28, 2017

Initial implementation of docopt parssing for functions
When executing a function, we now parse argv according to
the function's docopt signature, if any, and populate variables
as described in fish-shell#478

@floam floam reopened this Sep 28, 2017

@floam floam modified the milestones: will-not-implement, fish-future Sep 28, 2017

@floam floam added the RFC label Sep 28, 2017

@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Oct 2, 2017

Member

I do plan to pick this up again at some point. I think my first attempt had too much complexity so I want to find a way to do it more simply.

Member

ridiculousfish commented Oct 2, 2017

I do plan to pick this up again at some point. I think my first attempt had too much complexity so I want to find a way to do it more simply.

@krader1961

This comment has been minimized.

Show comment
Hide comment
@krader1961

krader1961 Oct 2, 2017

Contributor

I think the idea is fatally flawed and the Python implementation seems to be dead since it hasn't been updated in more than two years and still isn't deemed good enough for a 1.0 release. See docopt/docopt#371

Contributor

krader1961 commented Oct 2, 2017

I think the idea is fatally flawed and the Python implementation seems to be dead since it hasn't been updated in more than two years and still isn't deemed good enough for a 1.0 release. See docopt/docopt#371

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