Re: Bug in zsh-3.1.5

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Nov 7, 10:20am, Martin Birgmeier wrote:
} Subject: Bug in zsh-3.1.5
}
} $ echo echo "${HOSTTYPE:-$OSTYPE}:${TERM}:${TTY}"       <--- informational
} freebsd2.2.7:xterm:/dev/ttyp0
} 
} $ case "${HOSTTYPE:-$OSTYPE}:${TERM}:${TTY}" in        <--- DOES NOT WORK
} freebsd*:xterm:* | freebsd*:xterms:* )
} echo yes
} ;;
} * )
} echo no
} ;;
} esac
} no
}
} It seems that the second choice of the first case label controls the truth
} value of the expression!

Actually, it's the first alternative in that label that is at fault, and
it only incidentally has to do with the new grouping syntax.

The pattern match fails in matchonce() after executing the code at about
line 2497.  The comment on line 2496 says:
	    /* optimisation when next pattern is not a closure */
The current pattern at this point is the "*" just to the left of the "|"
and the next pattern is the empty string.  The text being matched is
"/dev/ttyp0", the "freebsd2.2.7:xterm:" part already having correctly
matched.

Up at around line 2217, in doesmatch(), this condition failed:

	    if (STARP(c) && c->next &&
		!c->next->left && (looka = *c->next->str) &&
		!itok(looka)) {

because *(c->next->str) is 0 -- which means that even though STARP(c) is
true, it didn't consume "/dev/ttyp0" before calling matchonce().

Now, arguably the empty string ought to match anywhere, so one possible
fix is to change the condition above to:

	    if (STARP(c) && c->next && !c->next->left &&
		((looka = *c->next->str) && !itok(looka) || !looka)) {

However, I'm concerned that the real problem is that the pattern was not
parsed correctly, i.e. the trailing empty string should never have been
there in the first place; so I'm reluctant to recommend that change.  I
don't have time to re-learn the pattern-parsing code just now. :-/

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com