#30 option with argument in angle brackets are not recognized.

closed-fixed
None
5
2005-02-17
2005-02-16
No

Options in options list are not recognized if the option
argument is enclosed in angle brackets.

The following is recognized as option, but the angle
bracket are included in the output

-m <MODELS>, --models <MODELS>
Select the models to query. Useful if the
entity
contains more than one model
(MODEL/ENDMDL blocks).
MODELS is an integers or integer range
in N1-N2
format. If not specified, query all the
models.

The following is recognized as an ordinary paragraph.

--point <X Y Z> Process the point X Y Z in the entity
space. Many
points can be sampled by selecting this
option more
than once.

Discussion

  • Daniele Varrazzo

    Logged In: YES
    user_id=1053920

    ... of course submision destroyed indentation. Here is an
    attached file showing the bug: try

    rst2html.py cmdlinebug.txt cmdlinebug.html

    and verify cmdlinebug.html.

     
  • Daniele Varrazzo

    shows the bug in option parsing.

     
    Attachments
  • Felix Wiemann

    Felix Wiemann - 2005-02-17
    • status: open --> closed-fixed
     
  • Felix Wiemann

    Felix Wiemann - 2005-02-17
    • assigned_to: nobody --> felixwiemann
     
  • Felix Wiemann

    Felix Wiemann - 2005-02-17

    Logged In: YES
    user_id=1014490

    > The following is recognized as option, but the angle
    > bracket are included in the output
    >
    > -m <MODELS>, --models <MODELS>

    That's not a bug. If you don't want angle brackets, don't
    write angle brackets.

    > [Not recognized as option strings:]
    > -o <[PATH]FILENAME.EXT>, --output <[PATH]FILENAME.EXT>

    That's a bug indeed -- thank you! Just fixed it; please
    grab a current snapshot from:
    http://docutils.sourceforge.net/docutils-snapshot.tgz

    > --residues <R1 [R2 [...]]>

    That's a bug, too, but I haven't been able to fix it now.
    Added to BUGS.txt
    (http://docutils.sf.net/BUGS.html#option-strings-with-spaces).

     
  • Daniele Varrazzo

    Logged In: YES
    user_id=1053920

    >> The following is recognized as option, but the angle
    >> bracket are included in the output
    >>
    >> -m <MODELS>, --models <MODELS>
    >
    > That's not a bug. If you don't want angle brackets, don't
    > write angle brackets.
    Ths is not as important as the other cases: i added it
    for "completeness". But is is a bug indeed.

    I'm not a lawyer, but the specs say an option argument:
    (1) Begins with a letter ([a-zA-Z]) and subsequently consists
    of letters, numbers, underscores and hyphens ([a-zA-Z0-9_-
    ]).
    (2) Begins with an open-angle-bracket (<) and ends with a
    close-angle-bracket (>); any characters except angle
    brackets are allowed internally.

    <MODELS> doesn't mach the first pattern (it doesn't match
    the pattern [a-zA-Z][a-zA-Z0-9_-]*), but it positively falls in
    the second case. So i expect it is treated as such: angle
    brackets removed.

    I wrote a script that takes a optparse.OptionParser as input
    and generates the reST version of its help: having a single
    syntax to express option args would be handy. Of course is
    easy to avoid emitting angle brackets for arguments matching
    the (1) pattern; nevertheless you should consider either
    changing the parser behaviour (recognizing the pattern <[^>]
    +> as an argument) or changing the specs (which is usually
    easier...)

    Regards

     
  • David Goodger

    David Goodger - 2005-02-19

    Logged In: YES
    user_id=7733

    The "--point <X Y Z>" form now works in CVS, and the snapshot is
    updated. This bug can now be considered *completely* fixed and
    *really* closed ;-)

    [Daniele Varrazzo]
    >>> The following is recognized as option, but the angle
    >>> bracket are included in the output
    >>>
    >>> -m <MODELS>, --models <MODELS>

    [Felix Wiemann]
    >> That's not a bug. If you don't want angle brackets, don't
    >> write angle brackets.

    [Daniele Varrazzo]
    > Ths is not as important as the other cases: i added it
    > for "completeness". But is is a bug indeed.

    I have to agree with Felix: that's not a bug. The spec says
    "begins
    with < and ends with >", but doesn't say anything about
    trimming them.
    If we *did* trim the characters that the option argument
    "begins with"
    and "ends with" in the bracketed form (2), shouldn't we also
    trim
    non-bracketed form (1)? After all, the wording for both
    forms is
    identical.

    The angle-brackets will stay in the output.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks