Remove double quotes surrounding a wildcard

[spgreenberg]

From man bash: Enclosing characters in double quotes preserves the literal value of all characters within the quotes, with the exception of $, `, \

In bash, this should not work. We would like to be able to point a wide range of users to the deploy-on-kind.sh script which calls this script. We would like to ensure the widest range of users do not run into issue with this.

Is there a related GitHub Issue?

No

What is this change about?

The script uses a wildcard inside double quotes. In bash, this should not work. We would like to be able to point a wide range of users to the deploy-on-kind.sh script which calls this script. We would like to ensure the widest range of users do not run into issue with this.

Does this PR introduce a breaking change?

No

Acceptance Steps

Run it in vanilla bash with no special settings.

Tag your pair, your PM, and/or team

N/A

[kieron-dev]

Removing the quotes breaks the case where $VENDOR_DIR contains spaces. Quoting just "$VENDOR_DIR" would be ok.

Are you seeing this problem on a mac with the default bash-v3.2 btw?

[gcapizzi]

Also note that kubectl apply -f will only accept one file regardless, so this will only work if the wildcard expands to exactly one file. How we quote it shouldn't matter, but we could change this to be targeting a single file more explicitly? Anything I can think of looks worse than what we already have though.

[spgreenberg]

I see this issue on osx with bash 5.2. I can revise to move the quotes.

[spgreenberg]

The latest commit should expand the wildcard and handle spaces in the path.

@gcapizzi vanilla bash doesn't expand wildcards in double quotes per the man page quote above. It isn't working as is with plain bash 5.2 on macos. The script is so quick and easy that I want to be able to point as many people to it as possible.

[danail-branekov]

The script is so quick and easy that I want to be able to point as many people to it as possible

Keep in mind that we do not "release" this script, we use it for dev purposes and will most probably change in future. I agree that such a script is much better than having an outdated documentation but we cannot guarantee that it works at all times.

[spgreenberg]

Understood. Given it is used for dev, I am sure it will get plenty of attention. We can make it clear this is a dev script and it should be treated as such.

[gcapizzi]

@spgreenberg We do not consider the script to be public API and we will change it for development purposes without warning, so we don't want people to think of it as something they can rely on. It will always work (as we use it daily) but both the behaviour and the interface might change.

We do try our best to make sure that install instructions in our releases are correct, those combined with the Helm chart are aimed at users.

[spgreenberg]

@gcapizzi I understand. Currently this is the best option available though. We are working on a streamlined introduction to Korifi and we want to be sure the experience is as easy as possible. We will be sure to stress that this is a development tool and that Korifi is still actively being built.