Zsh not installing correctly?

[amelio-vazquez-reina]

Output of brew config

❯ brew config
HOMEBREW_VERSION: 4.5.3
ORIGIN: https://github.com/Homebrew/brew
HEAD: dc0f9d50fd170492a33fd7234d06de1b94df363c
Last commit: 4 days ago
Branch: stable
Core tap JSON: 28 May 05:12 UTC
Core cask tap JSON: 28 May 05:12 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 12
Homebrew Ruby: 3.4.4 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.4.4/bin/ruby
CPU: dodeca-core 64-bit arm_blizzard_avalanche
Clang: 16.0.0 build 1600
Git: 2.39.5 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 15.5-arm64
CLT: 16.2.0.0.1.1733547573
Xcode: N/A
Rosetta 2: false

Output of brew doctor

❯ brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: Some installed formulae are deprecated or disabled.
You should find replacements for the following formulae:
  icu4c@76

Warning: Unbrewed dylibs were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae and may need to be deleted.

Unexpected dylibs:
  /usr/local/lib/libfido2.1.14.0.dylib

Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae and may need to be deleted.

Unexpected header files:
  /usr/local/include/fido.h
  /usr/local/include/fido/*

Warning: Unbrewed '.pc' files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae and may need to be deleted.

Unexpected '.pc' files:
  /usr/local/lib/pkgconfig/libfido2.pc

Description of issue

I'm having issues with zparseopts and it looks like Brew didn't install it correctly, see this simple test below (all similar tests fail):

❯ short_test_zpo() {
  autoload -Uz zparseopts || { echo "🔴 Autoload FAILED"; return 1; }
  local my_flag
  zparseopts -E -- f=my_flag -- "$@" # Use "$@" to pass args from func call
  if (( ${#my_flag[@]} )); then
    echo "✅ zparseopts PARSED the -f flag."
    echo "   Remaining args: $@"
  else
    echo "❌ zparseopts DID NOT parse the -f flag (or -f was not given)."
    echo "   Remaining args: $@"
  fi
}


❯ short_test_zpo some arg
short_test_zpo:3: zparseopts: function definition file not found
❌ zparseopts DID NOT parse the -f flag (or -f was not given).
   Remaining args: some arg
   

❯ ls -l $(brew --prefix)/share/zsh/functions/zparseopts

ls: /opt/homebrew/share/zsh/functions/zparseopts: No such file or directory

❯ brew reinstall zsh
==> Downloading https://ghcr.io/v2/homebrew/core/zsh/manifests/5.9-3
Already downloaded: /Users/amelio/Library/Caches/Homebrew/downloads/2913dc2cb6e58f61f4261bc20839152f766b9eaf2f55e601c528b77f4c91a364--zsh-5.9-3.bottle_manifest.json
==> Fetching zsh
==> Downloading https://ghcr.io/v2/homebrew/core/zsh/blobs/sha256:93cacab325d2a9
Already downloaded: /Users/amelio/Library/Caches/Homebrew/downloads/655b05f05860b07b382da3cd3866feb12706ed25b0a4d381ff276f1ba84c6d18--zsh--5.9.arm64_sequoia.bottle.3.tar.gz
==> Reinstalling zsh
==> Pouring zsh--5.9.arm64_sequoia.bottle.3.tar.gz
🍺  /opt/homebrew/Cellar/zsh/5.9: 1,579 files, 16MB
==> Running `brew cleanup zsh`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).

Relevant casks

Zsh

[daeho-ro]

I don't know why but it is located in /help only not /functions.
I think then this means there is no function? hm...

[amelio-vazquez-reina]

From what I gathered:

The zparseopts built-in in your Homebrew-installed Zsh 5.9 (the arm64_sequoia bottle for macOS 15.5) is not behaving according to its documentation and standard behavior.
Specifically, we've observed two deviations in a clean zsh -f environment:

• Failure to modify $@: zparseopts does not remove parsed options from the positional parameters. It acts as if the -D option is always active.
• Incorrect behavior of -E: When -E is used with a scalar variable for a flag (e.g., f=my_flag), my_flag is set to the option name (-f) instead of 1.

This is almost certainly a bug or an unintended consequence of how Zsh was compiled or patched by Homebrew for the new macOS Sequoia (15.5).

@daeho-ro is this consistent with what you see on your end / expect?

[viking1304]

As far as I know autoload -Uz zparseopts does not work on macOS and it is not needed. You can use zmodload zsh/zutil instead.

This is the working version of your test.

short_test_zpo() {
  zmodload zsh/zutil # Use this for macOS instead of autoload if needed
  local -A opts
  local -a args
  args=("${(@)argv}")  # Copy the original arguments

  zparseopts -E -A opts -- f -f
  
  # Remove all recognized options from args
  for opt in "${(@k)opts}"; do
    args=(${args:#$opt})
  done

  if [[ -n ${opts[(i)-f]} || -n ${opts[(i)--f]} ]]; then
    echo "✅ Option -f/--f was passed"
  else
    echo "❌ Option -f/--f was NOT passed"
  fi

  echo "   Remaining args: ${args[*]}"
}

And this is the simple test

❯ short_test_zpo -f test 1
✅ Option -f/--f was passed
   Remaining args: test 1
❯ short_test_zpo --f test 1
✅ Option -f/--f was passed
   Remaining args: test 1   
❯ short_test_zpo -d test 2
❌ Option -f/--f was NOT passed
   Remaining args: -d test 2

This works for me even without zmodload with the both built-in zsh and the one from brew, but I guess in my case modules were loaded by Oh My Zsh. I added that line in this example to be sure that not loading the module would not cause any issue.

EDIT:

I had a typo, this is the correct version of zparseopts:

  zparseopts -E -A opts -- f -f

Each option should be with one "-" less than it actually have when used. So, it should be "-f" for "--f". I also added this test result.

[amelio-vazquez-reina]

Thanks @viking1304

Hmm, Your answer works:

❯ short_test_zpo() {
  zmodload zsh/zutil # Use this for macOS instead of autoload if needed
  local -A opts
  local -a args
  args=("${(@)argv}")  # Copy the original arguments

  zparseopts -E -A opts -- f -f
  
  # Remove all recognized options from args
  for opt in "${(@k)opts}"; do
    args=(${args:#$opt})
  done

  if [[ -n ${opts[(i)-f]} || -n ${opts[(i)--f]} ]]; then
    echo "✅ Option -f/--f was passed"
  else
    echo "❌ Option -f/--f was NOT passed"
  fi

  echo "   Remaining args: ${args[*]}"
}

# Testing it ..

❯ short_test_zpo -f test 1
✅ Option -f/--f was passed
   Remaining args: test 1

However, I try to define multi-letter arguments instead, it doesn't seem to work

❯ short_test_zpo() {
  zmodload zsh/zutil # Use this for macOS instead of autoload if needed
  local -A opts
  local -a args
  args=("${(@)argv}")  # Copy the original arguments

  # MODIFIED: Changed the option spec to look for 'from' with a required argument (:)
  zparseopts -E -A opts -- from:

  # Remove all recognized options from args
  # NOTE: This loop may not correctly remove arguments for options
  # when they are passed as separate words (e.g., --from foo).
  # See explanation below.
  for opt in "${(@k)opts}"; do
    args=(${args:#$opt})
    # This part is a bit tricky, which is why zparseopts modifies argv directly.
    # To correctly remove the option's argument as well, you would need more logic.
    # The idiomatic way is to just use the `argv` array after zparseopts runs.
  done

  # MODIFIED: Check for the '--from' key and print its value
  if [[ -n ${opts[(i)--from]} ]]; then
    echo "✅ Option --from was passed with value: ${opts[--from]}"
  else
    echo "❌ Option --from was NOT passed"
  fi

  echo "   Remaining args: ${args[*]}"
  # For comparison, here are the arguments left in argv by zparseopts itself:
  echo "   (argv after zparseopts): ${argv[*]}"
}

# Testing it ..

❯ short_test_zpo --from="foo" bar baz
❌ Option --from was NOT passed
   Remaining args: --from=foo bar baz
   (argv after zparseopts): --from=foo bar baz

[viking1304]

That was just a quick demo to demonstrate that zsh properly works, not a fully functional solution for option handling in zsh.

Do not forget that you always need to have exactly one less - in zparseopts than in the option itself. So, you need to use:

f for -f
-f for --f
from for -from
-from for --from

This is the reason why you are getting a message that your option --from was not recognized.

p.s. Even zsh is my default shell everywhere I still use bash for all my scripts, because (as far as I know) proper linter for zsh does not exist.