[knuckle_cake]

I think you should continue working on it. If nothing else it builds your personal code library up. I'm not sure how many apps in general use ncurses anymore, but I don't think it's going anywhere.

I'm actually developing a console-based ruby app right now. What would have been useful for me however is something to easily work with a REPL (including commands, subcommands, etc.) without a) having to drop into a full IRB session b) any assumptions that I want to parse an ARGV-like line with --long-switches and whatnot. I don't.

cmdparse is the closest, but still isn't good enough.

Thanks for doing the work on your project. Open-source authors don't get thanked often enough if their project isn't used by millions.

[crazydiamond]

Thanks for your reply. I would really appreciate if you could elaborate a bit more on the REPL part. Are you talking of a command line with which to query your own app within the app, as to the state of objects. Is this within the app, or like talking to it on a port and passing commands on a shell.

I had been actually thinking on the lines of how emacs can expose its commands -- although i am not an emacs user. I'd need to study that.

I am very familiar with various command line parsing libraries, including cmdparse. I did not get your requirement in this context. Thanks for answering.

[knuckle_cake]

I'm writing a monitor for an emulator I'm working on, so your first example is what I am doing.

I was wanting for something that lets me add commands, with aliasing, and arguments (maybe with optional regex validation) - e.g. breakpoint add $BEEF, etc. Writing a DSL is one solution and will probably end up being the way I go once I take a second iteration at this. Right now I'm just using regex parsing, but I only have a few commands I need to worry about now.

cmdparse is frustratingly close but makes a few assumptions that you want to parse ARGV or something that looks like it.

[crazydiamond]

Did you come across a project named Boson (I think), it allows aliasing of commands, and various other options. Check this: http://tagaholic.me/2009/10/14/boson-command-your-ruby-unive...

[knuckle_cake]

Interesting, but it looks to require irb, heavily pollutes the global namespace with commands, and assumes I want to use --options-with-dashes. This is another 'close, but not quite' example.

The current implementation is that I have a hardware instance (like a CPU) that I want to monitor. To do that, I create a new monitor object, and tell it to monitor the hardware instance, and the monitor will mix itself in from there. It's not good if extra methods show up in the global namespace just for command parsing within a single module of the app. The monitor is just a part of this application, and a part that will not be used often by most users.

Everything I see feels like it's inches from what I really need. So close yet so far :)

[crazydiamond]

Another option that comes to mind is Thor by yehuda katz (took me ten minutes to recall the name!): http://yehudakatz.com/2008/05/12/by-thors-hammer/

otoh, there are some simple ones you could possible customize: i once studied and modified Choice (by Chris Wainstrath).

I'd really like to know if you find something that helps you, or what you did eventually.

[knuckle_cake]

I looked at both already. Both assume ARGV-like command strings with --long-switches with no way to get around that without significant rewriting/additional feature work.

Of everything, cmdparse is closest to what I want (by a significant margin,) but it's GPL (not LGPL :( ) so I'm not even sure I can use it in a non-GPL app. If cmdparse were under less-restrictive licensing I would have just hacked it up and released it already. I had already started doing so until I saw the license.

Right now, just writing a DSL is likely going to be my solution. I can bind an irb session to the monitor to keep scope from running away I think. Writing my own command parsing library just isn't interesting enough to me and I don't think I would ever finish it. This itch isn't quite that strong, at least not now.

What I really should do and am going to do later is look into irc clients written in ruby to see how they are doing it. They would probably run into this same problem.