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
