The CLI of GLI has pretty much no test coverage. Need to find a way to test it to prevent future cockups like 1.2.0 being nigh-unusable

This is kinda sucky:

> bin/gli asdf
error: Unknown command 'asdf'
> bin/gli init -f
error: Unknown argument -f

GLI should provide the option to say "see bin/gli help for commands" or "see bin/gli help init for options"

Realized that when you do my_app help, there's no way to include a message as to what the application actually does. Pretty lame.

We generate a app_name.rdoc (that is updatable via app_name rdoc), however it's not referenced in the scaffolded gemspec.

The config options cannot be overridden by the command-line. Major cockup

On a fresh install of gli using Ruby 1.8.7 & REE (RVM install) i'm getting the following error from GLI.

ruby-1.8.7-p352@test  ~/documents/projects/test   
→ gli init my_proj command_name
Creating dir ./my_proj/lib...
Creating dir ./my_proj/bin...
Creating dir ./my_proj/test...
Created ./my_proj/bin/my_proj
Created ./my_proj/README.rdoc
Created ./my_proj/my_proj.rdoc
Created ./my_proj/my_proj.gemspec
Created ./my_proj/test/tc_nothing.rb
Created ./my_proj/Rakefile
Created ./my_proj/Gemfile
Created ./my_proj/lib/my_proj_version.rb
ruby-1.8.7-p352@test  ~/documents/projects/test

→ my_proj/bin/my_proj help
/Users/schneems/.rvm/rubies/ruby-1.8.7-p352/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require': no such file to load -- my_proj_version (LoadError)
    from /Users/schneems/.rvm/rubies/ruby-1.8.7-p352/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require'
    from my_proj/bin/my_proj:4

Any thoughts? Congrats on the book btw.

Given this:

command :new do |c|

  c.flag :p
  c.switch :f

  c.action do |global_options,options,args|
  end
end

The help output is:

new [command options] 
nil

Adding a desc '' before the command call fixes it.

It would be handy to have the long option names in the options map in addition to the short names. e.g.

switch [:c,:clean]

options[:c] == options[:clean]

This would allow for more readable access to the options hash

doit --someflag Foo Foo Foo Bar results in an arg list of ["Foo","Bar"]

Probably would be handy to be able to do something like

type Float
flag :cost

and have options[:cost] return a Float of the value.

type [:foo,:bar,:baz]
flag :selection

and have the app a) check that --selection is one of the options and b) set it.

Probably would be pretty easy to do Int, Float, Enum, and List initially.

Also, this would probably be available for free if using OptionParser, per #32

Given this

> todo
usage: todo command [options]

Version: 0.0.1

Options:
    -f, --filename=full path to file - Specify the location of the todo txt file
                                       (default: /Users/davec/.todo.txt)

Commands:
    done - Complete one or more items
    help - Shows list of commands or help for one command
    list - List all items to do
    new  - Create a new item to do

the usage line should really read

usage: todo [global_options] command [command_options]

Global Options:
    -f #etc

And for todo help list we should see

list [command_options] 
    List all items to do
Command Options:
    --foo - 

In order to make a bash function to auto-complete gli-based applications, the help command could be modified to take a switch that means "dump out the commands in a list" so that it could easily be used via the bash complete builtin.

• myapp help should show the commands defined in global space
• myapp command1 help should show the sub-commands of command1
• myapp command1 subcommand help should show the commands under subcommand, etc

on latest, it seems the map(&:to_sym) is not working somehow, even though I test on 1.8.7. Weird.

