Homebrew base64 does not support `base64 -w`

[matthiaz]

Mac does not support base64 -w which we are using here https://github.com/drud/ddev-platformsh/blob/main/install.yaml#L163

See: https://stackoverflow.com/questions/46463027/base64-doesnt-have-w-option-in-mac

[lolautruche]

Hi @matthiaz and thank you! The line you're pointing out is specifically here to test if the option is available or not:

  BASE64_ENCODE="base64"
  if base64 -w 0 </dev/null >/dev/null 2>&1; then BASE64_ENCODE="base64 -w 0"; fi

By default the command is just base64. We're setting the BASE64_ENCODE variable and use it along the way, to keep being compatible with macOS, Linux, etc

[matthiaz]

I saw that... but uhm... doesn't seem to be working ?

[lolautruche]

This is weird... I have it running smoothly on my Mac. Which version of macOS are you running? Is it an Intel or ARM CPU? Are you using Bash, ZSH or another shell?

[gilzow]

Can you provide more details, @matthiaz on your set up? As @lolautruche said, I can run it on my mac without issue.

If you run

BASE64_ENCODE="base64"; if base64 -w 0 </dev/null >/dev/null 2>&1; then BASE64_ENCODE="base64 -w 0"; fi; echo $BASE64_ENCODE;

directly in a terminal, what happens?

[rfay]

Also, is is possible you have an unexpected base64? If you could show base64 --version and ls -l $(which base64) it would be great.

I should note that we don't intend to rely on a local base64 in the future of this project.

[bber33]

Hello, Following discussion with @matthiaz here are the output I get on MacOS (Monterey 12.1).

here is what I get on BASE64_ENCODE="base64"; if base64 -w 0 </dev/null >/dev/null 2>&1; then BASE64_ENCODE="base64 -w 0"; fi; echo $BASE64_ENCODE; base64 -w 0

And on ls -l $(which base64)

lrwxr-xr-x 1 bberth admin 31 Jan 19 18:21 /usr/local/bin/base64 -> ../Cellar/base64/1.5/bin/base64

[bber33]

base64 --version

base64 1.5 Last revised: 10th June 2007 The latest version is always available at http://www.fourmilab.ch/webtools/base64

[bber33]

This is weird... I have it running smoothly on my Mac. Which version of macOS are you running? Is it an Intel or ARM CPU? Are you using Bash, ZSH or another shell?

Using ZSH 2,3 GHz Intel Core i5 dual core (Intel x86)

[rfay]

I see, you have the homebrew version of base64. If you uninstall it this will work, brew uninstall base64. You'll need to do a hash -r after uninstalling before using base64 again. We will definitely get it to where it doesn't depend on the host-side installed base64.

[bber33]

@rfay it actually worked when uninstalling brew base64. Thanks a lot !

[rfay]

Thanks, glad it's working. We'll need to figure out in the short term how to detect the type of base64 better, and of course in the longer term we need to not use the local tool.

[lolautruche]

I wonder why it wouldn't work since the script is supposed to use the brew version (base64 -w). There is a mismatch here, so I guess it's a question of context. base64 may be installed as a dependency by other packages, and uninstalling it might cause trouble with those hypothetic packages.

[rfay]

The script here assumes the macOS built-in version, and fails with the homebrew version. I'm never heard of the homebrew base64 being a dependency of something else but it probably is. But in @bber33 's case it would have warned about that.

[lolautruche]

From what I understand, it doesn't assume the built-in version since we do a test first, to detect if base64 -w is valid or not. In the case of base64 being installed via Homebrew, it is. But for some reason it seems that further on the binary used is the built-in one. At least that's my understanding of the issue.

[rfay]

I agree with you that the code seems like it's doing the right thing. It's possible that the homebrew base64 doesn't behave exactly like the linux base64?

https://github.com/drud/ddev-platformsh/blob/7b77ecef94713319a36b483b6593c10c0df3d5a0/install.yaml#L162-L164

[rfay]

Linux base64:

$ base64 --help
Usage: base64 [OPTION]... [FILE]
Base64 encode or decode FILE, or standard input, to standard output.

With no FILE, or when FILE is -, read standard input.

Mandatory arguments to long options are mandatory for short options too.
  -d, --decode          decode data
  -i, --ignore-garbage  when decoding, ignore non-alphabet characters
  -w, --wrap=COLS       wrap encoded lines after COLS character (default 76).
                          Use 0 to disable line wrapping

      --help     display this help and exit
      --version  output version information and exit

Homebrew base64:

$ base64 -h
base64: illegal option -- h
base64  --  Encode/decode file as base64.  Call:
            base64 [-e / -d] [options] [infile] [outfile]

Options:
           --copyright       Print copyright information
           -d, --decode      Decode base64 encoded file
           -e, --encode      Encode file into base64
           -n, --noerrcheck  Ignore errors when decoding
           -u, --help        Print this message
           --version         Print version number

macOS base64:

v$ /usr//bin/base64 -h
Usage:  base64 [-hDd] [-b num] [-i in_file] [-o out_file]
  -h, --help     display this message
  -Dd, --decode   decodes input
  -b, --break    break encoded string into num character lines
  -i, --input    input file (default: "-" for stdin)
  -o, --output   output file (default: "-" for stdout)

[lolautruche]

It's a bug in Homebrew base64:

$ which base64
/opt/homebrew/bin/base64
$ base64 -w 0
base64: illegal option -- w
$ echo $?
0

$ /usr/bin/base64 -w 0
base64: invalid argument -w
$ echo $?
64

[rfay]

How can there be so many different kinds! Homebrew version seems to require -e option to encode.