[next.4] Cannot install gcloud sdk on macOS

[patrickserrano]

I was helping @zihli get set-up with prompt on macOS and ran into an issue installing the gcloud sdk using install-gcloud in version 8.3.0-next.4. I was able to recreate the error on a fresh install of macOS:

For reference the issue initially appeared on macOS 10.15 and then was reproduced on macOS 11. Existing prompt installs don't seem to have issues using the SDK if it was previously installed.

It looks like #85 made changes to the install script, and based on the error it looks like there's an issue with the C flag in tar -xfC.

Looking at the manpage for tar, it seems like -C and --directory are the same flag. I can't tell if that was intentional or not.

-C, --directory=DIR
    Change to DIR before performing any operations.
    This option is order-sensitive, i.e. it affects all options that follow.

Though the macOS manpage shows this:

-C directory, --cd directory, --directory directory
    In c and r mode, this changes the directory before adding the following files. 
    In x mode, change directories after opening the archive but before extracting entries from the archive.

I've tried changing the flags and reordering some of the options when calling tar and managed to get it to extract and start the install but the SDK isn't available on the path. While looking into that, I noticed there are inconstancies in the paths we're referencing the install at:

On line 47 in install-gcloud we're extracting compressed files to "$AM_PROMPT_USER"/gcloud but then on line 54 we're trying to run the install script from "$AM_PROMPT_USER"/bin/gcloud/install.sh.

In the bash version of set-gcloud-path we're checking "$AM_PROMPT_USER"/bin/gcloud/gcloud but in the zsh version of that script we're checking "$HOME/.gcloud/bin/gcloud".

[sjk07]

@dmccaffery @patrickserrano Off topic but: What was the purpose of having install-gcloud? anything wrong with just using brew to install gcloud? I see that it will install kubctl and some other stuff; was that the only reason?

[dmccaffery]

1. The brew version is typically behind -- it's not the official install mechanism and competes with the auto update functionality in the sdk itself
2. Brew isn't cross platform across macOS and all linux distros we support. Linuxbrew has a long way to go to be truly stable; we reverted from using it