| Summary: | app-admin/eselect-sh: zsh should not be present in SYMLINK_TARGETS | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | kfm |
| Component: | Current packages | Assignee: | Michał Górny <mgorny> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | radhermit |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Do you have a more recent example of zsh being incompatible? I suspect it has gotten better since 2007. The release notes for ash 5.0 specifically mention several enhancements in this area. (In reply to Mike Gilbert from comment #1) > Do you have a more recent example of zsh being incompatible? I suspect it I spoke to someone earlier this very morning in #gentoo who had recently switched to zsh, upgraded/rebuilt glibc and encountered exactly the same symptoms as described in bug 180259. I instructed him to switch to dash and rebuild glibc, upon which he reported the problem as solved. This, alone, ought to be sufficient justification for my request. > has gotten better since 2007. The release notes for ash 5.0 specifically > mention several enhancements in this area. Any shell designated as /bin/sh should be able to correctly execute any script that is written according to the specifications of the Shell Command Language. Merely suspecting that zsh is compliant isn't enough. From time to time, I've seen some of the greybeards in #bash - most of whom are exceptionally well versed in the various shell dialects - mention zsh gotchas. I don't log the channel, otherwise I would paste some of their examples. If I recall correctly, there are some situations in which it does not propagate the exit status in the same way as other shells. SpanKY stated unequivocally that it is not compliant and I would tend to take what he says seriously. I also found this gem in /usr/bin/gettext.sh ... # sed -n '42,46p' /usr/bin/gettext.sh # zsh is not POSIX compliant: By default, while ". gettext.sh" is executed, # it sets $0 to "gettext.sh", defeating the purpose of this test. But # fortunately we know that when running under zsh, this script is always # being sourced, not executed, because hardly anyone is crazy enough to # install zsh as /bin/sh. Pleae, let's remove it. It's bad enough that gentoo already defaults to bash (for reasons that are beyond the scope of this bug), without breaking things by switching to zsh. As I mentioned before, some people are switching /bin/sh in the wake of shellshock, completely oblivious as to the implications. @radhermit, any opinion on zsh side of this? (In reply to Michał Górny from comment #3) > @radhermit, any opinion on zsh side of this? zsh is still not fully POSIX compliant although it can be made more so by setting various options which generally aren't enabled by default since they take away some of the extended functionality provided by zsh. Personally I've never pointed /bin/sh to zsh as I've considered zsh to be focused on interactive use and extensibility through it's own globbing language and syntax. In terms of removing it as an option from eselect-sh, I don't care one way or the other since people really wanting to do so will just do it manually, but if you want eselect-sh to only list fully POSIX compliant shells, zsh shouldn't be on the list. +*eselect-sh-0.4-r2 (06 Oct 2014) + + 06 Oct 2014; Michał Górny <mgorny@gentoo.org> +eselect-sh-0.4-r2.ebuild, + +files/sh.eselect-0.4-r2, -files/sh.eselect-0.4-r1: + Remove zsh due to POSIX incompatibilities, bug #524572. Also remove busybox, + this time for real. + 06 Oct 2014; Michał Górny <mgorny@gentoo.org> -eselect-sh-0.4-r1.ebuild, + -files/sh.eselect-0.4, eselect-sh-0.4-r2.ebuild: + Transfer stable keywords (only broken implementation was removed) and remove + old. |
eselect-sh presents zsh and allows it be set as /bin/sh. # eselect sh list Available POSIX shell implementations: [1] bash [2] dash * [3] zsh [4] posh [5] busybox However, zsh is not appropriate for use in this context. See bug 180259 as an example. I recently spoke to someone else in #gentoo who had made the same mistake. I believe that there has been an upsurge of such activity in the wake of the Shellshock incident. Please remove zsh from SYMLINK_TARGETS.