ko1nksm / getoptions Goto Github PK

getoptions を日頃より利用させてもらっております。開発者の皆様ありがとうございます。

以下のような ShellScript コードを作成し、 gengetoptions embed --overwrite を利用して、オプション解析のコードを追加した後実行すると、オプション -a のバックスラッシュが自動的にエスケープされるようです。

# @getoptions
parser_definition() {
  setup REST
  param a -a init:='\\'
}
# @end

# @gengetoptions parser -i parser_definition parse
# @end

parse "$@"
eval "set -- $REST"

printf '%s\n' "$a"

直接 -a を指定するとエスケープされないようです。

$ sh a
\
$ sh a -a '\\'
\\

この動作はバグでしょうか。それとも仕様でしょうか。

当方の動作環境は以下のようになります。

$ getoptions -v
v3.3.0
$ gengetoptions -v
v3.3.0
$ dpkg -l | grep dash
ii  dash                                   0.5.8-2.10                                       i386         POSIX-compliant shell

AURにgetoptionsのPKGBUILDを書いて投稿しました。
これによりArchユーザーはpacmanの管理下でgetoptionsを使用できます。

https://aur.archlinux.org/packages/getoptions-git/
https://aur.archlinux.org/packages/getoptions/

READMEにこれを追記することでArchユーザーは簡単にインストールできるようになります。

My understanding (possibly incorrect) based on the Reference document is that options (options with an optional argument) should be able to be:

• set explicitly to some value passed on the actual command line (consistent with validation)
• set to "on" value if the option is present in the commandline and no value is passed, -e.g. -n
• set to the "no" value if the negated option is present in the commandline and no value is passed, e.g. +n
• if the option is not passed on the commandline my expectation was that the init attribute would be the default

It seems that the last bullet item is not correct. The result is that options with optional values cannot have a default for when they are not present. I have tried setting a default as an explicit string

init:="missing value"

And I have tried setting it to one of the pre-defined expressions

init:@on

Note that the latter is still limiting because it would limit the default value to be either the on or the no value rather than a distinct value for the case when the option was not specified.

I believe the init option is not working for options (with optional values) currently. (It works fine for parameters)

Thanks again for this great tool. As you can see from the example, I prefer to use it with functions in library mode. In library mode I usually have strict mode enabled with "set -euo pipefail" enabled. But I have tested with strict mode disabled and the result is the same.

example.zip

I run the code from the documentation, but it doesn't embed code.

gengetoptions embed --overwrite example.sh

~/Sandbox/examples
cat example.sh

What am I doing wrong?

What is the difference between param and option?

param - Define an option that takes an argument
option - Define an option that takes an optional argument

I can see that option has on and no:

on:STRING - The positive value
no:STRING - The negative value

It seems like a mixture of flag and option.
The option can be used as a flag and also you can add an argument.

Is this a correct interpretation?

This is implemented as an optional feature as it would take a lot of code.

Is there an example of using the embed options while there are multiple subcmds involved?

I've noticed that getoptions fails to set a constant for an option when the option name contains hyphens, such as --foo-bar.

Just wonder if there is possibility or how much of the work to support sub-sub-commands?

e.g.:
command sub-command1 sub-sub-command1

I just followed the instruction:

~/Sandbox/examples
❯ gengetoptions parser ./parser_definition.sh parse prog > parser.sh

Deprecated. Use the --file option instead.
gengetoptions: The parser definition 'parser_definition' not found

Am I missing something here?

My use case is something like this:

I have an sh file that is used as a proxy for a binary. However I want to only parse "some" options while forwarding the others to the binary. Example: my.sh --proxy-option 1 --opt1 --opt2 - I want to only parse proxy-option while having the other options in "$@" (--opt1 --opt2). Is this possible?

First, this is a really great utility! Thanks so much for creating it.

I was wondering, do you have plans to support a default error for params that are required? Currently I have to do like this. Was wondering if those required param checks could be built in, and if you have plans for that.

eval "$(getoptions parser_definition parse "$0")" 
parse "$@"                         
               
[[ -z "${APPNAME-}" ]] && die "Missing required parameter: --appsvc-name"
[[ -z "${FILEPATH-}" ]] && die "Missing required parameter: --upload-filepath"

Overall, it looks like a good tool, with many features, but learning how to use it is very time intensive. While there are some examples, there is hardly any explanation in the documentation.

I still have some questions unanswered, for example

• What is the format of each of the following: "setup", "msg", "flag", "option", "param", and "disp"? Any others?
• What is "mode"? How can it be used?
• What is the difference between "parameter" and "option"?
• How do I define the required parameters?

In addition, while getoptions looks useful, it is difficult to understand how it works from the code.

When I run brew upgrade I get the following warning:

$ brew upgrade
Warning: Calling bottle :unneeded is deprecated! There is no replacement.
Please report this issue to the ko1nksm/getoptions tap (not Homebrew/brew or Homebrew/core):
  /opt/homebrew/Library/Taps/ko1nksm/homebrew-getoptions/getoptions.rb:7

I see in both the Advanced example and in the Reference that parameters accept an init attribute. My understanding was that if the parameter is specified in the commandline, then a value must be supplied. However, if the parameter is not specified in the commandline, then presumably the init value will be applied as the default value of the parameter.

However, this does not seem to be working.
example.zip

This feature is currently not implemented correctly, and fixing it would increase the amount of code significantly, so it will remove it.

