getopt-declare 1.09.7 → 1.12

Sign up to get free protection for your applications and to get access to all the features.
data/Declare.rdoc ADDED
@@ -0,0 +1,1861 @@
1
+ #
2
+ # = NAME
3
+ #
4
+ # Getopt::Declare - Declaratively Expressed Command-Line Arguments via Regular Expressions
5
+ #
6
+ # = VERSION
7
+ #
8
+ # This document describes version 1.09 of Getopt::Declare,
9
+ # released May 21, 1999 for Perl.
10
+ # Released Jan 15, 2003 for Ruby.
11
+ #
12
+ # = SYNOPSIS
13
+ #
14
+ # require "Getopt/Declare"
15
+ # args = Getopt::Declare.new(specification_string, optional_source);
16
+ #
17
+ #
18
+ # = DESCRIPTION
19
+ #
20
+ # == Overview
21
+ #
22
+ # Getopt::Declare is <em>yet another</em> command-line argument parser,
23
+ # one which is specifically designed to be powerful but exceptionally
24
+ # easy to use.
25
+ #
26
+ # To parse the command-line in +ARGV+, one simply creates a
27
+ # Getopt::Declare object, by passing Getopt::Declare::new() a
28
+ # specification of the various parameters that may be encountered:
29
+ #
30
+ # args = Getopt::Declare.new(specification)
31
+ #
32
+ # The specification is a single string such as this:
33
+ #
34
+ # specification = %q(
35
+ #
36
+ # -a Process all data
37
+ #
38
+ # -b <t:n> Set mean byte length threshold to <t>
39
+ # { bytelen = t }
40
+ #
41
+ # +c <FILE> Create new file <FILE>
42
+ #
43
+ # --del Delete old file
44
+ # { delold() }
45
+ #
46
+ # delete [ditto]
47
+ #
48
+ # e <h:i>x<w:i> Expand image to height <h> and width <w>
49
+ # { expand(h,w) }
50
+ #
51
+ # -F <file>... Process named file(s)
52
+ # { defer { file.each {|i|
53
+ # process(i) } } }
54
+ #
55
+ # =getrand [<n:i>] Get a random number
56
+ # (or, optionally, <n> of them)
57
+ # { n = 1 unless !n.empty? }
58
+ #
59
+ # -- Traditionally indicates end of arguments
60
+ # { finish(1) }
61
+ # )
62
+ #
63
+ # in which the syntax of each parameter is declared, along with a
64
+ # description and (optionally) one or more actions to be performed when
65
+ # the parameter is encountered. The specification string may also
66
+ # include other usage formatting information (such as group headings or
67
+ # separators) as well as standard Ruby comments (which are ignored).
68
+ #
69
+ # Calling Getopt::Delare::new() parses the contents of the array +ARGV+,
70
+ # extracting any arguments which match the parameters defined in the
71
+ # specification string, and storing the parsed values as hash elements
72
+ # within the new Getopt::Declare object being created.
73
+ #
74
+ # Other features of the Getopt::Declare package include:
75
+ #
76
+ # * The use of full Ruby regular expressions to constrain matching
77
+ # of parameter components.
78
+ #
79
+ # * Automatic generation of error, usage and version information.
80
+ #
81
+ # * Optional conditional execution of embedded actions (i.e. only on
82
+ # successful parsing of the entire command-line)
83
+ #
84
+ # * Strict or non-strict parsing (unrecognized command-line elements may either
85
+ # trigger an error or may simply be left in +ARGV+
86
+ #
87
+ # * Declarative specification of various inter-parameter relationships (for
88
+ # example, two parameters may be declared mutually exclusive and this
89
+ # relationship will then be automatically enforced).
90
+ #
91
+ # * Intelligent clustering of adjacent flags (for example: the
92
+ # command-line sequence "-a -b -c" may be abbreviated to "-abc", unless
93
+ # there is also a <tt>-abc</tt> flag declared).
94
+ #
95
+ # * Selective or global case-insensitivity of parameters.
96
+ #
97
+ # * The ability to parse files (especially configuration files) instead of
98
+ # the command-line.
99
+ #
100
+ # == Terminology
101
+ #
102
+ # The terminology of command-line processing is often confusing, with various
103
+ # terms (such as "argument", "parameter", "option", "flag", etc.)
104
+ # frequently being used interchangeably and inconsistently in the various
105
+ # Getopt packages available. In this documentation, the following
106
+ # terms are used consistently:
107
+ #
108
+ # * <b>"command-line"</b>
109
+ #
110
+ # The space-separated concatenation of the elements of the array +ARGV+
111
+ # at the time a Getopt::Declare object is created.
112
+ #
113
+ # * <b>"parameter specification" (or just "parameter")</b>
114
+ #
115
+ # A specification of a single entity which may appear in the
116
+ # command-line. Always includes at least one syntax for the entity.
117
+ # Optionally may include other _variant>_ syntaxes, one or more
118
+ # _descriptions_ of the entity, and/or _actions_ to be performed when
119
+ # the entity is encountered. For example, the following is a single
120
+ # parameter specification (with two variants):
121
+ #
122
+ # --window <height> x <width> Set window to <height> by <width>
123
+ # { setwin(width,height) }
124
+ #
125
+ # --window <h>x<w>@<x>,<y> Set window size and centroid
126
+ # { setwin(w,h,x,y) }
127
+ #
128
+ #
129
+ # * <b>"argument"</b>
130
+ #
131
+ # A substring of the command-line which matches a single parameter variant.
132
+ # Unlike some other Getopt packages, in Getopt::Declare an argument
133
+ # may be a single element of +ARGV+, or part of a single +ARGV+ element,
134
+ # or the concatenation of several adjacent +ARGV+ elements.
135
+ #
136
+ #
137
+ # * <b>"parameter definition"</b>
138
+ #
139
+ # A specification of one actual syntax variant matched by a parameter. Always
140
+ # consists of a leading _parameter_ _flag_ or _parameter_ _variable_,
141
+ # optionally followed by one or more _parameter_ _components_ (that is,
142
+ # other parameter variables or _punctuators_. In the above example,
143
+ # <tt>--window <height> x <width></tt> is a parameter definition.
144
+ #
145
+ #
146
+ # * <b>"parameter flag" (or just "flag")</b>
147
+ #
148
+ # A sequence of non-space characters which introduces a parameter. Traditionally
149
+ # a parameter flag begins with "-" or "--", but Getopt::Declare allows
150
+ # almost any sequence of characters to be used as a flag. In the above example,
151
+ # <tt>--window</tt> is the parameter flag.
152
+ #
153
+ #
154
+ # * <b>"parameter variable"</b>
155
+ #
156
+ # A place-holder (within a parameter specification) for a value that
157
+ # will appear in any argument matching that parameter. In the above example,
158
+ # <tt>-height</tt>, <tt>-width</tt>, <tt>-h</tt>, <tt>-w</tt>, <tt>-x</tt>, and <tt>-y</tt> are
159
+ # all parameter variables.
160
+ #
161
+ #
162
+ # * <b>"parameter punctuator" (or just "punctuator")</b>
163
+ #
164
+ # A literal sequence of characters (within a parameter specification)
165
+ # which will appear in any argument matching that parameter. In the above
166
+ # example, the literals +x+ and <tt>@</tt> are punctuators.
167
+ #
168
+ #
169
+ # * <b>"parameter description"</b>
170
+ #
171
+ # A textual description of the purpose and/or use of a particular variant of
172
+ # parameter. In the above examples, the string:
173
+ #
174
+ # Set window to <height> by <width>
175
+ #
176
+ # is a parameter description.
177
+ #
178
+ #
179
+ # * <b>"parameter action" (or just "action")</b>
180
+ #
181
+ # A block of Ruby code to be executed in response to encountering a specific
182
+ # parameter. In the above example:
183
+ #
184
+ # { setwin(width,height) }
185
+ #
186
+ # is a parameter action.
187
+ #
188
+ # * <b>"parameter variants"</b>
189
+ #
190
+ # One or more different syntaxes for a single parameter, all sharing
191
+ # the same leading flag, but having different trailing parameter
192
+ # variables and/or punctuators. Getopt::Declare considers all parameter
193
+ # definitions with the same leading flag to be merely variant forms of
194
+ # a single "underlying" parameter. The above example shows two parameter
195
+ # variants for the <tt>--window</tt> parameter.
196
+ #
197
+ #
198
+ # == Parameter definitions
199
+ #
200
+ # As indicated above, a parameter specification consists of three
201
+ # parts: the parameter definition, a textual description, and any
202
+ # actions to be performed when the parameter is matched.
203
+ #
204
+ # The parameter definition consists of a leading flag or parameter
205
+ # variable, followed by any number of parameter variables or
206
+ # punctuators, optionally separated by spaces. The parameter definition
207
+ # is terminated by one or more tabs (at least one trailing tab _must_
208
+ # be present).
209
+ #
210
+ # For example, all of the following are valid Getopt::Declare parameter
211
+ # definitions:
212
+ #
213
+ # -v
214
+ # in=<infile>
215
+ # +range <from>..<to>
216
+ # --lines <start> - <stop>
217
+ # ignore bad lines
218
+ # <outfile>
219
+ #
220
+ # Note that each of the above examples has at least one trailing tab
221
+ # (even if you can't see them). Note too that this hodge-podge of
222
+ # parameter styles is certainly not recommended within a single program,
223
+ # but is shown so as to illustrate some of the range of parameter syntax
224
+ # conventions Getopt::Declare supports.
225
+ #
226
+ # The spaces between components of the parameter definition are optional but
227
+ # significant, both in the definition itself and in the arguments that
228
+ # the definition may match. If there is no space between components in the
229
+ # specification, then no space is allowed between corresponding arguments
230
+ # on the command-line. If there _is_ space between components of the
231
+ # specification, then space between those components is optional on the
232
+ # command-line.
233
+ #
234
+ # For example, the <tt>--lines</tt> parameter above matches:
235
+ #
236
+ # --lines1-10
237
+ # --lines 1-10
238
+ # --lines 1 -10
239
+ # --lines 1 - 10
240
+ # --lines1- 10
241
+ #
242
+ # If it were instead specified as:
243
+ #
244
+ # --lines <start>-<stop>
245
+ #
246
+ # then it would match only:
247
+ #
248
+ # --lines1-10
249
+ # --lines 1-10
250
+ #
251
+ # Note that the optional nature of spaces in parameter specification implies that
252
+ # flags and punctuators cannot contain the character '<' (which is taken as the
253
+ # delimiter for a parameter variable) nor the character '[' (which
254
+ # introduces an optional parameter component - see
255
+ # "Optional parameter components".
256
+ #
257
+ #
258
+ # == Types of parameter variables
259
+ #
260
+ # By default, a parameter variable will match a single blank-terminated
261
+ # or comma-delimited string. For example, the parameter:
262
+ #
263
+ # -val <value>
264
+ #
265
+ # would match any of the following the arguments:
266
+ #
267
+ # -value # <value> <- "ue"
268
+ # -val abcd # <value> <- "abcd"
269
+ # -val 1234 # <value> <- "1234"
270
+ # -val "a value" # <value> <- "a value"
271
+ #
272
+ #
273
+ # It is also possible to restrict the types of values which may be
274
+ # matched by a given parameter variable. For example:
275
+ #
276
+ # -limit <threshold:n> Set threshold to some (real) value
277
+ # -count <N:i> Set count to <N> (must be an integer)
278
+ #
279
+ # If a parameter variable is suffixed with ":n", it will match any
280
+ # reasonable numeric value, whilst the ":i" suffix restricts a
281
+ # parameter variable to only matching integer values.
282
+ # These two "type specifiers" are the simplest examples of a much more
283
+ # powerful mechanism, which allows parameter variables to be restricted
284
+ # to matching any specific regular expression. See "Defining new
285
+ # parameter variable types".
286
+ #
287
+ # Parameter variables are treated as scalars by default, but this too
288
+ # can be altered. Any parameter variable immediately followed by
289
+ # an ellipsis (<tt>...</tt>) is treated as a list variable, and matches its
290
+ # specified type sequentially as many times as possible. For example,
291
+ # the parameter specification:
292
+ #
293
+ # -pages <page:i>...
294
+ #
295
+ # would match either of the following arguments:
296
+ #
297
+ # -pages 1
298
+ # -pages 1 2 7 20
299
+ #
300
+ # Note that both scalar and list parameter variables are "respectful" of the
301
+ # flags of other parameters as well as their own trailing punctuators.
302
+ # For example, given the specifications:
303
+ #
304
+ # -a
305
+ # -b <b_list>...
306
+ # -c <c_list>... ;
307
+ #
308
+ # The following arguments will be parsed as indicated:
309
+ #
310
+ # -b -d -e -a # <b_list> <- ("-d", "-e")
311
+ # -b -d ; # <b_list> <- ("-d", ";")
312
+ # -c -d ; # <c_list> <- ("-d")
313
+ #
314
+ # List parameter variables are also "repectful" of the needs of
315
+ # subsequent parameter variables. That is, a parameter specification
316
+ # like:
317
+ #
318
+ # -copy <files>... <dir>
319
+ #
320
+ # will behave as expected, putting all but the last string after the
321
+ # <tt>-copy</tt> flag into the parameter variable <tt>files</tt>, while
322
+ # the very last string is assigned to <tt>dir</tt>.
323
+ #
324
+ #
325
+ # == Optional parameter components
326
+ #
327
+ # Except for the leading flag, any part of a parameter definition
328
+ # may be made optional by placing it in square brackets.
329
+ # For example:
330
+ #
331
+ # +range <from> [..] [<to>]
332
+ #
333
+ # which matches any of:
334
+ #
335
+ # +range 1..10
336
+ # +range 1..
337
+ # +range 1 10
338
+ # +range 1
339
+ #
340
+ # List parameter variables may also be made optional (the ellipsis must
341
+ # follow the parameter variable name immediately, so it goes _inside_
342
+ # the square brackets):
343
+ #
344
+ # -list [<page>...]
345
+ #
346
+ # Two or more parameter components may be made jointly optional, by specifying
347
+ # them in the same pair of brackets. Optional components may also be nested. For
348
+ # example:
349
+ #
350
+ # -range <from> [.. [<to>] ]
351
+ #
352
+ # Scalar optional parameter variables (such as [<tt>to</tt>]>)
353
+ # are given undefined values if they are skipped during a successful
354
+ # parameter match. List optional parameter variables (such as
355
+ # [<tt>page</tt>...]) are assigned an empty list if unmatched.
356
+ #
357
+ # One important use for optional punctuators is to provide abbreviated
358
+ # versions of specific flags. For example:
359
+ #
360
+ # -num[eric] # Match "-num" or "-numeric"
361
+ # -lexic[ographic]al # Match "-lexical" or "-lexicographical"
362
+ # -b[ells+]w[histles] # Match "-bw" or "-bells+whistles"
363
+ #
364
+ # Note that the actual flags for these three parameters are <tt>-num</tt>,
365
+ # <tt>-lexic</tt> and <tt>-b</tt>, respectively.
366
+ #
367
+ # == Parameter descriptions
368
+ #
369
+ # Providing a textual description for each parameter (or parameter
370
+ # variant) is optional, but strongly recommended. Apart from providing
371
+ # internal documentation, parameter descriptions are used in the
372
+ # automatically-generated usage information provided by Getopt::Declare.
373
+ #
374
+ # Descriptions may be placed after the tab(s) following the
375
+ # parameter definition and may be continued on subsequent lines,
376
+ # provided those lines do not contain any tabs after the first
377
+ # non-whitespace character (because any such line will instead be
378
+ # treated as a new parameter specification). The description is
379
+ # terminated by a blank line, an action specification (see below) or
380
+ # another parameter specification.
381
+ #
382
+ # For example:
383
+ #
384
+ # -v Verbose mode
385
+ # in=<infile> Specify input file
386
+ # (will fail if file does not exist)
387
+ #
388
+ # +range <from>..<to> Specify range of columns to consider
389
+ # --lines <start> - <stop> Specify range of lines to process
390
+ #
391
+ # ignore bad lines Ignore bad lines :-)
392
+ #
393
+ # <outfile> Specify an output file
394
+ #
395
+ # The parameter description may also contain special directives which
396
+ # alter the way in which the parameter is parsed. See the various
397
+ # subsections of "ADVANCED FEATURES" for more information.
398
+ #
399
+ #
400
+ # == Actions
401
+ #
402
+ # Each parameter specification may also include one or more blocks of
403
+ # Ruby code, specified in a pair of curly brackets (which _must_ start on
404
+ # a new line).
405
+ #
406
+ # Each action is executed as soon as the corresponding parameter is
407
+ # successfully matched in the command-line (but see "Deferred actions"
408
+ # for a means of delaying this response).
409
+ #
410
+ # For example:
411
+ #
412
+ # -v Verbose mode
413
+ # { $verbose = 1 }
414
+ # -q Quiet mode
415
+ # { $verbose = 0 }
416
+ #
417
+ # Actions are executed (as +begin+ blocks) in the package in which the
418
+ # Getopt::Declare object containing them was created. Hence they
419
+ # have access to all package variables and functions in that namespace.
420
+ #
421
+ # In addition, each parameter variable belonging to the corresponding
422
+ # parameter is made available as a (block-scoped) Ruby variable with the
423
+ # same name. For example:
424
+ #
425
+ # +range <from>..<to> Set range
426
+ # { setrange($from, $to) }
427
+ #
428
+ # -list <page:i>... Specify pages to list
429
+ # { page.each { |i|
430
+ # list(i) if i > 0
431
+ # }
432
+ # }
433
+ #
434
+ # Note that single parameter variables become scalar Ruby variables,
435
+ # all matching their type (Fixnum, Float, String) and list parameter
436
+ # variables become Ruby arrays.
437
+ #
438
+ #
439
+ # == Predefined variables available in actions
440
+ #
441
+ # Within an action the following variables are also available:
442
+ #
443
+ # * <tt>\_PARAM_</tt> String
444
+ #
445
+ # Stores the identifier of the current parameter: either the leading
446
+ # flag or, if there is no leading flag, the name of the first parameter
447
+ # variable.
448
+ #
449
+ # * <tt>\_PUNCT_</tt> Hash
450
+ #
451
+ # Stores the substring matched by each punctuator in the current parameter.
452
+ # The hash is indexed by the punctuator itself. The main purpose of this
453
+ # variable is to allow actions to check whether optional punctuators were
454
+ # in fact matched.
455
+ #
456
+ # For example:
457
+ #
458
+ # -v[erbose] Set verbose mode
459
+ # (doubly verbose if full word used)
460
+ # { if _PUNCT_["erbose"]
461
+ # verbose = 2
462
+ # else
463
+ # verbose = 1
464
+ # end
465
+ # }
466
+ #
467
+ # * <tt>\_FOUND_</tt> Hash
468
+ #
469
+ # This hash stores boolean values indicating whether or not a given
470
+ # parameter has already been found. The hash keys are the leading flags
471
+ # or parameter variables of each parameter. For instance, the following
472
+ # specification makes the <tt>-q</tt> and <tt>-v</tt> parameters mutually
473
+ # exclusive (but see "Parameter dependencies" for a _much_ easier way
474
+ # to achieve this effect):
475
+ #
476
+ # -v Set verbose mode
477
+ # { raise "Can't be verbose *and* quiet!\n" if
478
+ # _FOUND_["-q"]
479
+ # }
480
+ #
481
+ # -q Set quiet mode
482
+ # { raise "Can't be quiet *and* verbose!\n" if
483
+ # _FOUND_["-v"]
484
+ # }
485
+ #
486
+ # For reasons that will be explained in "Rejection and termination",
487
+ # a given parameter is not marked as found until _after_ its
488
+ # associated actions are executed. That is, <tt>_FOUND_[\_PARAM_]</tt> will not
489
+ # (usually) be true during a parameter action.
490
+ #
491
+ #
492
+ # Note that, although numerous other internal variables on which the
493
+ # generated parser relies are also visible within parameter actions,
494
+ # accessing any of them may have Dire Consequences. Moreover, these
495
+ # other variables may no longer be accessible (or even present) in
496
+ # future versions of Getopt::Declare. All such internal variables
497
+ # have names beginning with an underscore. Avoiding such variables names
498
+ # will ensure there are no conflicts between actions and the parser
499
+ # itself.
500
+ #
501
+ #
502
+ # == The command-line parsing process
503
+ #
504
+ # Whenever a Getopt::Declare object is created, the current command-line
505
+ # is parsed by sequentially, by attempting to match each parameter
506
+ # in the object's specification string against the current elements in the
507
+ # +ARGV+ array (but see "Parsing from other sources"). The order
508
+ # in which parameters are tried against +ARGV+ is determined by
509
+ # three rules:
510
+ #
511
+ # 1. Parameters with longer flags are tried first. Hence the command-line
512
+ # argument "-quiet" would be parsed as matching the parameter
513
+ # <tt>-quiet</tt> rather than the parameter <tt>-q <string></tt>, even
514
+ # if the <tt>-q</tt> parameter was defined first.
515
+ #
516
+ # 2. Parameter _variants_ with the most components are
517
+ # matched first. Hence the argument "-rand 12345" would be parsed as
518
+ # matching the parameter variant <tt>-rand <seed></tt>, rather than the
519
+ # variant <tt>-rand</tt>, even if the "shorter" <tt>-rand</tt> variant
520
+ # was defined first.
521
+ #
522
+ # 3. Otherwise, parameters are matched in the order they are defined.
523
+ #
524
+ # Elements of +ARGV+ which do not match any defined parameter are collected
525
+ # during the parse and are eventually put back into +ARGV+
526
+ # (see "Strict and non-strict command-line parsing").
527
+ #
528
+ #
529
+ # = ADVANCED FEATURES
530
+ #
531
+ # == Case-insensitive parameter matching
532
+ #
533
+ # By default, a Getopt::Declare object parses the command-line in
534
+ # a <em>case-sensitive</em> manner. The <tt>[nocase]</tt> directive enables
535
+ # a specific parameter (or, alternatively, _all_ parameters) to be matched
536
+ # case-insensitively.
537
+ #
538
+ # If a <tt>nocase]</tt> directive is included in the description of a
539
+ # specific parameter variant, then that variant (only) will be matched
540
+ # without regard for case. For example, the specification:
541
+ #
542
+ # -q Quiet mode [nocase]
543
+ #
544
+ # -v Verbose mode
545
+ #
546
+ # means that the arguments "-q" and "-Q" will both match the <tt>-q</tt> parameter, but
547
+ # that only "-v" (and _not_ "-V") will match the <tt>-v</tt> parameter.
548
+ #
549
+ # If a <tt>[nocase]</tt> directive appears anywhere _outside_ a parameter
550
+ # description, then the entire specification is declared case-insensitive
551
+ # and all parameters defined in that specification are matched without
552
+ # regard to case.
553
+ #
554
+ #
555
+ # == Termination and rejection
556
+ #
557
+ # It is sometimes useful to be able to terminate command-line
558
+ # processing before all arguments have been parsed. To this end,
559
+ # Getopt::Declare provides a special local operator (+finish+) which
560
+ # may be used within actions. The +finish+ operator takes a single optional
561
+ # argument. If the argument is true (or omitted),
562
+ # command-line processing is terminated at once (although the current
563
+ # parameter is still marked as having been successfully matched). For
564
+ # example:
565
+ #
566
+ # -- Traditional argument list terminator
567
+ # { finish }
568
+ #
569
+ # -no-- Use non-traditional terminator instead
570
+ # { nontrad = 1 }
571
+ #
572
+ # ## Non-traditional terminator (only valid if -no-- flag seen)
573
+ # { finish(nontrad) }
574
+ #
575
+ # It is also possible to reject a single parameter match from within an
576
+ # action (and then continue trying other candidates). This allows
577
+ # actions to be used to perform more sophisticated tests on the type of
578
+ # a parameter variable, or to implement complicated parameter
579
+ # interdependencies.
580
+ #
581
+ # To reject a parameter match, the +reject+ operator is used. The
582
+ # +reject+ operator takes an optional argument.
583
+ # If the argument is true (or was omitted), the current parameter
584
+ # match is immediately rejected. For example:
585
+ #
586
+ # -ar <r:n> Set aspect ratio (must be in the range [0..1])
587
+ # {
588
+ # $sawaspect += 1
589
+ # reject( r <= 0 || r > 1 )
590
+ # setaspect(r)
591
+ # }
592
+ #
593
+ # -q Quiet option (not available on Wednesdays)
594
+ # {
595
+ # reject(Time.new.localtime.day == 3)
596
+ # $verbose = 0
597
+ # }
598
+ #
599
+ # Note that any actions performed _before_ the call to +reject+ will
600
+ # still have effect (for example, the variable <tt>$sawaspect</tt> remains
601
+ # incremented even if the aspect ratio parameter is subsequently rejected).
602
+ #
603
+ # The +reject+ operator may also take a second argument, which is
604
+ # used as an error message if the rejected argument subsequently
605
+ # fails to match any other parameter. For example:
606
+ #
607
+ # -q Quiet option (not available on Wednesdays)
608
+ # {
609
+ # reject(Time.new.localtime.day == 3, "Not today!")
610
+ # $verbose = 0;
611
+ # }
612
+ #
613
+ #
614
+ # == Specifying other parameter variable types
615
+ #
616
+ # As was mentioned in "Type of parameter variables", parameter
617
+ # variables can be restricted to matching only numbers or only integers
618
+ # by using the type specifiers ":n" and ":i". Getopt::Declare
619
+ # provides seven other inbuilt type specifiers, as well as two mechanisms
620
+ # for defining new restrictions on parameter variables.
621
+ #
622
+ # The other inbuilt type specifiers are:
623
+ #
624
+ # * :+i
625
+ #
626
+ # which restricts a parameter variable to matching positive, non-zero
627
+ # integers (that is: 1, 2, 3, etc.)
628
+ #
629
+ # * :+n
630
+ #
631
+ # which restricts a parameter variable to matching positive, non-zero
632
+ # numbers (that is, floating point numbers strictly greater than zero).
633
+ #
634
+ # * :0+i
635
+ #
636
+ # which restricts a parameter variable to matching non-negative integers (that
637
+ # is: 0, 1, 2, 3, etc.)
638
+ #
639
+ # * :0+n
640
+ #
641
+ # which restricts a parameter variable to matching non-negative numbers (that
642
+ # is, floating point numbers greater than or equal to zero).
643
+ #
644
+ # * :s
645
+ #
646
+ # which allows a parameter variable to match any quote-delimited or
647
+ # whitespace-terminated string. Note that this specifier simply makes
648
+ # explicit the default behaviour.
649
+ #
650
+ # * :d
651
+ #
652
+ # which is used to match directory names. Like type ':s', type ':d'
653
+ # matches any quote-delimited or whitespace-terminated string. However
654
+ # this type requires that the matched string is name of an existing
655
+ # (and accesable) directory.
656
+ #
657
+ # * :if
658
+ #
659
+ # which is used to match input file names. Like type ':s', type ':if'
660
+ # matches any quote-delimited or whitespace-terminated string. However
661
+ # this type does _not_ respect other command-line flags and also
662
+ # requires that the matched string is either "-" (indicating standard
663
+ # input) or the name of a readable file.
664
+ #
665
+ # * :of
666
+ #
667
+ # which is used to match output file names. It is exactly like type ':if' except
668
+ # that it requires that the string is either "-" (indicating standard output)
669
+ # or the name of a file that is either writable or non-existent.
670
+ #
671
+ # * :s
672
+ #
673
+ # which allows a parameter variable to match any quote-delimited or
674
+ # whitespace-terminated string. Note that this specifier simply makes
675
+ # explicit the default behaviour.
676
+ #
677
+ #
678
+ # For example:
679
+ #
680
+ # -repeat <count:+i> Repeat <count> times (must be > 0)
681
+ #
682
+ # -scale <factor:0+n> Set scaling factor (cannot be negative)
683
+ #
684
+ #
685
+ # Alternatively, parameter variables can be restricted to matching a
686
+ # specific regular expression, by providing the required pattern
687
+ # explicitly (in matched "/" delimiters after the ":"). For example:
688
+ #
689
+ # -parity <p:/even|odd|both/> Set parity (<p> must be "even",
690
+ # "odd" or "both")
691
+ #
692
+ # -file <name:/\w*\.[A-Z]{3}/> File name must have a three-
693
+ # capital-letter extension
694
+ #
695
+ # If an explicit regular expression is used, there are three "convenience"
696
+ # extensions available:
697
+ #
698
+ # * %T
699
+ #
700
+ # If the sequence <tt>%T</tt> appears in a pattern, it is translated to a negative
701
+ # lookahead containing the parameter variable's trailing context.
702
+ # Hence the parameter definition:
703
+ #
704
+ # -find <what:/(%T.)+/> ;
705
+ #
706
+ # ensures that the command line argument "-find abcd;" causes <tt><-what></tt>
707
+ # to match "abcd", _not_ "abcd;".
708
+ #
709
+ #
710
+ # * %D
711
+ #
712
+ # If the sequence <tt>%D</tt> appears in a pattern, it is translated into
713
+ # a subpattern which matches any single digit (like a <tt>\d</tt>), but
714
+ # only if that digit would _not_ match the parameter variable's trailing
715
+ # context.
716
+ # Hence <tt>%D</tt> is just a convenient short-hand for <tt>(?:%T\d)</tt>
717
+ # (and is actually implemented that way).
718
+ #
719
+ # * %F
720
+ #
721
+ # By default, any explicit pattern is modified by Getopt::Declare
722
+ # so that it fails if the argument being matched represents some defined
723
+ # parameter flag. If however the sequence <tt>%F</tt> appears anywhere in a
724
+ # pattern, it causes the pattern _not_ to reject strings which would
725
+ # otherwise match another flag. For example, the inbuilt types ':if' and
726
+ # ':of' use <tt>%F</tt> to enable them to match filenames which happen to be
727
+ # identical to parameter flags.
728
+ #
729
+ #
730
+ # == Defining new parameter variable types
731
+ #
732
+ # Explicit regular expressions are very powerful, but also cumbersome to
733
+ # use (or reuse) in some situations. Getopt::Declare provides a general
734
+ # "parameter variable type definition" mechanism to simplify such cases.
735
+ #
736
+ # To declare a new parameter variable type, the <tt>[pvtype:...]</tt>
737
+ # directive is used. A <tt>[pvtype...]</tt> directive specifies the name,
738
+ # matching pattern, and action for the new parameter variable type
739
+ # (though both the pattern and action are optional).
740
+ #
741
+ # The name string may be _any_ whitespace-terminated sequence of
742
+ # characters which does not include a ">". The name may also be specified
743
+ # within a pair of quotation marks (single or double) or within any Perl
744
+ # quotelike operation. For example:
745
+ #
746
+ # [pvtype: num ] # Makes this valid: -count <N:num>
747
+ # [pvtype: 'a num' ] # Makes this valid: -count <N:a num>
748
+ # [pvtype: %q{nbr} ] # Makes this valid: -count <N:nbr>
749
+ #
750
+ # The pattern is used in initial matching of the parameter variable.
751
+ # Patterns are normally specified as a "/"-delimited Perl regular
752
+ # expression:
753
+ #
754
+ # [pvtype: num /\d+/ ]
755
+ # [pvtype: 'a num' /\d+(\.\d*)/ ]
756
+ # [pvtype: %q{nbr} /[+-]?\d+/ ]
757
+ #
758
+ # Alternatively the pattern associated with a new type may be specified
759
+ # as a ":" followed by the name of another parameter variable type (in
760
+ # quotes if necessary). In this case the new type matches the same
761
+ # pattern (and action! - see below) as the named type. For example:
762
+ #
763
+ # [pvtype: num :+i ] # <X:num> is the same as <X:+i>
764
+ # [pvtype: 'a num' :n ] # <X:a num> is the same as <X:n>
765
+ # [pvtype: %q{nbr} :'a num' ] # <X:nbr> is also the same as <X:n>
766
+ #
767
+ # As a third alternative, the pattern may be omitted altogether, in
768
+ # which case the new type matches whatever the inbuilt pattern ":s"
769
+ # matches.
770
+ #
771
+ # The optional action which may be included in any <tt>[pvtype:...]</tt>
772
+ # directive is executed _after_ the corresponding parameter variable
773
+ # matches the command line but _before_ any actions belonging to the
774
+ # enclosing parameter are executed. Typically, such type actions
775
+ # will call the +reject+ operator (see "Termination and rejection")
776
+ # to test extra conditions, but any valid Perl code is acceptible. For
777
+ # example:
778
+ #
779
+ # [pvtype: num /\d+/ { reject if (localtime)[6]==3 } ]
780
+ # [pvtype: 'a num' :n { print "a num!" } ]
781
+ # [pvtype: %q{nbr} :'a num' { reject $no_nbr } ]
782
+ #
783
+ # If a new type is defined in terms of another (for example, ":a num"
784
+ # and ":nbr" above), any action specified by that new type is
785
+ # _prepended_ to the action of that other type. Hence:
786
+ #
787
+ #
788
+ # * the new type ":num" matches any string of digits, but then rejects the
789
+ # match if it's Wednesday.
790
+ #
791
+ # * the new type ":a num" matches any string of digits (like its parent
792
+ # type ":num"), _then_ prints out "a num!", _and_ _then_ rejects the
793
+ # match if it's Wednesday (like its parent type ":num").
794
+ #
795
+ # * the new type ":nbr" matches any string of digits (like its parent type
796
+ # ":a num"), but then rejects the match if the global <tt>$no_nbr</tt> variable
797
+ # is true. Otherwise it next prints out "a num!" (like its parent type
798
+ # ":a num"), and finally rejects the match if it's Wednesday (like its
799
+ # grandparent type ":num").
800
+ #
801
+ #
802
+ # When a type action is executed (as part of a particular parameter
803
+ # match), three local variables are available:
804
+ #
805
+ # * <tt>\_VAL_</tt> String/Fixnum/Float
806
+ #
807
+ # which contains the value matched by the type's pattern. It is this value which
808
+ # is ultimately assigned to the local Ruby variable which is available to
809
+ # parameter actions. Hence if the type action changes the value of <tt>\_VAL_</tt>,
810
+ # that changed value becomes the "real" value of the corresponding parameter
811
+ # variable (see the Roman numeral example below).
812
+ # Note that <tt>\_VAL_</tt> is a variable of different type based on
813
+ # parameter specified. For [pvtype:...] it is always a String variable.
814
+ #
815
+ # * <tt>\_VAR_</tt> String
816
+ #
817
+ # which contains the name of the parameter variable being matched.
818
+ #
819
+ # * <tt>\_PARAM_</tt> String
820
+ #
821
+ # which contains the name of the parameter currently being matched.
822
+ #
823
+ #
824
+ # Here is a example of the use of these variables:
825
+ #
826
+ # args = Getopt::Declare.new( <<-'EOPARAM' )
827
+ #
828
+ # [pvtype: type /AB|[OAB]/ ]
829
+ # [pvtype: Rh? /Rh[+-]/ ]
830
+ # [pvtype: days :+i {
831
+ # reject(_VAL_ < 14,"#{_PARAM_} (too soon!)")
832
+ # }
833
+ # ]
834
+ #
835
+ # -donated <d:days> Days since last donation
836
+ # -applied <a:days> Days since applied to donate
837
+ #
838
+ # -blood <type:type> [<rh:Rh?>] Specify blood type
839
+ # and (optionally) rhesus factor
840
+ # EOPARAM
841
+ #
842
+ # In the above example, the ":days" parameter variable type is defined
843
+ # to match whatever the ":+i" type matches (that is positive, non-zero
844
+ # integers), with the proviso that the matching value (<tt>\_VAL_</tt>) must
845
+ # be at least 14. If a shorter value is specified for <tt>d</tt>,
846
+ # or <tt>a</tt> parameter variables, then Getopt::Declare would
847
+ # issue the following (respective) error messages:
848
+ #
849
+ # Error: -donated (too soon!)
850
+ # Error: -applied (too soon!)
851
+ #
852
+ # Note that the "inbuilt" parameter variable types ("i", "n", etc.) are
853
+ # really just predefined type names, and hence can be altered if necessary:
854
+ #
855
+ # args = Getopt::Declare.new( <<-'EOPARAM' )
856
+ #
857
+ # [pvtype: 'n' /[MDCLXVI]+/ { reject( !(_VAL_=to_roman(_VAL_))) } ]
858
+ #
859
+ # -index <number:n> Index number
860
+ # { print data[number]; }
861
+ # EOPARAM
862
+ #
863
+ # The above <tt>[pvtype:...]</tt> directive means that all parameter variables
864
+ # specified with a type ":n" henceforth only match valid Roman
865
+ # numerals, but that any such numerals are _automatically_ converted to
866
+ # ordinary numbers (by passing <tt>\_VAL_</tt>) through the <tt>to_roman</tt>
867
+ # function).
868
+ #
869
+ # Hence the requirement that all ":n" numbers now must be Roman can be
870
+ # imposed _transparently_, at least as far as the actual parameter
871
+ # variables which use the ":n" type are concerned. Thus <tt>number</tt> can
872
+ # be still used to index the array <tt>data</tt> despite the new restrictions
873
+ # placed upon it by the redefinition of type ":n".
874
+ #
875
+ # Note too that, because the ":+n" and ":0+n" types are implicitly
876
+ # defined in terms of the original ":n" type (as if the directives:
877
+ #
878
+ # [pvtype: '+n' :n { reject if _VAL_ <= 0 } ]
879
+ # [pvtype: '0+n' :n { reject if _VAL_ < 0 } ]
880
+ #
881
+ # were included in every specification), the above redefinition of ":n"
882
+ # affects those types as well. In such cases the format conversion is
883
+ # performed _before_ the "sign" tests (in other words, the "inherited"
884
+ # actions are performed _after_ any newly defined ones).
885
+ #
886
+ # Parameter variable type definitions may appear anywhere in a
887
+ # Getopt::Declare specification and are effective for the entire
888
+ # scope of the specification. In particular, new parameter variable
889
+ # types may be defined _after_ they are used.
890
+ #
891
+ # == Undocumented parameters
892
+ #
893
+ # If a parameter description is omitted, or consists entirely of
894
+ # whitespace, or contains the special directive <tt>[undocumented]</tt>, then
895
+ # the parameter is still parsed as normal, but will not appear in the
896
+ # automatically generated usage information (see "Usage information").
897
+ #
898
+ # Apart from allowing for "secret" parameters (a dubious benefit), this
899
+ # feature enables the programmer to specify some undocumented action
900
+ # which is to be taken on encountering an otherwise unknown argument.
901
+ # For example:
902
+ #
903
+ # <unknown>
904
+ # { handle_unknown(unknown) }
905
+ #
906
+ #
907
+ # == "Dittoed" parameters
908
+ #
909
+ # Sometimes it is desirable to provide two or more alternate flags for
910
+ # the same behaviour (typically, a short form and a long form). To
911
+ # reduce the burden of specifying such pairs, the special directive
912
+ # <tt>[ditto]</tt> is provided. If the description of a parameter _begins_ with
913
+ # a <tt>[ditto]</tt> directive, that directive is replaced with the
914
+ # description for the immediately preceding parameter (including any
915
+ # other directives). For example:
916
+ #
917
+ # -v Verbose mode
918
+ # --verbose [ditto] (long form)
919
+ #
920
+ # In the automatically generated usage information this would be displayed as:
921
+ #
922
+ # -v Verbose mode
923
+ # --verbose " " (long form)
924
+ #
925
+ # Furthermore, if the "dittoed" parameter has no action(s) specified, the
926
+ # action(s) of the preceding parameter are reused. For example, the
927
+ # specification:
928
+ #
929
+ # -v Verbose mode
930
+ # { $verbose = 1; }
931
+ # --verbose [ditto]
932
+ #
933
+ # would result in the <tt>--verbose</tt> option setting <tt>$verbose</tt> just like the
934
+ # <tt>-v</tt> option. On the other hand, the specification:
935
+ #
936
+ # -v Verbose mode
937
+ # { $verbose = 1; }
938
+ # --verbose [ditto]
939
+ # { $verbose = 2; }
940
+ #
941
+ #
942
+ # would give separate actions to each flag.
943
+ #
944
+ #
945
+ # == Deferred actions
946
+ #
947
+ # It is often desirable or necessary to defer actions taken in response
948
+ # to particular flags until the entire command-line has been parsed. The most
949
+ # obvious case is where modifier flags must be able to be specified _after_
950
+ # the command-line arguments they modify.
951
+ #
952
+ # To support this, Getopt::Declare provides a local operator (+defer+) which
953
+ # delays the execution of a particular action until the command-line processing
954
+ # is finished. The +defer+ operator takes a single block, the execution of which
955
+ # is deferred until the command-line is fully and successfully parsed. If
956
+ # command-line processing _fails_ for some reason (see "DIAGNOSTICS"), the
957
+ # deferred blocks are never executed.
958
+ #
959
+ # For example:
960
+ #
961
+ # <files>... Files to be processed
962
+ # { defer { files.each { |i|
963
+ # print i,"\n" } } }
964
+ #
965
+ # -rev[erse] Process in reverse order
966
+ # { $ordered = -1 }
967
+ #
968
+ # -rand[om] Process in random order
969
+ # { $ordered = 0 }
970
+ #
971
+ #
972
+ # With the above specification, the <tt>-rev</tt> and/or <tt>-rand</tt> flags
973
+ # can be specified _after_ the list of files, but still affect the processing
974
+ # of those files. Moreover, if the command-line parsing fails for some reason
975
+ # (perhaps due to an unrecognized argument), the deferred processing will
976
+ # not be performed.
977
+ #
978
+ #
979
+ # == Flag clustering
980
+ #
981
+ # Like some other Getopt modules, Getopt::Declare allows parameter
982
+ # flags to be "clustered". That is, if two or more flags have the same
983
+ # "flag prefix" (one or more leading non-whitespace, non-alphanumeric
984
+ # characters), those flags may be concatenated behind a single copy of that
985
+ # flag prefix.
986
+ # For example, given the parameter specifications:
987
+ #
988
+ # -+ Swap signs
989
+ # -a Append mode
990
+ # -b Bitwise compare
991
+ # -c <FILE> Create new file
992
+ # +del Delete old file
993
+ # +e <NICE:i> Execute (at specified nice level) when complete
994
+ #
995
+ # The following command-lines (amongst others) are all exactly equivalent:
996
+ #
997
+ # -a -b -c newfile +e20 +del
998
+ # -abc newfile +dele20
999
+ # -abcnewfile+dele20
1000
+ # -abcnewfile +e 20del
1001
+ #
1002
+ # The last two alternatives are correctly parsed because
1003
+ # Getopt::Declare allows flag clustering at _any point_ where the
1004
+ # remainder of the command-line being processed starts with a
1005
+ # non-whitespace character and where the remaining substring would not
1006
+ # otherwise immediately match a parameter flag.
1007
+ #
1008
+ # Hence the trailing "+dele20" in the third command-line example is parsed as
1009
+ # "+del +e20" and not "-+ del +e20". This is because the previous "-"
1010
+ # prefix is _not_ propagated (since the leading "+del" _is_ a valid flag).
1011
+ #
1012
+ # In contrast, the trailing "+e 20del" in the fourth example is parsed as
1013
+ # "+e 20 +del" because, after the " 20" is parsed (as the integer
1014
+ # parameter variable <tt><NICE></tt>, the next characters are "del",
1015
+ # which _do_ _not_ form a flag themselves unless prefixed with the
1016
+ # controlling "+".
1017
+ #
1018
+ # In some circumstances a clustered sequence of flags on the command-line
1019
+ # might also match a single (multicharacter) parameter flag. For example, given
1020
+ # the specifications:
1021
+ #
1022
+ # -a Blood type is A
1023
+ # -b Blood type is B
1024
+ # -ab Blood type is AB
1025
+ # -ba Donor has a Bachelor of Arts
1026
+ #
1027
+ # A command-line argument "-aba" might be parsed as
1028
+ # "-a -b -a" or "-a -ba" or "-ab -a". In all such
1029
+ # cases, Getopt::Declare prefers the longest unmatched flag first.
1030
+ # Hence the previous example would be parsed as "-ab -a", unless
1031
+ # the <tt>-ab</tt> flag had already appeared in the command-line (in which
1032
+ # case, it would be parsed as "-a -ba").
1033
+ #
1034
+ # These rules are designed to produce consistency and "least surprise",
1035
+ # but (as the above example illustrates) may not always do so. If the
1036
+ # idea of unconstrained flag clustering is too libertarian for a particular
1037
+ # application, the feature may be restricted (or removed completely),
1038
+ # by including a <tt>[cluster:...]</tt> directive anywhere in the specification string.
1039
+ #
1040
+ # The options are:
1041
+ #
1042
+ # * <tt>[cluster: any]</tt>
1043
+ #
1044
+ # This version of the directive allows any flag to be clustered (that is,
1045
+ # it merely makes explicit the default behaviour).
1046
+ #
1047
+ # * <tt>[cluster: flags]</tt>
1048
+ #
1049
+ # This version of the directive restricts clustering to parameters which are
1050
+ # "pure" flags (that is, those which have no parameter variables or punctuators).
1051
+ #
1052
+ # * <tt>[cluster: singles]</tt>
1053
+ #
1054
+ # This version of the directive restricts clustering to parameters which are
1055
+ # "pure" flags, and which consist of a flag prefix followed by a single
1056
+ # alphanumeric character.
1057
+ #
1058
+ # * <tt>[cluster: none]</tt>
1059
+ #
1060
+ # This version of the directive turns off clustering completely.
1061
+ #
1062
+ # For example:
1063
+ #
1064
+ # args = Getopt::Declare.new(<<-'EOSPEC')
1065
+ # -a Append mode
1066
+ # -b Back-up mode
1067
+ # -bu [ditto]
1068
+ # -c <file> Copy mode
1069
+ # -d [<file>] Delete mode
1070
+ # -e[xec] Execute mode
1071
+ #
1072
+ # [cluster:singles]
1073
+ # EOSPEC
1074
+ #
1075
+ # In the above example, only the <tt>-a</tt> and <tt>-b</tt> parameters may be clustered.
1076
+ # The <tt>-bu</tt> parameter is excluded because it consists of more than one
1077
+ # letter, whilst the <tt>-c</tt> and <tt>-d</tt> parameters are excluded because they
1078
+ # take (or may take, in <tt>-d</tt>'s case) a variable. The <tt>-e[xec]</tt> parameter
1079
+ # is excluded because it may take a trailing punctuator (<tt>[xec]</tt>).
1080
+ #
1081
+ # By comparison, if the directive had been <tt>[cluster: flags]</tt>, then
1082
+ # <tt>-bu</tt> _could_ be clustered, though <tt>-c</tt>, <tt>-d</tt> and <tt>-e[xec]</tt> would
1083
+ # still be excluded since they are not "pure flags").
1084
+ #
1085
+ #
1086
+ # == Strict and non-strict command-line parsing
1087
+ #
1088
+ # "Strictness" in Getopt::Declare refers to the way in which unrecognized
1089
+ # command-line arguments are handled. By default, Getopt::Declare is
1090
+ # "non-strict", in that it simply skips silently over any unrecognized
1091
+ # command-line argument, leaving it in +ARGV+ at the conclusion of
1092
+ # command-line processing (but only if they were originally parsed
1093
+ # from +ARGV+).
1094
+ #
1095
+ # No matter where they came from, the remaining arguments are also available
1096
+ # by calling the +unused+ method on the Getopt::Declare object, after it
1097
+ # has parsed. In a list context, this method returns a list of the
1098
+ # unprocessed arguments; in a scalar context a single string with the unused
1099
+ # arguments concatenated is returned.
1100
+ #
1101
+ # Likewise, there is a +used+ method that returns the arguments that were
1102
+ # successfully processed by the parser.
1103
+ #
1104
+ # However, if a new Getopt::Declare object is created with a
1105
+ # specification string containing the <tt>[strict]</tt> directive (at any
1106
+ # point in the specification):
1107
+ #
1108
+ # args = Getopt::Declare.new(<<-'EOSPEC')
1109
+ #
1110
+ # [strict]
1111
+ #
1112
+ # -a Append mode
1113
+ # -b Back-up mode
1114
+ # -c Copy mode
1115
+ # EOSPEC
1116
+ #
1117
+ # then the command-line is parsed "strictly". In this case, any
1118
+ # unrecognized argument causes an error message (see "DIAGNOSTICS") to
1119
+ # be written to <tt>$stderr</tt>, and command-line processing to (eventually)
1120
+ # fail. On such a failure, the call to Getopt::Declare::new() returns
1121
+ # +nil+ instead of the usual hash.
1122
+ #
1123
+ # The only concession that "strict" mode makes to the unknown is that,
1124
+ # if command-line processing is prematurely terminated via the
1125
+ # +finish+ operator, any command-line arguments which have not yet
1126
+ # been examined are left in +ARGV+ and do not cause the parse to fail (of
1127
+ # course, if any unknown arguments were encountered _before_ the
1128
+ # +finish+ was executed, those earlier arguments _will_ cause
1129
+ # command-line processing to fail).
1130
+ #
1131
+ # The "strict" option is useful when _all_ possible parameters
1132
+ # can be specified in a single Getopt::Declare object, whereas the
1133
+ # "non-strict" approach is needed when unrecognized arguments are either
1134
+ # to be quietly tolerated, or processed at a later point (possibly in a
1135
+ # second Getopt::Declare object).
1136
+ #
1137
+ #
1138
+ # == Parameter dependencies
1139
+ #
1140
+ # Getopt::Declare provides five other directives which modify the
1141
+ # behaviour of the command-line parser in some way. One or more of these
1142
+ # directives may be included in any parameter description. In addition,
1143
+ # the <tt>[mutex:...]</tt> directive may also appear in any usage "decoration"
1144
+ # (see "Usage information").
1145
+ #
1146
+ # Each directive specifies a particular set of conditions that a
1147
+ # command-line must fulfil (for example, that certain parameters may not
1148
+ # appear on the same command-line). If any such condition is violated,
1149
+ # an appropriate error message is printed (see "DIAGNOSTICS").
1150
+ # Furthermore, once the command-line is completely parsed, if any
1151
+ # condition was violated, the program terminates
1152
+ # (whilst still inside Getopt::Declare::new()).
1153
+ #
1154
+ # The directives are:
1155
+ #
1156
+ # * <tt>[tight]</tt>
1157
+ #
1158
+ # Specifies that the usage description should be printed in a tight
1159
+ # form, eliminating as many empty or whitespace only lines as possible.
1160
+ #
1161
+ #
1162
+ # * <tt>[required]</tt>
1163
+ #
1164
+ # Specifies that an argument matching at least one variant of the
1165
+ # corresponding parameter _must_ be specified somewhere in the
1166
+ # command-line. That is, if two or more required parameters share the
1167
+ # same flag, it suffices that _any_ _one_ of them matches an argument
1168
+ # (recall that Getopt::Declare considers all parameter specifications
1169
+ # with the same flag merely to be variant forms of a single "underlying"
1170
+ # parameter).
1171
+ #
1172
+ # If an argument matching a "required" flag is _not_ found in the
1173
+ # command-line, an error message to that effect is issued,
1174
+ # command-line processing fails, and Getopt::Declare::new() returns
1175
+ # +nil+.
1176
+ #
1177
+ #
1178
+ # * <tt>[repeatable]</tt>
1179
+ #
1180
+ # By default, Getopt::Declare objects allow each of their parameters to
1181
+ # be matched only once (that is, once any variant of a particular
1182
+ # parameter matches an argument, _all_ variants of that same parameter
1183
+ # are subsequently excluded from further consideration when parsing the
1184
+ # rest of the command-line).
1185
+ #
1186
+ # However, it is sometimes useful to allow a particular parameter to match
1187
+ # more than once. Any parameter whose description includes the directive
1188
+ # <tt>[repeatable]</tt> is _never_ excluded as a potential argument match, no matter
1189
+ # how many times it has matched previously:
1190
+ #
1191
+ # -nice Increase nice value (linearly if repeated)
1192
+ # [repeatable]
1193
+ # { set_nice( get_nice()+1 ) }
1194
+ #
1195
+ # -w Toggle warnings [repeatable] for the rest
1196
+ # of the command-line
1197
+ # { warn = !warn }
1198
+ #
1199
+ # As a more general mechanism is a <tt>[repeatable]</tt> directive appears in a
1200
+ # specification anywhere other than a flag's description, then _all_ parameters
1201
+ # are marked repeatable:
1202
+ #
1203
+ # [repeatable]
1204
+ #
1205
+ # -nice Increase nice value (linearly if repeated)
1206
+ # { set_nice( get_nice()+1 ) }
1207
+ #
1208
+ # -w Toggle warnings for the rest of the command-line
1209
+ # { warn = !warn }
1210
+ #
1211
+ #
1212
+ # * <tt>[mutex: <flag list>]</tt>
1213
+ #
1214
+ # <tt>[mutex:...]</tt> directive specifies that the parameters whose
1215
+ # flags it lists are mutually exclusive. That is, no two or more of them
1216
+ # may appear in the same command-line. For example:
1217
+ #
1218
+ # -case set to all lower case
1219
+ # -CASE SET TO ALL UPPER CASE
1220
+ # -Case Set to sentence case
1221
+ # -CaSe SeT tO "RAnSom nOTe" CasE
1222
+ #
1223
+ # [mutex: -case -CASE -Case -CaSe]
1224
+ #
1225
+ # The interaction of the <tt>[mutex:...]</tt> and <tt>[required]</tt>
1226
+ # directives is potentially awkward in the case where two "required"
1227
+ # arguments are also mutually exclusive (since the <tt>[required]</tt>
1228
+ # directives insist that both parameters must appear in the command-line,
1229
+ # whilst the <tt>[mutex:...]</tt> directive expressly forbids this).
1230
+ #
1231
+ # Getopt::Declare resolves such contradictory constraints by
1232
+ # relaxing the meaning of "required" slightly. If a flag is marked
1233
+ # "required", it is considered "found" for the purposes of error
1234
+ # checking if it or _any_ other flag with which it is mutually
1235
+ # exclusive appears on the command-line.
1236
+ #
1237
+ # Hence the specifications:
1238
+ #
1239
+ # -case set to all lower case [required]
1240
+ # -CASE SET TO ALL UPPER CASE [required]
1241
+ # -Case Set to sentence case [required]
1242
+ # -CaSe SeT tO "RAnSom nOTe" CasE [required]
1243
+ #
1244
+ # [mutex: -case -CASE -Case -CaSe]
1245
+ #
1246
+ # mean that _exactly_ _one_ of these four flags must appear on the
1247
+ # command-line, but that the presence of any one of them will suffice
1248
+ # to satisfy the "requiredness" of all four.
1249
+ #
1250
+ # It should also be noted that mutual exclusion is only tested for
1251
+ # _after_ a parameter has been completely matched (that is, after the
1252
+ # execution of its actions, if any). This prevents "rejected" parameters
1253
+ # (see "Termination and rejection") from incorrectly generating
1254
+ # mutual exclusion errors. However, it also sometimes makes it necessary
1255
+ # to defer the actions of a pair of mutually exclusive parameters (for
1256
+ # example, if those actions are expensive or irreversible).
1257
+ #
1258
+ #
1259
+ # * <tt>[excludes: <flag list>]</tt>
1260
+ #
1261
+ # The <tt>[excludes:...]</tt> directive provides a "pairwise" version of
1262
+ # mutual exclusion, specifying that the current parameter is mutually exclusive
1263
+ # with all the other parameters lists, but those other parameters are not
1264
+ # mutually exclusive with each other. That is, whereas the specification:
1265
+ #
1266
+ # -left Justify to left margin
1267
+ # -right Justify to right margin
1268
+ # -centre Centre each line
1269
+ #
1270
+ # [mutex: -left -right -centre]
1271
+ #
1272
+ # means that only one of these three justification alternatives can ever be used
1273
+ # at once, the specification:
1274
+ #
1275
+ # -left Justify to left margin
1276
+ # -right Justify to right margin
1277
+ # -centre Centre each line [excludes: -left -right]
1278
+ #
1279
+ # means that <tt>-left</tt> and <tt>-right</tt> can still be used together
1280
+ # (probably to indicate "left _and_ right" justification), but that
1281
+ # neither can be used with <tt>-centre</tt>. Note that the <tt>[excludes:...]</tt>
1282
+ # directive also differs from the <tt>[mutex:...]</tt> in that it is always
1283
+ # connected with a paricular parameter, _implicitly_
1284
+ # using the flag of that parameter as the target of exclusion.
1285
+ #
1286
+ #
1287
+ # * <tt>[requires: -condition]</tt>
1288
+ #
1289
+ # The <tt>[requires]</tt> directive specifies a set of flags which
1290
+ # must also appear in order for a particular flag to be permitted in the
1291
+ # command-line. The condition is a boolean expression, in which the
1292
+ # terms are the flags or various parameters, and the operations are
1293
+ # <tt>&&</tt>, <tt>||</tt>, <tt>!</tt>, and bracketting. For example, the specifications:
1294
+ #
1295
+ # -num Use numeric sort order
1296
+ # -lex Use "dictionary" sort order
1297
+ # -len Sort on length of line (or field)
1298
+ #
1299
+ # -field <N:+i> Sort on value of field <N>
1300
+ #
1301
+ # -rev Reverse sort order
1302
+ # [requires: -num || -lex || !(-len && -field)]
1303
+ #
1304
+ # means that the <tt>-rev</tt> flag is allowed only if either the <tt>-num</tt> or the
1305
+ # <tt>-lex</tt> parameter has been used, or if it is not true that
1306
+ # _both_ the <tt>-len</tt> _and_ the <tt>-field</tt> parameters have been used.
1307
+ #
1308
+ # Note that the operators <tt>&&</tt>, <tt>||</tt> and <tt>!</tt> retain their normal
1309
+ # Ruby precedences.
1310
+ #
1311
+ #
1312
+ # == Parsing from other sources
1313
+ #
1314
+ # Getopt::Declare normally parses the contents of +ARGV+, but can
1315
+ # be made to parse specified files or other sources instead.
1316
+ # To accommodate this, Getopt::Declare::new() takes an optional second parameter, which specifies a file to be parsed.
1317
+ # This second parameter can also be passed directly onto Getopt::Declare::parse()
1318
+ # The parameter may be either:
1319
+ #
1320
+ # * An +IO+ object
1321
+ #
1322
+ # in which case Getopt::Declare::new() reads the corresponding handle until
1323
+ # end-of-file, and parses the resulting text (even if it is an empty string).
1324
+ #
1325
+ # * An ARRAY containing the single string ['-CONFIG']
1326
+ #
1327
+ # in which case Getopt::Declare::new() looks for the files
1328
+ # <tt>ENV['HOME']/.#{progname}rc</tt> and <tt>ENV['PWD']/.#{progname}rc</tt>,
1329
+ # concatenates their contents, and parses that.
1330
+ #
1331
+ # If neither file is found (or if both are inaccessible)
1332
+ # Getopt::Declare::new() immediately returns zero. If a
1333
+ # file is found but the parse subsequently fails, +nil+ is returned.
1334
+ #
1335
+ # * An ARRAY containing the single string ['-BUILD']
1336
+ #
1337
+ # in which case Getopt::Declare::new() builds a parser from the
1338
+ # supplied grammar and returns it, but does not parse anything.
1339
+ # See "The Getopt::Declare::code() method" and
1340
+ # "The Getopt::Declare::parse() method".
1341
+ #
1342
+ # * An ARRAY containing the single string ['-SKIP'] or the single value [nil] or nothing []
1343
+ #
1344
+ # in which case Getopt::Declare::new() immediately returns zero.
1345
+ # This alternative is useful when using a +File+:
1346
+ #
1347
+ # args = Getopt::Declare.new(grammar,
1348
+ # File.new(filename) || ['-SKIP'])
1349
+ #
1350
+ # because it makes explicit what happens if File::new() fails. Of course,
1351
+ # if the <tt>['-SKIP']</tt> alternative were omitted, Getopt::Declare::new would
1352
+ # still return immediately, having found +nil+ as its second argument.
1353
+ #
1354
+ # * An ARRAY containing the word "-ARGV" followed by another ARRAY
1355
+ #
1356
+ # in which case Getopt::Declare::new() treats the array elements as
1357
+ # parameters to parse (as if it were +ARGV+).
1358
+ #
1359
+ # arr = ['-in','opt with spaces']
1360
+ # args = Getopt::Declare.new(grammar, ['-ARGV', arr])
1361
+ #
1362
+ # * Any other ARRAY
1363
+ #
1364
+ # in which case Getopt::Declare::new() treats the array elements as a
1365
+ # list of filenames, concatenates the contents of those files, and parses that.
1366
+ #
1367
+ # If the list does not denote any accessible file(s)
1368
+ # Getopt::Declare::new() immediately returns zero. If matching files
1369
+ # are found, but not successfully parsed, +nil+ is returned.
1370
+ #
1371
+ # * A string
1372
+ #
1373
+ # in which case Getopt::Declare::new() parses that string directly.
1374
+ #
1375
+ # Note that when Getopt::Declare::new() parses from a
1376
+ # source other than +ARGV+, unrecognized arguments are _not_
1377
+ # placed back in +ARGV+.
1378
+ #
1379
+ #
1380
+ # == Using Getopt::Declare objects after command-line processing
1381
+ #
1382
+ # After command-line processing is completed, the object returned by
1383
+ # Getopt::Declare::new() will have the following features:
1384
+ #
1385
+ # * Parameter data
1386
+ #
1387
+ # For each successfully matched parameter, the Getopt::Declare object
1388
+ # will contain a hash element. The key of that element will be the leading flag
1389
+ # or parameter variable name of the parameter.
1390
+ #
1391
+ # The value of the element will be another hash which contains
1392
+ # the names and values of each distinct parameter variable and/or
1393
+ # punctuator which was matched by the parameter. Punctuators generate
1394
+ # string values containing the actual text matched. Other parameter
1395
+ # variables generate values based on their specification (Fixnum,
1396
+ # Float, String). List parameter variables generate Arrays.
1397
+ #
1398
+ # As a special case, if a parameter consists of a single component
1399
+ # (either a single flag or a single parameter variable), then the value for the
1400
+ # corresponding hash key is not another hash, but the actual value matched.
1401
+ #
1402
+ # The following example illustrates the various possibilities:
1403
+ #
1404
+ # args = Getopt::Declare.new( %q{
1405
+ #
1406
+ # -v <value> [etc] One or more values
1407
+ # <infile> Input file [required]
1408
+ # -o <outfiles>... Output files
1409
+ # } )
1410
+ #
1411
+ # if args['-v']
1412
+ # print "Using value: ", args['-v']['<value>']
1413
+ # print " (etcetera)" if args['-v']['etc']
1414
+ # print "\n"
1415
+ # end
1416
+ #
1417
+ # infile = File.new( args['<infile>'] )
1418
+ # data = infile
1419
+ #
1420
+ # for outfile in args['-o']
1421
+ # outfile = File.new(outfile,'w')
1422
+ # outfile.puts "processed"
1423
+ # outfile.close
1424
+ # end
1425
+ #
1426
+ # The values which are assigned to the various hash elements are copied from
1427
+ # the corresponding blocked-scoped variables which are available within
1428
+ # actions. In particular, if the value of any of those block-scoped variables
1429
+ # is changed within an action, that changed value is saved in the hash. For
1430
+ # example, given the specification:
1431
+ #
1432
+ # args = Getopt::Declare.new( %q{
1433
+ #
1434
+ # -ar <r:n> Set aspect ratio (will be clipped to [0..1])
1435
+ # {
1436
+ # r = 0 if r < 0
1437
+ # r = 1 if r > 1
1438
+ # }
1439
+ # } )
1440
+ #
1441
+ # then the value of <tt>args['-ar']</tt> will always be between zero
1442
+ # and one.
1443
+ #
1444
+ # * The +ARGV+ array
1445
+ #
1446
+ # In its "non-strict" mode, once a Getopt::Declare object has
1447
+ # completed its command-line processing, it pushes any unrecognized
1448
+ # arguments back into the emptied command-line array +ARGV+ (whereas
1449
+ # all _recognized_ arguments will have been removed).
1450
+ #
1451
+ # Note that these remaining arguments will be in sequential elements
1452
+ # (starting at <tt>ARGV[0]</tt>), _not_ in their original positions in
1453
+ # +ARGV+.
1454
+ #
1455
+ #
1456
+ # * The Getopt::Declare::usage() method
1457
+ #
1458
+ # Once a Getopt::Declare object is created, its <tt>usage()</tt> method may be called
1459
+ # to explicitly print out usage information corresponding to the specification
1460
+ # with which it was built. See "Usage information" for more details.
1461
+ # If the <tt>usage()</tt> method is called with an argument, that argument is passed
1462
+ # to <tt>exit</tt> after the usage information is printed (the no-argument version of
1463
+ # <tt>usage()</tt> simply returns at that point).
1464
+ #
1465
+ #
1466
+ # * The Getopt::Declare::version() method
1467
+ #
1468
+ # Another useful method of a Getopt::Declare object is <tt>version()</tt>,
1469
+ # which prints out the name of the enclosing program, the last time it
1470
+ # was modified, and the value of <tt>$VERSION</tt>, if it is defined.
1471
+ # Note that this implies that _all_ Getopt::Declare objects in a
1472
+ # single program will print out identical version information.
1473
+ #
1474
+ # Like the <tt>usage()</tt> method, if <tt>version</tt> is passed an argument, it
1475
+ # will exit with that value after printing.
1476
+ #
1477
+ #
1478
+ # * The Getopt::Declare::parse() method
1479
+ #
1480
+ # It is possible to separate the construction of a Getopt::Declare
1481
+ # parser from the actual parsing it performs. If
1482
+ # Getopt::Declare::new() is called with a second parameter ['-BUILD']
1483
+ # (see "Parsing from other sources", it constructs and returns a
1484
+ # parser, without parsing anything.
1485
+ # The resulting parser object can then be used to parse multiple sources,
1486
+ # by calling its <tt>parse()</tt> method.
1487
+ #
1488
+ # Getopt::Declare::parse() takes an optional parameter which specifies
1489
+ # the source of the text to be parsed (it parses +ARGV+ if the
1490
+ # parameter is omitted). This parameter takes the same set of values as the
1491
+ # optional second parameter of Getopt::Declare::new() (see "Parsing
1492
+ # from other sources").
1493
+ #
1494
+ # Getopt::Declare::parse() returns true if the source is located and
1495
+ # parsed successfully. It returns a defined false (zero) if the source is
1496
+ # not located. A +nil+ is returned if the source is located, but not
1497
+ # successfully parsed.
1498
+ #
1499
+ # Thus, the following code first constructs a parsers for a series of
1500
+ # alternate configuration files and the command line, and then parses them:
1501
+ #
1502
+ # # BUILD PARSERS
1503
+ # config = Getopt::Declare::new(config_grammar, ['-BUILD']);
1504
+ # cmdline = Getopt::Declare::new(cmdline_grammar, ['-BUILD']);
1505
+ #
1506
+ # # TRY STANDARD CONFIG FILES
1507
+ # config.parse(['-CONFIG'])
1508
+ #
1509
+ # # OTHERWISE, TRY GLOBAL CONFIG
1510
+ # or config.parse('/usr/local/config/.demo_rc')
1511
+ #
1512
+ # # OTHERWISE, TRY OPENING A FILEHANDLE (OR JUST GIVE UP)
1513
+ # or config.parse(File.new(".config") || ['-SKIP']);
1514
+ #
1515
+ # # NOW PARSE THE COMMAND LINE
1516
+ #
1517
+ # cmdline.parse() or raise "cannot parse";
1518
+ #
1519
+ #
1520
+ # * The Getopt::Declare::code() method
1521
+ #
1522
+ # It is also possible to retreive the command-line parsing code generated
1523
+ # internally by Getopt::Declare::new(). The Getopt::Declare::code()
1524
+ # method returns a string containing the complete command-line processing
1525
+ # code, as a single +begin+ block plus a leading +package+ declaration.
1526
+ #
1527
+ # Getopt::Declare::code() takes as its sole argument a string
1528
+ # containing the complete name of the package (for the leading
1529
+ # +package+ declaration in the generated code). If this string is empty
1530
+ # or undefined, the package name defaults to "main".
1531
+ #
1532
+ # Since the default behaviour of Getopt::Declare::new() is to execute
1533
+ # the command-line parsing code it generates, if the goal is only to
1534
+ # generate the parser code, the optional second ['-BUILD'] parameter
1535
+ # (see "Parsing from other sources") should be specified when calling
1536
+ # Getopt::Declare::new().
1537
+ #
1538
+ # For example, the following program "inlines" a Getopt::Declare
1539
+ # specification, by extracting it from between the first "=for
1540
+ # Getopt::Declare" and the next "=cut" appearing on +$stdin+:
1541
+ #
1542
+ # =begin
1543
+ # Just type in something, like:
1544
+ #
1545
+ # =for Getopt::Declare
1546
+ #
1547
+ # -a Append mode
1548
+ # =cut
1549
+ #
1550
+ # =end
1551
+ #
1552
+ # $/ = '=cut'
1553
+ # if t = $stdin.readline
1554
+ # t.sub!( /^=for\s+Getopt::Declare\s*\n(.*?)\n=cut/esm ) {
1555
+ # '(self,source) = []'+encode("#$1") }
1556
+ # end
1557
+ #
1558
+ # print t
1559
+ #
1560
+ #
1561
+ # Note that the generated inlined version expects to find a lexical variable
1562
+ # named +source+, which tells it what to parse (this variable is
1563
+ # normally set by the optional parameters of Getopt::Declare::new() or
1564
+ # Getopt::Declare::parse()).
1565
+ #
1566
+ # The inlined code leaves all extracted parameters in the lexical
1567
+ # variable +self+ and the does not autogenerate help or version flags
1568
+ # (since there is no actual Getopt::Declare object in the inlined code
1569
+ # through which to generate them).
1570
+ #
1571
+ # = AUTOGENERATED FEATURES
1572
+ #
1573
+ # == Usage information
1574
+ #
1575
+ # The specification passed to Getopt::Declare::new is used (almost
1576
+ # verbatim) as a "usage" display whenever usage information is
1577
+ # requested.
1578
+ #
1579
+ # Such requests may be made either by specifying an argument matching
1580
+ # the help parameter (see "Help parameters") or by explicitly calling
1581
+ # the Getopt::Declare::usage() method (through an action or after
1582
+ # command-line processing):
1583
+ #
1584
+ # args = Getopt::Declare.new( %q{
1585
+ #
1586
+ # -usage Show usage information and exit
1587
+ # { usage(0) }
1588
+ #
1589
+ # +usage Show usage information at end of program
1590
+ # } )
1591
+ #
1592
+ # # PROGRAM HERE
1593
+ #
1594
+ # args.usage if args['+usage'];
1595
+ #
1596
+ #
1597
+ # The following changes are made to the original specification before
1598
+ # it is displayed:
1599
+ #
1600
+ # * All actions and comments are deleted,
1601
+ #
1602
+ # * any <tt>[ditto]</tt> directive is converted to an appropriate set of "ditto" marks,
1603
+ #
1604
+ # * any text in matching square brackets (including any directive) is deleted,
1605
+ #
1606
+ # * any parameter variable type specifier (":i", ":n", ":/pat/", etc.) is deleted.
1607
+ #
1608
+ # Otherwise, the usage information displayed retains all the formatting
1609
+ # present in the original specification.
1610
+ #
1611
+ # In addition to this information, if the input source is +ARGV+,
1612
+ # Getopt::Declare displays three sample command-lines: one indicating
1613
+ # the normal usage (including any required parameter variables), one
1614
+ # indicating how to invoke help (see "Help parameters"), and one
1615
+ # indicating how to determine the current version of the program (see
1616
+ # "Version parameters").
1617
+ #
1618
+ # The usage information is printed to <tt>$stdout</tt> and (since Getopt::Declare
1619
+ # tends to encourage longer and better-documented parameter lists) if
1620
+ # the IO::Pager> package is available, an IO::Pager> object is used to
1621
+ # page out the entire usage documentation.
1622
+ #
1623
+ # == Usage "decoration"
1624
+ #
1625
+ # It is sometimes convenient to add other "decorative" features to a
1626
+ # program's usage information, such as subheadings, general notes,
1627
+ # separators, etc. Getopt::Declare accommodates this need by ignoring
1628
+ # such items when interpreting a specification string, but printing them
1629
+ # when asked for usage information.
1630
+ #
1631
+ # Any line which cannot be interpreted as either a parameter
1632
+ # definition, a parameter description, or a parameter action, is treated
1633
+ # as a "decorator" line, and is printed verbatim (after any square
1634
+ # bracketted substrings have been removed from it).
1635
+ #
1636
+ # The key to successfully decorating Getopt::Declare usage
1637
+ # information is to ensure that decorator lines are separated from
1638
+ # any preceding parameter specification, either by an action or by an
1639
+ # empty line. In addition, like a parameter description, a decorator
1640
+ # line cannot contain a tab character after the first non-whitespace
1641
+ # character (because it would then be treated as a parameter
1642
+ # specification).
1643
+ #
1644
+ # The following specification demonstrates various forms of usage
1645
+ # decoration. In fact, there are only four actual parameters (<tt>-in</tt>,
1646
+ # <tt>-r</tt>, <tt>-p</tt>, and <tt>-out</tt>) specified. Note in particular that _leading_ tabs
1647
+ # are perfectly acceptible in decorator lines.
1648
+ #
1649
+ # args = Getopt::Declare.new(<<-'EOPARAM');
1650
+ #
1651
+ # ============================================================
1652
+ # Required parameter:
1653
+ #
1654
+ # -in <infile> Input file [required]
1655
+ #
1656
+ # ------------------------------------------------------------
1657
+ #
1658
+ # Optional parameters:
1659
+ #
1660
+ # (The first two are mutually exclusive) [mutex: -r -p]
1661
+ #
1662
+ # -r[and[om]] Output in random order
1663
+ # -p[erm[ute]] Output all permutations
1664
+ #
1665
+ # ---------------------------------------------------
1666
+ #
1667
+ # -out <outfile> Optional output file
1668
+ #
1669
+ # ------------------------------------------------------------
1670
+ # Note: this program is known to run very slowly of files with
1671
+ # long individual lines.
1672
+ # ============================================================
1673
+ # EOPARAM
1674
+ #
1675
+ #
1676
+ # == Help parameters
1677
+ #
1678
+ # By default, Getopt::Declare automatically defines _all_ of the following
1679
+ # parameters:
1680
+ #
1681
+ # -help Show usage information [undocumented]
1682
+ # { usage(0) }
1683
+ # -Help [ditto]
1684
+ # -HELP [ditto]
1685
+ # --help [ditto]
1686
+ # --Help [ditto]
1687
+ # --HELP [ditto]
1688
+ # -h [ditto]
1689
+ # -H [ditto]
1690
+ #
1691
+ # Hence, most attempts by the user to get help will automatically work
1692
+ # successfully.
1693
+ #
1694
+ # Note however that, if a parameter with any of these flags is
1695
+ # explicitly specified in the string passed to Getopt::Declare::new(),
1696
+ # that flag (only) is removed from the list of possible help flags. For
1697
+ # example:
1698
+ #
1699
+ # -w <pixels:+i> Specify width in pixels
1700
+ # -h <pixels:+i> Specify height in pixels
1701
+ #
1702
+ # would cause the <tt>-h</tt> help parameter to be removed (although help
1703
+ # would still be accessible through the other seven alternatives).
1704
+ #
1705
+ #
1706
+ # == Version parameters
1707
+ #
1708
+ # Getopt::Declare also automatically creates a set of parameters which can be
1709
+ # used to retreive program version information:
1710
+ #
1711
+ # -version Show version information [undocumented]
1712
+ # { version(0) }
1713
+ # -Version [ditto]
1714
+ # -VERSION [ditto]
1715
+ # --version [ditto]
1716
+ # --Version [ditto]
1717
+ # --VERSION [ditto]
1718
+ # -v [ditto]
1719
+ # -V [ditto]
1720
+ #
1721
+ # As with the various help commands, explicitly specifying a parameter
1722
+ # with any of the above flags removes that flag from the list of version
1723
+ # flags.
1724
+ #
1725
+ #
1726
+ # = DIAGNOSTICS
1727
+ #
1728
+ # Getopt::Declare may issue the following diagnostics whilst parsing a
1729
+ # command-line. All of them are fatal (the first five, instantly so):
1730
+ #
1731
+ # * "Error: bad Getopt::Declare parameter variable specification near %s"
1732
+ #
1733
+ # A matching pair of angle brackets were specified as part of a
1734
+ # parameter definition, but did not form a valid parameter variable
1735
+ # specification (that is, it wasn't in the form: <_name_> or
1736
+ # <_name_:_type_>).
1737
+ #
1738
+ # * "Error: bad type in Getopt::Declare parameter variable specification near %s"
1739
+ #
1740
+ # An unknown type specifier was used in a parameter variable type suffix.
1741
+ #
1742
+ # * "Error: bad action in Getopt::Declare specification:\n %s"
1743
+ #
1744
+ # A Perl syntax error was detected in the indicated action.
1745
+ #
1746
+ # * "Error: unattached action in Getopt::Declare specification:\n %s"
1747
+ #
1748
+ # An action was found for which there was no preceding parameter specification.
1749
+ # This usually occurs because the trailing tab was omitted from the preceding
1750
+ # parameter specification.
1751
+ #
1752
+ # * "Error: incomplete action in Getopt::Declare specification:\n %s"
1753
+ #
1754
+ # An action was found, but it was missing one or more closing '}'s.
1755
+ #
1756
+ # * "Error: bad condition in directive [requires: %s]\n"
1757
+ #
1758
+ # The condition specified as part of the indicated <tt>[requires:...]</tt>
1759
+ # directive was not a well-formed boolean expression. Common problems
1760
+ # include: omitting a <tt>&&</tt>/<tt>||</tt> operator between two flags,
1761
+ # mismatched brackets, or using <tt>and</tt>/<tt>or</tt> instead of <tt>&&</tt>/<tt>||</tt>.
1762
+ #
1763
+ # * "Error: in generated command-line parser code:\n %s"
1764
+ #
1765
+ # Either there was a Ruby syntax error in one some action (which was
1766
+ # not caught by the previous diagnostic), or (less likely) there is a
1767
+ # bug in the code generator inside Getopt::Declare.
1768
+ #
1769
+ # * "Error: incorrect specification of %s parameter"
1770
+ #
1771
+ # The flag for the indicated parameter was found, but the argument did not
1772
+ # then match any of that parameter's variant syntaxes.
1773
+ #
1774
+ # * "Error: parameter %s not allowed with %s"
1775
+ #
1776
+ # Two mutually exclusive flags were specified together.
1777
+ #
1778
+ # * "Error: required parameter %s not found"
1779
+ #
1780
+ # No argument matching the specified "required" parameter was found
1781
+ # during command-line processing.
1782
+ #
1783
+ # * "Error: parameter %s can only be specified with %s"
1784
+ #
1785
+ # The indicated parameter has a <tt>[requires:...]</tt> directive, which
1786
+ # was not satisfied.
1787
+ #
1788
+ # * "Error: unknown command-line argument (%s)"
1789
+ #
1790
+ # A command-line argument was encountered which did not match any
1791
+ # specified parameter. This diagnostic can only only appear if the
1792
+ # "strict" option is in effect.
1793
+ #
1794
+ # * "Error: in parameter %s (%s must be an integer greater than zero)"
1795
+ #
1796
+ # A parameter variable in the indicated parameter was declared with the
1797
+ # type ":+i" (or a type derived from it), but the corresponding
1798
+ # argument was not a positive, non-zero integer.
1799
+ #
1800
+ # * "Error: in parameter %s (%s must be a number greater than zero)"
1801
+ #
1802
+ # A parameter variable in the indicated parameter was declared with the
1803
+ # type ":+n" (or a type derived from it), but the corresponding
1804
+ # argument was not a positive, non-zero number.
1805
+ #
1806
+ # * "Error: in parameter %s (%s must be an positive integer)"
1807
+ #
1808
+ # A parameter variable in the indicated parameter was declared with the
1809
+ # type ":0+i" (or a type derived from it), but the corresponding
1810
+ # argument was not a positive integer.
1811
+ #
1812
+ # * "Error: in parameter %s (%s must be a positive number)"
1813
+ #
1814
+ # A parameter variable in the indicated parameter was declared with the
1815
+ # type ":0+n" (or a type derived from it), but the corresponding
1816
+ # argument was not a positive number.
1817
+ #
1818
+ # = AUTHORS
1819
+ #
1820
+ # Damian Conway (damian@conway.org) Perl Implementation.
1821
+ #
1822
+ # Gonzalo Garramuno (GGarramuno@aol.com) Ruby Port, Minor Bug Fixes,
1823
+ # Inline docs, and :d stdtype.
1824
+ ##
1825
+ # = BUGS AND ANNOYANCES
1826
+ #
1827
+ # There are undoubtedly serious bugs lurking somewhere in this code.
1828
+ #
1829
+ # If nothing else, it shouldn't take 1500 lines to explain a
1830
+ # package that was designed for intuitive ease of use!
1831
+ #
1832
+ # Bug reports and other feedback are most welcome.
1833
+ #
1834
+ #
1835
+ # = COPYRIGHT
1836
+ #
1837
+ # Ruby Port:
1838
+ # Copyright (c) 2004, Gonzalo Garramuno. All Rights Reserved.
1839
+ # This package is free software. It may be used, redistributed
1840
+ # and/or modified under the terms of the Perl Artistic License
1841
+ # (see http://www.perl.com/perl/misc/Artistic.html)
1842
+ #
1843
+ # Original Perl Code:
1844
+ # Copyright (c) 1997-2000, Damian Conway. All Rights Reserved.
1845
+ # This package is free software. It may be used, redistributed
1846
+ # and/or modified under the terms of the Perl Artistic License
1847
+ # (see http://www.perl.com/perl/misc/Artistic.html)
1848
+ #
1849
+ # This Getopt::Declare module relies on a custom version of DelimScanner.rb,
1850
+ # which is roughly a port of Perl's Text::Balanced.
1851
+ # The main change added to that library was to add returning :suffix to several
1852
+ # functions. DelimScanner.rb is:
1853
+ #
1854
+ # Copyright (c) 2002, 2003 The FaerieMUD Consortium. Most rights reserved.
1855
+ #
1856
+ # This work is licensed under the Creative Commons Attribution License. To view
1857
+ # a copy of this license, visit http://creativecommons.org/licenses/by/1.0 or
1858
+ # send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California
1859
+ # 94305, USA.
1860
+
1861
+