Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 162007 - ksh-93 doesn't support + command line options
Summary: ksh-93 doesn't support + command line options
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: ksh
Version: 4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Karsten Hopp
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-29 01:45 UTC by Ian Mortimer
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-06-30 13:30:11 UTC


Attachments (Terms of Use)

Description Ian Mortimer 2005-06-29 01:45:46 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4

Description of problem:
The man page for ksh says that + command line options are supported by the builtin
getopts:

getopts [  -a name ] optstring vname [ arg ... ]
              ...
              parameters are used.  An option argument begins with a + or a -.
              An  option not beginning with + or - or the argument -- ends the
              options.
                          ...  The  option letter will be
              prepended with a + when arg begins with a +.

However + options on the command line are not being recognized as options.

Version-Release number of selected component (if applicable):
ksh-20050202-1

How reproducible:
Always

Steps to Reproduce:
1. write a simple ksh script with a getopts option loop
2. run it with a + command line option
3.
  

Actual Results:  The + option is not recognized as an option but is treated as an ordinary argument.

Expected Results:  The + option should have been recognized as an option and prepended with a + as the man page describes.

Additional info:

This simple script shows the problem:

while getopts :n opt
do
        case $opt in
                n) print "-n selected";;
                +n) print "+n selected";;
        esac
done
shift $(($OPTIND-1))
print "arguments: $*"

When run with pdksh or other ksh implementations with a +n option it produces
the output "+n selected" as expected.  When run with the ksh shipped with FC4
(ksh-93) it produces "arguments: +n" from the final print statement.

The POSIX standard doesn't allow + arguments (it seems) but removing it from ksh
breaks backward compatibility and cross-platform compatibility since it's supported in pdksh and commercial ksh implementations.

Comment 1 Karsten Hopp 2005-06-30 13:30:11 UTC
ksh's man page doesn't cover everything, please use getopts own man page:
ksh> getopts --??

You'll find this section:
If the leading character of optstring is +, then arguments beginning with +
will also be considered options.

A leading : character or a : following a leading + in optstring affects the
way errors are handled. 

If you rewrite your testcase as

while getopts +:n opt
do
        case $opt in
                n) print "-n selected";;
                +n) print "+n selected";;
        esac
done
shift $(($OPTIND-1))
print "arguments: $*"

everything works as expected.

Comment 2 Ian Mortimer 2005-06-30 22:29:37 UTC
Thanks for the quick solution.

That works and is portable (although not mentioned in the man pages for pdksh
and other ksh implementations).

However it still breaks backward and cross-platform compatibility since the
syntax without the leading + works with other ksh implementations (including pdksh).


Note You need to log in before you can comment on or make changes to this bug.