Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Fix plugin-test arg parsing #1084

Merged
merged 2 commits into from Nov 7, 2021
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
14 changes: 8 additions & 6 deletions lib/commands/command-plugin-test.bash
Expand Up @@ -9,24 +9,26 @@ plugin_test_command() {
local plugin_gitref="master"
local tool_version
local interpret_args_literally
local skip_next_arg

for arg; do
shift
if [ -n "${interpret_args_literally}" ]; then
if [ -n "${skip_next_arg}" ]; then
skip_next_arg=
elif [ -n "${interpret_args_literally}" ]; then
set -- "$@" "${arg}"
else
case "${arg}" in
--asdf-plugin-gitref)
plugin_gitref="$2"
shift 2
plugin_gitref="$1"
skip_next_arg=true
;;
--asdf-tool-version)
tool_version="$2"
shift 2
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why these lines didn't work. Can you explain what was wrong with the previous code? New code looks good, but it seems like it should be equivalent to the old code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I feel less guilty for failing to realize the bugs last time :)

Two issues with the old code:

  • We shift at the beginning of the loop, so although $1 and ${arg} are equivalent at the beginning of the loop, they are no longer equivalent after shift. Therefore we should be using $1 instead of $2.
  • Even if you fix that, modifying the args array in place does not affect the iteration, so even if you shift a second time to skip over the option argument, it still shows up as the next value for ${arg}. Hence the requirement to use a bool to track whether to skip the next argument.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'll notice that all of this is horribly obtuse, this is why writing pure POSIX compatible scripts is not so popular these days!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'll notice that all of this is horribly obtuse, this is why writing pure POSIX compatible scripts is not so popular these days!

Indeed 😅

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@raxod502 just curious, where does arg get set? I don't see it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would a pattern like this be better? https://github.com/Stratus3D/dotfiles/blob/master/scripts/tools/to_server#L101-L143 (this is a pattern I've repeatedly used because it doesn't require setting any temporary variables. Only $1, $2, and shift are used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • arg gets set by the for arg at the top of the loop. It's equivalent to for arg in "$@".
  • No, unfortunately, we can't do it the reasonable way, because we need to save an array of the command to run, for execution later, and unfortunately POSIX sh only supports having one array variable in your whole program, namely $@. So we have to do all of the manipulation in place.

tool_version="$1"
skip_next_arg=true
;;
--)
interpret_args_literally=true
shift
;;
*)
set -- "$@" "${arg}"
Expand Down