/usr/lib/ruby/gems/1.8/gems/gli-1.2.1/lib/gli/command_line_token.rb:38:in `parse_names':     wrong argument type Symbol (expected Proc) (TypeError)
    from /usr/lib/ruby/gems/1.8/gems/gli-1.2.1/lib/gli/command_line_token.rb:13:in `initialize'
    from /usr/lib/ruby/gems/1.8/gems/gli-1.2.1/lib/gli/command.rb:15:in `initialize'
    from /usr/lib/ruby/gems/1.8/gems/gli-1.2.1/lib/gli.rb:83:in `new'
    from /usr/lib/ruby/gems/1.8/gems/gli-1.2.1/lib/gli.rb:83:in `command'
    from ./rr:16

Ruby version:

$ ruby --version
ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]

The tc_nothing.rb that is generated by the scaffold requires the file test/unit/ui/console/testrunner for some reason (most likely I thought it was needed). This file exists on 1.8.7, but not on 1.9.2. It's not needed for 1.8.7 tests to work, so it should be removed from the scaffold test file.

when using more than one flag, the order seems to sometimes matter. For example:

"-i 5 -z a" I get :z but :i is the default, not 5.

"-z a -i 5" gives me both as expected

"-i=5 -z=a" gives me both as expected

A lot of code is wrapped up in parsing command line options. Using OptionParser for that might make sense, but I'm not sure if it's as easy as it sounds…

Might be nice to be able raise errors (or certain types) and have them translated into non-stack error messages.

rdoc might be better served by creating a man page suitable for use with ronn and gem-man

Seems all the rage; might as well have a cheat sheet

This could take a few possible forms:

• aruba is in the gemspec and a features/ directory exists with a basic test
• gli-specific step definitions and hooks

The README is getting pretty big; now that the github wikis are git-managed, might make sense to move this stuff there

Etc.getpwuid returns nil on Windows. A better way to get the home directory is Dir.home or File.expand_path('~')

Given this:

desc 'Create a day''s worth of data for a particular service point'
arg_name 'service point ids'
command :data do |c|

  c.desc 'Type of data'
  c.arg_name 'either bill, day, or halfhour'
  c.flag [:t,:type]

  c.desc 'Date for the reads (start date for billing)'
  c.arg_name 'date (in yyyy-mm-dd format)'
  c.default_value '2010-04-01'
  c.flag [:d,:date]

  c.desc 'Number of reads, for billing'
  c.arg_name 'number'
  c.default_value '1'
  c.flag :n

  c.desc 'Make like gas data'
  c.switch :g

  c.action do |global_options,options,args|
    raise "at least one service point id required" if args.nil? || args.empty?
    Generate::Data.new(options[:t],options[:d],options[:n].to_i,options[:g],args).go
  end
end

Using this command line:

generate data -t bill -n 10 1234

The -n 10 doesn't get picked up. If we do this, instead:

generate data -n 10 -t bill 1234

it does work. Not sure why

Would be cool to have a real website for GLI and not just the giant README

Would be nice if gli would generate the code to deal with a .rc file in a user's home directory that could provide user-configured default values for all options:

--- 
:globals: 
  :v: :very
  :h: 
:ls: 
  :x: foo
  :l: true

It would be cool if there were a way to generate the README or part of the README from the DSL used to create the commands; you could run this every so often as you developed your command line application:

gli readme bin/my_command

Could even add a few new bits of meta-data:

desc 'Lists all files in directory'
long_desc 'This will show all the files, optionally with details, in the entire directory where you run this command.  The most useful options are `-l` and `-x`'
command :ls do
  # whatever defines the ls command
end

The long_desc wouldn't show up in help, but might show up in the help command and would certainly show up in the README

I end up writing a lot of

if command.nil? || command.name == :help
  # not creating a trac instance
else 
  # do normal pre checks and init
end

and it would be nice to have a way to detect "special" commands like help, initconfig and rdoc (and whatever other ones get added) in a more generic way

requiring rubygems is kindof a code smell, and the scaffolding does it. Since a gem-deployed command line app will not need it, it's probably not a good idea; need a way to run locally in development, but I suppose there's a lot of options for having rubygems available at runtime:

http://tomayko.com/writings/require-rubygems-antipattern

In bin/cmd:

config_file '.cmd.rc'

flag :o
default_value 'open'

in ~/.cmd.rc

:o: start

the output of cmd help should indicate that the default value of -o is start and not open

There should be a way to invoke the command block with the command itself as the binding so that we don't have to do c. in front of everything.

Given this example:

#!/usr/bin/ruby
$: << File.expand_path(File.dirname(__FILE__) + '/../lib')
require 'rubygems'
require 'gli'

include GLI

desc 'deploys a script to a server'
arg_name 'Describe arguments to deploy here'
command :deploy do |c|
  c.desc 'Forces generation'
  c.default_value 'localhost'
  c.flag [:server,:s]
  c.action do |global_options,options,args|
    p global_options
    p options
    p args
  end
end

GLI.run(ARGV)

When you pass the server before the first argument it works:

$ ruby ./gli-bug.rb deploy --server=internetz here
{}
{:server=>"internetz"}
["here"]

However when you pass it after the argument, it fails:

$ ruby ./gli-bug.rb deploy here --server=internetz
{}
{:server=>"localhost"}
["here", "--server=internetz"]

Am I doing something wrong?

Currently, most of the files are hacked out from the scaffold.rb file. Should use Bundler or its internals to bootstrap the GLI-powered apps. Only issue is that bundler is very married to a git-based repo; not sure that's the best thing to do, so this might could be an option?

error_message in gli.rb eats any error message that isn't in the switch statement, thus if you raise "something's wrong" inside an action block, nothing happens.

Should probably use the long_desc in rdoc everywhere it's accepted

It's come to my attention that the Gemfile for projects like GLI and the projects it generates should be:

source :rubygems

gemspec

And the we should use

s.add_development_dependency "gli"

in the .gemspec files instead of the way GLI currently does it.

I installed gli to follow along with David Copeland's "Command-Line Apps" book. The example fails with "no such file to load -- todo_version.rb". It works when I change line 4 of bin/todo to...

require File.expand_path(File.join(File.dirname(__FILE__),'/../lib/todo_version.rb'))

I verified this behavior on ruby 1.9.2p290 and 1.8.7. I also cloned the repo and did a hard reset to Oct. 5, "updated dep on simplecov", before the load path change and it worked without modification.

Thanks for the great library. I wanted to share in case this is useful.

A lot of the public methods are not rdoc'ed and mentioned only in the wiki documentation. That's not very nice, so I should probably document all the public methods and DSL methods.

Currently, you can document a command's arguments via arg_name. This is OK for simple commands, but for commands that have and ordering of arguments, it's difficult. A syntax might be:

arg_name 1,"the filename"
arg_name 2,:optional,"output file (stdout if omitted)"

Jeweler is just much easier to deal with, so I should convert this project to using it and have the scaffold script default to using Jeweler as well (possibly even using Jeweler's bootstrapping?)

Often, the pre block requires a bunch of command-line options and/or does stuff that is irrelevant to help. There should be an option to not call the pre block for the help subcommand

It would be nice if there was a canonical way that GLI could look for the version of an app. It could then include this in the help automatically. It would also be nice to allow

gli_generated_app --version

to simply output the version without requiring a subcommand (or it could just show the help, I suppose)

If you want to us a '-' in an option name or command name, you have do this:

flag [:n,:'dry-run']

which is pretty annoying. Should be easy to allow strings, and just sanity check for spaces:

flag [:n,'dry-run']

The current error callback only handles errors related to the command line interface; it would be more handy to be able to handle all exceptions that came back.

I mistakenly used this code in a talk, and it brought up an interesting question:

switch [:f,:force]

flag [:f,:file]

What would happen? I believe that the flag would "win", but I'm not sure of the fate of :force, and overall I think this should be treated as an erroneous interface.

Thus, I think this is a bug in GLI and it should complain if you do this, as it's clearly wrong.

Generate a canonical Rakefile (optionally) that could:

• Run tests
• Set up your github pages page with grancher
• Generate rdoc
• Create coverage with rcov

Currently, GLI writes the version file in lib/app_version.rb This probably won't cause any conflicts, but is not the best-practice; it should write the file to lib/app/version.rb (or just anywhere in lib/app).

All GLI apps exit with a status of zero. This is fairly lame, as you cannot script GLI-powered apps. It's doubly lame because I make fun of maven for not doing this.

A few options:

• If error, exit -1, otherwise exit 0
• Provide the user a way to indicate exit code

In either case, this change won't fix any existing GLI apps; they will probably have to add code to exit explicitly themselves

As opposed to a global option to the command, it would be nice to be able to specify a command-scoped option that applies to all commands and then have some commands opt-out of it. For example, suppose several commands create an output file. Instead of

command :foo do |c|
  c.flag [:o,:output_file]
end
command :bar do |c|
  c.flag [:o,:output_file]
end
command :baz do |c|
end

It could look like:

all_commands.flag [:o,:output_file]
command :foo do |c|
end
command :bar do |c|
end
command :baz do |c|
  c.except_flag :o
end