~
❯ brew tap ko1nksm/getoptions
Running `brew update --preinstall`...
[...]

==> Tapping ko1nksm/getoptions
Cloning into '/opt/homebrew/Library/Taps/ko1nksm/homebrew-getoptions'...
remote: Enumerating objects: 9, done.
remote: Counting objects: 100% (9/9), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 9 (delta 0), reused 5 (delta 0), pack-reused 0
Receiving objects: 100% (9/9), 4.36 KiB | 4.36 MiB/s, done.
Error: Invalid formula: /opt/homebrew/Library/Taps/ko1nksm/homebrew-getoptions/getoptions.rb
getoptions: Calling bottle :unneeded is disabled! There is no replacement.
Please report this issue to the ko1nksm/getoptions tap (not Homebrew/brew or Homebrew/core):
  /opt/homebrew/Library/Taps/ko1nksm/homebrew-getoptions/getoptions.rb:7

Error: Cannot tap ko1nksm/getoptions: invalid syntax in tap!

I forked your tap repo and removed the bottle :unneeded line and it works fine!

shameless duplicate of matejak/argbash#158

tldr: replace the argument @my-args.txt with the contents of the my-args.txt file, allow recursion

challenge: string parsing without eval

I'm confused about on: and no: in the flag and option.

When I set this:

flag FLAG_D -d +d on:ON no:NO

./advanced -d returns FLAG_D: ON and ./advanced +d returns FLAG_D: NO.

In the reference, it states:

on:STRING - The positive value
no:STRING - The negative value

So I expected ./advanced -d to return the negative value. In the above case, it is NO.

When I use a plus sign in set command, it causes these options to be turned off. Is it the same way getoptions working?
If it is so, what do the positive and negative values stand?

What am I missing here?

I'm often writing scripts that require some parameters to be provided when calling the script, while others are (and that seems to be the reasonable standard when using getoptions) completely (or conditionally – but that's to complicated here) optional. Even when using this super tool here, I am forced to check for the existence of my mandatory parameters after the parsing.

Could it be possible, to include this kind of simple mandatory check into this tool? (Maybe with a new annotation required, or a new type paramReq or so?)
If it could be automatically reflected by the generated options list would be a perfect bonus.

To demonstrate what I mean:

script.sh -a <valueA> [ -b <valueB> ]

This definition would not only require the existence of a value for <valueA> when calling with -a, but the existence of the parameter -a itself.

So the following calls would be correct:

script.sh -a ABCD
script.sh -a ABCD -b 1234

The following would be rejected by getoptions now (assuming that -a and -b configured as params):

script.sh -a

But this would be accepted (by now) also, despite the fact that I want to require the user to provide the -a flag:

script.sh
script.sh -c 1234

As a bonus this kind of "mandatory parameters" could be (optionally) visually be hinted by a small asterisk or some other little character, like so:

My script does the following …

OPTION DESCRIPTION
-a  * -- 'My mandatory param a'
-b    -- 'My normal/optional param b'
-c    -- 'and so on …'

When I use getoptions, I always have to manually ignore SC2004 that ShellCheck points out.

In foo line 62:
          REST="${REST} \"\${$(($OPTIND-$#))}\""
                                ^-----^ SC2004 (style): $/${} is unnecessary on arithmetic variables.


In foo line 68:
        REST="${REST} \"\${$(($OPTIND-$#))}\""
                              ^-----^ SC2004 (style): $/${} is unnecessary on arithmetic variables.

For more information:
  https://www.shellcheck.net/wiki/SC2004 -- $/${} is unnecessary on arithmeti...

    59	      --)
    60	        shift
    61	        while [ $# -gt 0 ]; do
*   62	          REST="${REST} \"\${$(($OPTIND-$#))}\""
    63	          shift
    64	        done
    65	        break ;;
    66	      [-]?*) set "unknown" "$1"; break ;;
    67	      *)
*   68	        REST="${REST} \"\${$(($OPTIND-$#))}\""
    69	    esac
    70	    shift
    71	  done

Is it possible to fix this?

the optional grammar is below for current:
-ovalue or -o=value

can it support -o value?

subcmd.sh works all nice. I wonder if there is a way to let the command to display the help message if no option is provided.

... code from examples/subcmds.sh

eval "$(getoptions parser_definition parse "$0") exit 1"
parse "$@"
eval "set -- $REST"

if [ $# -gt 0 ]; then
	cmd=$1
	shift
	case $cmd in
		cmd1)
			eval "$(getoptions parser_definition_cmd1 parse "$0")"
			parse "$@"
			eval "set -- $REST"
			echo "FLAG_A: $FLAG_A"
			;;
		cmd2)
			eval "$(getoptions parser_definition_cmd2 parse "$0")"
			parse "$@"
			eval "set -- $REST"
			echo "FLAG_B: $FLAG_B"
			;;
		cmd3)
			eval "$(getoptions parser_definition_cmd3 parse "$0")"
			parse "$@"
			eval "set -- $REST"
			echo "FLAG_C: $FLAG_C"
			;;
		--) # no subcommand, arguments only
	esac
else
    echo "here!"
    ## How to let the command to display the help message here the same as --help option??
    eval "$(getoptions parser_definition parse "$0" "-h")"
fi
echo "GLOBAL: $GLOBAL"
i=0
while [ $# -gt 0 ] && i=$((i + 1)); do
	echo "$i: $1"
	shift
done