Handling options with optional arguments with getopts
‐‐‐ Original Message ‐‐‐
On Saturday, August 28, 2021 4:49 PM, Robert Elz wrote:
> Date:Sat, 28 Aug 2021 15:26:28 +
> From: hancooper
>
> Message-ID:
>
>
>
> | Would the code break if I use shortopts="Vuhv:s" (allows getopts
> | to issue errors, not in silent mode) but also have the (":") and
> | ("?") checks inside the case statement?
>
> Not break, but the ':' case will be a waste of space, as that cannot
> happen in that case, the ':' return only happens with the leading ':'
> in the opts string (I didn't bother to quote that part of the spec last
> time, as it wasn't immediately relevant).
The reason for the code is that it would be easy to use either Vuhv:s
or :Vuhv:s without having to modify the case statements when using Vuhv:s.
> | As so
>
> That should work, the ":" case (as above) won't ever happen.
>
> There's also a whole lot of meaningless quoting that you could delete
> (shell doesn't have strings ... or perhaps that is better stated as
> everything is a string, quotes aren't needed to make something into one -
> quotes are only needed where some shell magic character appears (to literally
> match the '?' that needs to be quoted) or to protect the contents of
> an expansion from further processing.
>
> So:
>
> | local shortopts="Vuhvs"
>
> quotes there are useless.
>
> | while getopts $shortopts arg; do
>
> but (double-)quoting around $shortopts can be a good idea,
> as anything that results from an expansion is subject to
> pathname expansion and field splitting ... that's not going to
> be an issue here, as the value of shortopts is known, and
> contains nothing which would trigger pathname expansion, and
> is unlikely to result in field splitting either (depends on
> the value of IFS, so it could happen) - but always quoting
> things like that is a good idea. Greg's FAQ would tell you
> it is essential ... I don't go quite that far (just 95% of the way).
>
> | case $arg in
>
> but quotes aren't essential there, because the word in a case statement
> isn't subject to those extra expansions (it wouldn't hurt to (double-)quote
> it though, for consistency)
>
> | ("V")
>
> Those quotes are useless (all the useless quotes here are also harmless,
> so if you really like the look of them, they do no harm - but they're
> unconventional in sh code).
>
> | printf '%s\n' "Version"
>
> The \ needs quoting, one way or another, so the single quotes
> are reasonable ( %s\\n would be another way ) but the double
> quotes around Version are meaningless. [Aside: if you are going
> to add meaningless quoting, using single quotes is generally
> better, the shell doesn't need to parse the insides of a single
> quoted word nearly as much as a double quoted one, so processing
> single quoted strings is marginally faster - but probably so marginally
> that you'd never be able to measure the difference].
>
> | ("v")
> | vb="$OPTARG"
>
> That's another place (the assignment) where the quotes aren't really
> needed, as neither pathname expansion nor field splitting occur there,
> but again, for consistency, keeping them can be a good idea.
>
> | ("?")
> | printf '%s\n' "Option not recognised by shortopts"
> | printf '%s\n'pfm "Invalid option: -${OPTARG}."
> | break
> | ;;
>
> You don't need the error messages, getopts will have issued
> one already, the point of the '?' case in this scenario is
> to allow the code to clean up (which the "break" is intended
> to achieve I suspect, but that's rarely the right choice, as
> it just falls out of the while loop and continues executing
> the script ... exit is a more common thing to do there.
>
> | (*)
> | printf '%s\n' "Invoke \`getopts_test -h' for details."
> | ;;
>
> That one is missing a break (or more likely, exit) which is likely
> needed for the same reason as the previous one. But since the var
> set by getopts only ever returns one char, unquoting the ? in the
> previous pattern would allow these two cases to be combined, the '?'
> (if unquoted) would match anything not previously matched, both
> a literal '?' for the error case, but also some other option where
> the char was added to the opts string (shortopts here) but the
> case pattern to handle it was forgotten.
>
> kre
Handling options with optional arguments with getopts
‐‐‐ Original Message ‐‐‐
On Friday, August 27, 2021 8:52 PM, Robert Elz wrote:
> Date:Fri, 27 Aug 2021 17:20:39 +
> From:nigelberlinguer
>
> Message-ID:
>
>
>
> | It should be noted though, that the POSIX requirement by "Guideline 7"
> | is not guided by actual portability in the technical sense but by a
> | rule written in the POSIX standard.
>
> Those guidelines serve two purposes - they indicate what should be the
> arg format for posix standard utilities, and they specify what must be
> handled for those cases where they are specified to apply (as in getopts).
>
> | Perhaps there should be an update
> | to POSIX on what is actually portable or not
>
> There are constantly updates to POSIX - but I don't see anything likely to
> change in this area. "Works in bash" is not the definition of portable.
>
> In general, what POSIX specifies (with just a few exceptions, which
> often don't matter) is what you can rely upon working - as soon as you
> start using anything not specified by POSIX, or explicitly said
> to be unspecified or undefined, then you cannot really expect the
> code (including scripts) to work on other systems, and perhaps not
> even on later versions of the system you're using.
>
> | I have seen the following workaround, where tho options that allows an
> | optional argument is defined with no arguments in shortopts.
> |
> | local vb=1 sort=0
> |
> | local OPTIND OPTARG
> | local shortopts="Vuhvs"
> | while getopts $shortopts arg; do
> | case $arg in
> | ("V") printf '%s\n' "Version" ; return ;;
> | ("u") printf '%s\n' "usage" ; return ;;
> | ("h") printf '%s\n' "help" ; return ;;
> | ("v")
> | # Allows argument to be optional.
> | # Defines option with no arguments in shortopts.
> | nextarg=${!OPTIND}
> | if [[ (-n "$nextarg") && ("$nextarg" != -*) ]] ; then
> | OPTIND=$((OPTIND + 1))
> | vb="$nextarg"
>
> Aside from using bash private syntax (which could be mostly avoided there
> if one had the desire) that kind of use of OPTIND is certainly not portable.
> The only defined write operation on OPTIND is to set it to 1.
>
> Further, even where something like that does work, it provides no mechanism
> for the arg to the option to begin with a '-', which might not matter in
> some cases, but certainly isn't very general.
>
> | I also wonder whether the "shift" command is used with `getopts`.
>
> No. Or not inside the loop. Once the loop is finished, the code
> should usually do
>
> shift $(( ${OPTIND} - 1 ))
>
> to remove all the args that have been processed by getopts - but that's
> not always required (there are other ways to get the remaining args, if
> any, if they are needed, but doing the shift means the remaining args are
> "$@").
>
> Altering the arg list (in any way at all) during getopts processing produces
> unspecified results.
>
> | I see people use the `shift` command when doing their own parsing;
>
> Yes, that's often the easiest way to do it for hand rolled parsing
> (it means that what you're currently examining is always $1, and so
> there's no need to write messy code to get at a variable positional param,
> which is not trivial to do portably).
>
> | and when others use `getopt`.
>
> getopt is obsolete, and has numerous failure modes. But yes, shift
> is used when using getopt (getopt is generally implemented as an
> external command, and so cannot affect the state of the shell, including
> any shell variables, getopts is always a shell builtin command).
>
> kre
Would the code break if I use shortopts="Vuhv:s" (allows getopts to issue
errors, not in silent mode)
but also have the (":") and ("?") checks inside the case statement?
As so
local OPTIND OPTARG
local shortopts="Vuhvs"
while getopts $shortopts arg; do
case $arg in
("V")
printf '%s\n' "Version"
return
;;
("u")
printf '%s\n' "Usage"
return
;;
("h")
printf '%s\n' "Help"
return
;;
("v")
vb="$OPTARG"
;;
#.
("s") sort=1 ;;
#.
(":")
printf '%s\n' "Argument not supplied"
printf '%s\n' "-${OPTARG} requires an argument."
break
;;
("?")
printf '%s\n' "Option not recognised by shortopts"
printf '%s\n'pfm "Invalid option: -${OPTARG}."
break
;;
(*)
printf '%s\n' "Invoke \`getopts_test -h' for details."
;;
esac
done
shift $(( OPTIND - 1 ))
Exclamation mark when using character classes
‐‐‐ Original Message ‐‐‐
On Saturday, August 21, 2021 11:25 AM, Ilkka Virta wrote:
> What do you get with [![:digit:]] then? It seems to work the same with both
> ! and ^ here:
>
> $ now=$EPOCHREALTIME
> $ echo "${now%[^[:digit:]]}" "${now#[^[:digit:]]}"
> 1629544775 183030
> $ echo "${now%[![:digit:]]}" "${now#[![:digit:]]}"
> 1629544775 183030
>
> On Fri, Aug 20, 2021 at 10:30 PM hancooper via Bug reports for the GNU
> Bourne Again SHell bug-bash@gnu.org wrote:
>
> > I am using EPOCHREALTIME and then computing the corresponding human
> > readable form, that can handle
> > changes in locale
> > now=$EPOCHREALTIME
> > printf -v second '%(%S)T.%s' "${now%[^[:digit:]]}" "${now#[^[:digit:]]}"
> > printf -v minute '%(%M)T' "${now%[^[:digit:]]}"
> > printf -v hour '%(%H)T' "${now%[^[:digit:]]}"Incidentally, [![:digit:]]
> > does not work there, you need to use the
> > POSIX-specified caret (^) instead of an
> > exclamation mark when using character classes. I'm not sure if this is
> > intentional or a bug in bash; man
> > page doesn't seem to mention it.
I got it backwards. POSIX specifies ! for use in globs, and bash
permits ^ as an extension, for people who are used to ^ from regular
expressions.
Had "tested" this using grep or [[ =~ ]] or something else that uses
regular expressions, not globs.
Exclamation mark when using character classes
‐‐‐ Original Message ‐‐‐
On Friday, August 20, 2021 8:00 PM, Kerin Millar wrote:
> On Fri, 20 Aug 2021 19:28:25 +
> hancooper via Bug reports for the GNU Bourne Again SHell bug-bash@gnu.org
> wrote:
>
> > I am using EPOCHREALTIME and then computing the corresponding human
> > readable form, that can handle
> > changes in locale
> > now=$EPOCHREALTIME
> > printf -v second '%(%S)T.%s' "${now%[^[:digit:]]}" "${now#[^[:digit:]]}"
> > printf -v minute '%(%M)T' "${now%[^[:digit:]]}"
> > printf -v hour '%(%H)T' "${now%[^[:digit:]]}"Incidentally, [![:digit:]]
> > does not work there, you need to use the POSIX-specified caret (^) instead
> > of an
> > exclamation mark when using character classes. I'm not sure if this is
> > intentional or a bug in bash; man
> > page doesn't seem to mention it.
>
> "If an open bracket introduces a bracket expression as in XBD RE Bracket
> Expression, [...] the character ( '!' ) shall replace the
> character ( '^' ) in its role in a non-matching list in the
> regular expression notation."
>
> So says POSIX on the matter of pattern matching notation. In other words,
> only the exclamation-mark is POSIX-specified, although bash happens to
> tolerate the use of a circumflex, in which case it should behave in the exact
> same way. Are you able to show a concrete example of one behaving differently
> from the other?
I could do with some help separating the integer and the fractional part from a
floating point number,
particularly for the situation where the number starts with a period.
t="13.357713"
# integer part of time interval
ts="${t%%[![:digit:]]+([:digit:])}" # remove longest match from back
# 13.877597, remove .877597
# fractional part of time interval
fr="${t##*([:digit:])[![:digit:]]}" # remove longest match from front
# 13.877597, remove 13.
Exclamation mark when using character classes
I am using EPOCHREALTIME and then computing the corresponding human readable
form, that can handle
changes in locale
now=$EPOCHREALTIME
printf -v second '%(%S)T.%s' "${now%[^[:digit:]]*}" "${now#*[^[:digit:]]}"
printf -v minute '%(%M)T' "${now%[^[:digit:]]*}"
printf -v hour '%(%H)T' "${now%[^[:digit:]]*}"
Incidentally, [![:digit:]] does not work there, you need to use the
POSIX-specified caret (^) instead of an
exclamation mark when using character classes. I'm not sure if this is
intentional or a bug in bash; man
page doesn't seem to mention it.
EPOCHREALTIME
‐‐‐ Original Message ‐‐‐ On Thursday, August 19, 2021 12:58 PM, Léa Gris wrote: > Le 19/08/2021 à 14:43, hancooper via Bug reports for the GNU Bourne > Again SHell écrivait : > > > Have been using $EPOCHREALTIME but can see that the output is as follows. > > 1629376497,853634 > > The utilisation of tho comma `,` is very inconvenient for those who want to > > do time > > computations. A change towards a period `.` would be the proper way to > > display the > > variable. > > Furthermore, one gets nanosecond precision when using date. But such > > precision > > is not possible with EPOCHREALTIME. Thusly, the improvement to nanosecond > > precision is desirable so as to match the capability of data. > > Felicitations > > Han > > (LC_NUMERIC=C; echo "$EPOCHREALTIME") > > It will use a dot time stamps are a way to track time as a running total of seconds, a count that starts on January 1st, 1970 at UTC. Therefore, the unix time stamp is merely the number of seconds between a particular date and the epoch. Technically, it should be pointed out that the time does not change no matter where you are located on the globe. Thusly, EPOCHREALTIME should not be made to depend on the locale. I have seen many workarounds, that complicate rather than simplify something that should be straighforward and germaine to direct numeric computation.
EPOCHREALTIME
Have been using $EPOCHREALTIME but can see that the output is as follows. 1629376497,853634 The utilisation of tho comma `,` is very inconvenient for those who want to do time computations. A change towards a period `.` would be the proper way to display the variable. Furthermore, one gets nanosecond precision when using date. But such precision is not possible with EPOCHREALTIME. Thusly, the improvement to nanosecond precision is desirable so as to match the capability of data. Felicitations Han
