OpenEuphoria

1. Command line help options

• Posted by nanochip Nov 29, 2010
• 1530 views

In the example provided for function cmd_parse(), option -h (for hash) triggers an error:

cmdline.e:274 in function standardize_opts() 
cmd_opts: Duplicate Short Names (h) are not allowed in an option record. 
called from cmdline.e:304 in function stardardize_opts() 
called from cmdline.e:985 in function cmd_parse() 

Are -h and -? hardcoded? What about if I don't want a help option? Documentation is not clear about that.

Also, is there a way to get rid of those annoying square brackets around command line options? Yes, I know they stand for optionals options but... still annoying for my taste.

3. Re: Command line help options

• Posted by ChrisB (moderator) Nov 29, 2010
• 1524 views

Hi

Just done a little with the example, and if you copy and paste, it doesn't work, as is. May I submit

include std/cmdline.e 
include std/map.e 
include std/filesys.e 
 
sequence option_definition 
integer gVerbose = 0 
sequence gOutFile = {} 
sequence gInFile = {} 
function opt_verbose( sequence value) 
   if value[OPT_VAL] = -1 then -- (-!v used on command line) 
   	gVerbose = 0 
   else 
     if value[OPT_CNT] = 1 then 
        gVerbose = 1 
     else 
        gVerbose += 1 
     end if 
   end if 
	return 1 
end function 
 
function opt_output_filename( sequence value) 
   gOutFile = value[OPT_VAL] 
	return 1 
end function 
 
function opt_extras( sequence value) 
   if not file_exists(value[OPT_VAL]) then 
       show_help(option_definition, sprintf("Cannot find '%s'",  
                 {value[OPT_VAL]}) ) 
       abort(1) 
   end if 
   gInFile = append(gInFile, value[OPT_VAL]) 
	return 1 
end function 
 
option_definition = { 
    { "m", "verbose", "Verbose output",   { NO_PARAMETER }, routine_id("opt_verbose") },           --can't have duplicate options           
    { "j", "hash",    "Calc hash values", { NO_PARAMETER }, -1 },                                  --change this to h when hardcoded h fixed 
    { "o", "output",  "Output filename",  { MANDATORY, HAS_PARAMETER, ONCE } ,  
                                            routine_id("opt_output_filename") }, 
    { "i", "import",  "An import path",   { HAS_PARAMETER, MULTIPLE}, -1 }, 
    { "v", "version", "Display version",  { VERSIONING, "myprog v1.0" } },                     
    {  0, 0, 0, 0, routine_id("opt_extras")} 
} 
 
map:map opts = cmd_parse(option_definition) 
 
-- When run as:  
--             eui myprog.ex -v @output.txt -i /etc/app input1.txt input2.txt 
-- and the file "output.txt" contains the two lines ... 
--   --output=john.txt 
--   '-i /usr/local' 
-- 
-- map:get(opts, "verbose") --> 1 
-- map:get(opts, "hash") --> 0 (not supplied on command line) 
-- map:get(opts, "output") --> "john.txt" 
-- map:get(opts, "import") --> {"/usr/local", "/etc/app"} 
-- map:get(opts, OPT_EXTRAS) --> {"input1.txt", "input2.txt"} 
 

Looking through cmdline, PAUSE_MSG doesn't seem to do anything when I try it.

Perhaps all the examples could be checked (not just by the devs, but by everyone) for copy and paste functionality.

Chris

5. Re: Command line help options

• Posted by DerekParnell (admin) Nov 29, 2010
• 1442 views

• Because the application might not be using the English language.
• Because the application does not have a console.
• Because standards are not laws

The OP did not state that they didn't want optional parameters to be distinguished from mandatory ones, only that using '[' ']' to do so is an issue for them.

The Unix standard is not the only standard in use today. For example, in the Windows console environment, the standard is to use "/?" as the help switch.

7. Re: Command line help options

• Posted by jeremy (admin) Nov 29, 2010
• 1515 views

Chris, thanks for catching this. It has been fixed in svn:4340. For clarification... If the user wants to use --get-help, for example, as the "help" parameter, they should put the word HELP in the options for that parameter, i.e.

sequence opts = { 
    { 0, "get-help", "Display help message", { NO_PARAMETER, HELP } } 
} 

This will tell cmd_parse that the "get-help" parameter is the help and it will not do it's own thing.

Jeremy

9. Re: Command line help options

• Posted by nanochip Nov 29, 2010
• 1457 views

Even without the bug, it doesn't works "as is" as it doesn't even include the required included files. Imagine a newcomer to Euphoria (or, worse, to programming) going round and round until he/she figures out which include files command used in the example belongs to.

When needed, an option to include them or not.

Anyone who works with Unix/Linux systems knows that, for example, almost none of Unix built-in commands uses brackets embracing any option when help is invoked, unlesss, of course, you are suggesting that Unix/Linux authors don't adhere to standards.

