Re: [patch] sh.1 getopts inaccurate
I also agree. > hi > > I'm not familiar with getopts, first time I use it and the man page was > confusing. It says "a colon following an option indicates it may take an > argument". > I understand this as: if I use the string "s:" then I can use "-s" or "-s > something" as it **may** take an argument. > > But if you use "s:", getopts reports an error "-s requires argument". > > I propose to modify that sentence (not sure for the s in requires). > > Index: sh.1 > === > RCS file: /data/cvs/src/bin/ksh/sh.1,v > retrieving revision 1.149 > diff -u -p -r1.149 sh.1 > --- sh.1 28 Sep 2018 18:32:39 - 1.149 > +++ sh.1 29 Nov 2018 06:44:50 - > @@ -495,7 +495,7 @@ to the index of the next variable to be > The string > .Ar optstring > contains a list of acceptable options; > -a colon following an option indicates it may take an argument. > +a colon following an option indicates it requires an argument. > If an option not recognised by > .Ar optstring > is found, > > > Example to reproduce it: > > #!/bin/sh > while getopts s:? args > do > case "$args" in > s) VALUE=${OPTARG} ;; > *) exit 0 ;; > esac > done > echo $VALUE > > > solene@t480 ~/notes/perso $ ./bug.sh -s > ./bug.sh[9]: -`s' requires argument > solene@t480 ~/notes/perso $ ./bug.sh -s value > value >
Re: [patch] sh.1 getopts inaccurate
On Wed, Nov 28, 2018 at 10:52 PM Solene Rapenne wrote: > I'm not familiar with getopts, first time I use it and the man page was > confusing. It says "a colon following an option indicates it may take an > argument". > I understand this as: if I use the string "s:" then I can use "-s" or "-s > something" as it **may** take an argument. > > But if you use "s:", getopts reports an error "-s requires argument". > > I propose to modify that sentence (not sure for the s in requires). > > Index: sh.1 > === > RCS file: /data/cvs/src/bin/ksh/sh.1,v > retrieving revision 1.149 > diff -u -p -r1.149 sh.1 > --- sh.128 Sep 2018 18:32:39 - 1.149 > +++ sh.129 Nov 2018 06:44:50 - > @@ -495,7 +495,7 @@ to the index of the next variable to be > The string > .Ar optstring > contains a list of acceptable options; > -a colon following an option indicates it may take an argument. > +a colon following an option indicates it requires an argument. > If an option not recognised by > .Ar optstring > is found, > "requires" is correct there. ok guenther@
[patch] sh.1 getopts inaccurate
hi I'm not familiar with getopts, first time I use it and the man page was confusing. It says "a colon following an option indicates it may take an argument". I understand this as: if I use the string "s:" then I can use "-s" or "-s something" as it **may** take an argument. But if you use "s:", getopts reports an error "-s requires argument". I propose to modify that sentence (not sure for the s in requires). Index: sh.1 === RCS file: /data/cvs/src/bin/ksh/sh.1,v retrieving revision 1.149 diff -u -p -r1.149 sh.1 --- sh.128 Sep 2018 18:32:39 - 1.149 +++ sh.129 Nov 2018 06:44:50 - @@ -495,7 +495,7 @@ to the index of the next variable to be The string .Ar optstring contains a list of acceptable options; -a colon following an option indicates it may take an argument. +a colon following an option indicates it requires an argument. If an option not recognised by .Ar optstring is found, Example to reproduce it: #!/bin/sh while getopts s:? args do case "$args" in s) VALUE=${OPTARG} ;; *) exit 0 ;; esac done echo $VALUE solene@t480 ~/notes/perso $ ./bug.sh -s ./bug.sh[9]: -`s' requires argument solene@t480 ~/notes/perso $ ./bug.sh -s value value