[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Handling getopt for option without optional argument value
From: |
lisa-asket |
Subject: |
Handling getopt for option without optional argument value |
Date: |
Fri, 23 Jul 2021 22:53:59 +0200 (CEST) |
From: Lawrence Velázquez <vq@larryv.me>
To: lisa-asket@perso.be
Subject: Re: Handling getopt for option without optional argument value
Date: 23/07/2021 22:30:51 Europe/Paris
Cc: help-bash@gnu.org
On Fri, Jul 23, 2021, at 4:08 PM, lisa-asket@perso.be wrote:
> I have the idea of adding
>
> local warn="1"
>
> just before
>
> case "$2" in
>
> The change will result in
>
> ("-w"|"--warning")
>
> local warn="1"
> case "$2" in
> (+([[:digit:]]))
> local warn="$2"
> shift 2
> ;;
> (*)
> local warn="1"
> shift 2
> ;;
> esac
This wouldn't fix anything. The `warn` variable would still only
get set when '-w' or '--warning' is passed to your function.
---
Correct. Warn is only used so that some lines are coloured in red.
I do not think `(*)` is called when having just `-w`.
---
I don't understand what you want at all. Isn't the current behavior
fine? Why would you want `warn` to be set by default? What is the
behavior you are seeing, and what are you expecting instead?
By the way.
if [[ -v $f ]] && (( f != 0 )); then
# print normal multi-line text
[[ ! -v $warn ]] && printf '%s\n' "$@"
# print multi-line warnings
rge='^[0-9]+$'
if [[ -v $warn && "$warn" == "1" ]]; then
printf '%s\n' ${red}"$1"${rgl} # first line red
printf '%s\n' "${@:2}" # remaining, uncoloured
elif [[ -v $warn && "$warn" =~ $rge ]]; then
printf '%s\n' ${red}"$@"${rgl} # all lines red
fi
[[ -v $f ]] and [[ -v $warn ]] are both wrong. They should be
[[ -v f ]] and [[ -v warn ]].
--- Thanks
> Do you think it is better to use `declare` to set numeric values for `warn`?
Not really.
> declare -i local warn=1
Within a function, 'declare' and 'local' are basically equivalent.
So this would declare two local variables -- one named "warn" and
another literally named "local". This has no advantage over what
you are already doing.
--- I understand your point. But using local is good to do, I think.
Re: Handling getopt for option without optional argument value, Lawrence Velázquez, 2021/07/23
Handling getopt for option without optional argument value, lisa-asket, 2021/07/23
- Re: Handling getopt for option without optional argument value, Greg Wooledge, 2021/07/23
- Handling getopt for option without optional argument value, lisa-asket, 2021/07/23
- Re: Handling getopt for option without optional argument value, Greg Wooledge, 2021/07/23
- Handling getopt for option without optional argument value, lisa-asket, 2021/07/23
- Re: Handling getopt for option without optional argument value, Greg Wooledge, 2021/07/23
- Re: Handling getopt for option without optional argument value, Dennis Williamson, 2021/07/23
- Handling getopt for option without optional argument value, lisa-asket, 2021/07/23
- Handling getopt for option without optional argument value, lisa-asket, 2021/07/23