May be there only two exceptions:

• The "Usage: cmd [OPTION...] [BLA...]... [BLA...]" line, usually at the top of the help screen. Interestingly, this is the only standard Euphoria interpreter doesn't display when help is invoked.

• Optional (or different) options for options: --with-mysql[=PATH], --include[=FILE], --color[=COLOR]

So... which standards are you talking about?

It was the first thing to come to my mind but before re-inventing the wheel, I prefer to ask.

A word of caution for English centric adepts. It's true that programming languages are English centric, but bear in mind that those adepts took too long to realize the very simple fact that English is not the only language on the Earth and not all letters/symbols from other languages can be represented with only one byte (not even written from left to right) and that caused and is still causing too much confusion in standards.

11. Re: Command line help options

• Posted by jeremy (admin) Nov 29, 2010
• 1347 views

The quote was a bit out of context, it was speaking as to removing help all together or making -h, --help non-functional. You are indeed right about extended help not using brackets and in light of that thinking I'd be in favor of removing that from our cmd_parse() method.

Jeremy

13. Re: Command line help options

• Posted by jeremy (admin) Nov 29, 2010
• 1309 views

Um, the user can easily over ride -h and --help. The user has complete control if they want to:

1. Over ride and use --get-help, -u or whatever to display help
2. Provide no default help options at all

It's always been this way. There was a bug that I did fix which prevented the no help at all from being recognized, but it was there from the get go. As for hard coding, I'll stick to the idea that -h and --help should be hard coded as that is a logical default that the vast majority of applications will use w/o any issue. If they localize their application, then they can override that the values with their localized values. Euphoria fully supports this.

I gave an example before about how to do this, here is another:

sequence opts = { 
  { "h", "--human-readable", "Display sizes in a human readable format (e.g., 1K, 234M, 2G)", { NO_PARAMETER } } 
} 

The above will cause the -h or --human-readable to flip a boolean value to YES, via the long name "human-readable". When looking at the help message from the application with this help sequence it will contain 3 entries, -h/--human-readable, --help and -?.

If you do not like either of those, you have two choices, give your own parameters for help:

sequence opts = { 
  { "h", "--human-readable", "Display sizes in a human readable format (e.g., 1K, 234M, 2G)", { NO_PARAMETER } }, 
  { "s", 0, "Admit you are (s)tuck and want help", { HELP } } 
} 

In which case there will be two options presented, -h/--human-readable and -s. If you give -s on the command line, cmd_parse will give the help message as the current -h/--help does. Or, you can specify you don't want cmd_parse() to handle any help options, you may want to do something totally on your own:

sequence opts = { 
  { "h", "--human-readable", "Display sizes in a human readable format (e.g., 1K, 234M, 2G)", { NO_PARAMETER } } 
} 
map optvals = cmd_parse(ops, { NO_HELP }) 

Does that cover what you wish to do, minus the removal of the brackets for now?

Jeremy

15. Re: Command line help options

• Posted by jeremy (admin) Nov 29, 2010
• 1325 views

You've updated from my fix this morning? It was working, maybe a better test case was needed. Thanks for taking it on. While you're working on it, if I don't get to talk to you, I was thinking it would be nice to be able to create grouped sections. This would be very easy to do. For example:

sequence opts = { 
  "General Options:", 
  { blah blah blah }, 
  { blah } 
  "Compilation Options:", 
  { blah blah } 
  ... 
  ... 
} 

The output being:

my_prog help: 
  General Options: 
    -blah1        Hello World 
    -blah2        Hello World 
 
  Compilation Options: 
    -blah3       asdfasdfasdf 
   ...... 

I was going to work on that tonight, but if you have ideas, I have other areas I could work on.

Jeremy

17. Re: Command line help options

• Posted by jeremy (admin) Nov 30, 2010
• 1380 views

Derek,

While I agree that we shouldn't add features during RC willy-nilly, the output of euc -help (especially) is pretty confusing and sloppy. It would be a minimal change that is easily tested. With 4.0 we are really going to push on the outreach program for Euphoria and thus I think polishing the output screen is more than a feature request. Doing so does not hold up 4.1 as there are other bugs that others are working on that are holding 4.0RC2 release up.

As for varying ways of indicating optional parameters, that seems of less importance but it would be easy to simply remove the printing of [] in all cases. Looking at a few Windows commands (copy, xcopy, dir, cd) and a few nix commands (ls, cp, rm, which) and a few common *nix tools (wget, dpkg, gcc, m4) none have brackets. Thus, I think for 4.0 release we are fine releasing w/o displaying brackets and in 4.1 adding some way of either marking optional parameters or maybe the better thing to do is mark mandatory parameters which are going to be the exception normally, at least from the general use of the progams I see so far.

I will be more than happy to do this work.

Jeremy Jeremy