getopt-declare 1.28 → 1.29

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