__lp_source_config error on sourcing liquidprompt

[OldCrow]

Attempting to source liquidprompt (from a fresh install from git) on Mac OS X 10.11.6 fails with the following error:

__lp_source_config:191: number expected

Shell: zsh 5.0.8

Operating system: Mac OS X El Capitan 10.11.6 (kernel Darwin 15.6.0)

Liquidprompt version: v1.12.1 (tag 762018c)

Steps to Reproduce

1. Install liquidprompt from repo (git clone https://github.com/nojhan/liquidprompt.git ~/liquidprompt)
2. Source liquidprompt (source ~/liquidprompt/liquidprompt)
3. failure.

Expected Behavior

Liquidprompt is sourced and prompts configure correctly

Current Behavior

Sourcing fails with reported error "__lp_source_config:191: number expected"

Possible Solution

Nil. works correctly on other instalations (e.g., macOS 10.15)

[Rycieos]

I haven't had a chance to dig into this yet, but since you think it only happens on some versions of MacOS, could you upload a machine report using tools/external-tool-tester.sh? See #640 for details.

[OldCrow]

liquidprompttest.txt
Machine report attached.

[OldCrow]

Sorry, also should have mentioned...the version of liquidprompt installed on my macOS 10.15 was installed using homebrew. However, I can't that being an issue as homebrew should be installing the same versions, with only the install location being different (and the interactive shell test/ source line in .zshrc).

In this case, liquidprompt was sourced directly as per the test drive instructions. The error does map to a function in liquidprompt.

[Rycieos]

Took me a second, but I tracked it down.

Zsh used to have a limitation where you could not declare an array and assign it in the same command. See the commit message for details.

Thanks for the report!

[Rycieos]

TL;DR: I am somewhat considering dropping support for Zsh < 5.1

Turns out this issue was not an isolated incident. According to the Zsh release notes:

Changes between versions 5.0.8 and 5.1

The builtins declare, export, local, readonly and typeset now have corresponding reserved words. When used in this form, the builtin syntax is extended so that assignments following the reserved word are treated similarly to assignments that appear at the start of the command line. For example,

local scalar=`echo one word` array=(several words)

creates a local "scalar" containing the text "one word" and an array "array" containing the words "several" "words".

Which means the issue is not isolated to typeset -a var=(1 2 3), but also typeset var=$foo. This means that Zsh <= 5.0.8 does this:

func() {
  local string=$1
}
func 'a pretty normal string'
+func:1> local 'string=a' pretty normal string
string=a

Which is totally broken. Both Ksh (93u+ 2012-08-01) and Bash >= 3.2 don't have this bug.

As I recently found, as far as I can tell with the relevant POSIX standard: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01
There is no specification as to how the typeset command acts:

If the command name [is typeset], the results are unspecified.

Which means technically the old Zsh behavior was not POSIX breaking, but it broke the expectation of the assignment syntax, which is why they fixed it.

Now this could be fixed in Liquidprompt. Any assignment of a local variable on the same line as it is declared local could be changed to either:

1. Be broken to two different lines: local var; var=$foo.
2. The variable wrapped in quotes: local var="$foo".

Neither seems like that big of a deal, so maybe I should just do it? I guess my question is, how common is Zsh 5.0.* still today? I guess I'm just looking for a "yeah support Zsh-5.0.X please" 😄

[OldCrow]

Well, I have at least one older computer running Mac OS X 10.11 which isn't going to get any zsh updates since those versions are OS components. Can't even upgrade zsh with Homebrew, because Homebrew doesn't support Mac OS X versions that far back.

I guess the question is, how many other OS (all the different Linux versions) are in a similar boat where a particular version people still use is too old to update some program beyond some upstream version.

Personally, I'd say "yes, please support zsh-5.0.X" because I like liquidprompt and want to use it on all my machines...but I also acknowledge that at some point, version support has to have a cut-off point for any program or utility. I have no illusions that if the cut-off for liquid prompt for an older Mac OS X version hasn't come today, it will one day.

[Rycieos]

I just added 0f98dbb to fix issues with Zsh-5.0.*, and 5bd80ce to add a check for Zsh versions less than 5.*, warn and exit.

I have run the test suite through many versions of Zsh (zsh-5.0.8, zsh-5.1.1, zsh-5.2, zsh-5.3.1, zsh-5.4.2, zsh-5.5.1, zsh-5.8) with no issues. I will be the first to point out that the test coverage is still lacking, but it's a start.