flag: proposal to completing arguments

[Archos]

Some shells to allow complete arguments to commands. e.g. for Bash, see files in directory '/etc/bash_completion.d/'
This is very tedious since it has to be added manually but the commands built in Go could do it easy.

My proposal is that every command built should have a flag '-f' or '-flags', just like '-h'; that new flag should return all flags (except "-h" and "-f") set in the command.
In this way (which does not need a change in the API), an external command could get easilly the arguments (flags) in commands built in Go.

[Hotei]

I don't understand what problem your proposal is intended to solve.  Saving keystrokes isn't sufficient justification for changing the behavior of an entire class of programs.  If you want a -f flag in your programs - just do it - and leave mine alone (tar -f x .) , for instance.

[Archos]

The problem to solve is to return all flags set into the command.
Obviously, the usage of  naming `-f` to the flag is only an example; other was `-flags`.

[chris dollin]

On 20 April 2013 14:15, Archos <raul...@sent.com> wrote:

The problem to solve is to return all flags set into the command.

In this way (which does not need a change in the API), an external command could get easilly the arguments (flags) in commands built in Go.

It's not clear to me what the value of this information is

and whether the consumer is a program or a person.

If a person, don't we already have ways for programs to

show people their flag usage?

If a program, what is it going to do with the set of names,
which to it a rather like -squodge, -pqxy, -fhjydopw, and -dkjcuiyqw

are to us -- just uninterpretable strings? 

-C=hris

--
Chris "allusive" Dollin

[Hotei]

Sorry, but I really don't understand the problem.  It's not imperative but most developers include a -h if the user needs help understanding how to use a command.  What I believe you're suggesting is that if I type :"command -flags" by itself that the program automatically prints something like :

-flags bool false "print all flags"

-h bool false "print help message"

-nCPU int 1 "number of cores to use"

How does that differ from flag.PrintDefaults() since you get that anyway if you include an un-parseable flag?  I mean in that sense your proposal is already implemented...  command -flags will print the defaults if flags is NOT defined.  What am I missing?

[Archos]

El sábado, 20 de abril de 2013 14:36:20 UTC+1, chris dollin escribió:

On 20 April 2013 14:15, Archos <raul...@sent.com> wrote:

The problem to solve is to return all flags set into the command.

In this way (which does not need a change in the API), an external command could get easilly the arguments (flags) in commands built in Go.

It's not clear to me what the value of this information is

and whether the consumer is a program or a person.

That information would be to be used by a third program.
 

If a program, what is it going to do with the set of names,
which to it a rather like -squodge, -pqxy, -fhjydopw, and -dkjcuiyqw

are to us -- just uninterpretable strings? 

Whether a command to can return all flags, then an external program can use that information to create a file with the flags used in each program; finally, that information would be used by a shell to complete arguments automatically.

[Archos]

It should return the names of the flags, i.e. for `gofmt` command:

$ gofmt -flags:
comments
cpuprofile
d
e
l
r
s
tabs
tabwidth
w

[Hotei]

you mean like this...

mdr@loki-535:~$ gofmt -flags

flag provided but not defined: -flags

usage: gofmt [flags] [path ...]

  -comments=true: print comments

  -cpuprofile="": write cpu profile to this file

  -d=false: display diffs instead of rewriting files

  -e=false: print all (including spurious) errors

  -l=false: list files whose formatting differs from gofmt's

  -r="": rewrite rule (e.g., 'a[b:len(a)] -> a[b:]')

  -s=false: simplify code

  -tabs=true: indent with tabs

  -tabwidth=8: tab width

  -w=false: write result to (source) file instead of stdout

All you have to do is remove some noise from the output and you have your wish.  I just don't see a problem here.

On Saturday, April 20, 2013 6:35:17 AM UTC-4, Archos wrote:

[Sebastien Binet]

hi,

On Sat, Apr 20, 2013 at 3:59 PM, Hotei <hote...@gmail.com> wrote:
> you mean like this...
>
> mdr@loki-535:~$ gofmt -flags
> flag provided but not defined: -flags
> usage: gofmt [flags] [path ...]
> -comments=true: print comments
> -cpuprofile="": write cpu profile to this file
> -d=false: display diffs instead of rewriting files
> -e=false: print all (including spurious) errors
> -l=false: list files whose formatting differs from gofmt's
> -r="": rewrite rule (e.g., 'a[b:len(a)] -> a[b:]')
> -s=false: simplify code
> -tabs=true: indent with tabs
> -tabwidth=8: tab width
> -w=false: write result to (source) file instead of stdout
>
> All you have to do is remove some noise from the output and you have your
> wish. I just don't see a problem here.

actually, I think the best way to tackle this issue is to have an
external program taking the sources of the command one wants to
generate the completion-data for (with switches for each $SHELL
flavour), compile those sources in some way (replace the
flag.PrintDefaults or just look at the AST), extract the needed infos
and generate the completion data.

and voila. bob's your uncle.

-s

>
> On Saturday, April 20, 2013 6:35:17 AM UTC-4, Archos wrote:
>>
>> Some shells to allow complete arguments to commands. e.g. for Bash, see
>> files in directory '/etc/bash_completion.d/'
>> This is very tedious since it has to be added manually but the commands
>> built in Go could do it easy.
>>
>> My proposal is that every command built should have a flag '-f' or
>> '-flags', just like '-h'; that new flag should return all flags (except "-h"
>> and "-f") set in the command.
>> In this way (which does not need a change in the API), an external command
>> could get easilly the arguments (flags) in commands built in Go.
>>

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Miki Tebeka]

My proposal is that every command built should have a flag '-f' or '-flags', just like '-h'; that new flag should return all flags (except "-h" and "-f") set in the command.
In this way (which does not need a change in the API), an external command could get easilly the arguments (flags) in commands built in Go.

I think a better approach will be to port http://furius.ca/optcomplete/ to Go. 

[Archos]

That output is given by flag.Usage which can be changed by the command's developer so it can not be taken as a fact
that every Go command use flag.PrintDefaults() there.

[Kevin Gillette]

I regularly use -f. That doesn't of course invalidate your suggestion of -flags. To be parsed with the utmost usefulness, a lot of information would need to be encoded, such as flag types, and noting whether a string var is a file or not (and if so, what shell pattern, or at least suffices are accepted). Most of that information is not captured by the flag package, and thus only exceptionally limited completion capabilities could be gleaned without either messy API additions to flag, or a complete redesign, neither of which will likely happen.

[Archos]

An AST parser to look for flag arguments is right to handle simple flags but not when a program uses sub-commands since there is no standard way to handle it.