Changing default shells on linux systems from bash to ksh or zsh or even fish is a good idea. I have written a blog post on how to change standard login shell on a system.

If it is done other ways, which might work correctly, it might break your system on a very subtle level and you will not even notice what is wrong. I had a system that was building all packages without problem an issue existed while installing certain ebuilds. The first ebuild that failed installation was x11-libs/libpciaccess this was the first error:

make[2]: Leaving directory '/var/tmp/portage/x11-libs/libpciaccess-0.13.5/work/libpciaccess-0.13.5-abi_x86_64.amd64'
make[1]: Leaving directory '/var/tmp/portage/x11-libs/libpciaccess-0.13.5/work/libpciaccess-0.13.5-abi_x86_64.amd64'
libtool: line 916: print: command not found
libtool: line 4964: print: command not found
libtool: line 5002: print: command not found
libtool: line 2502: print: command not found

It looks as if libtool was broken. But re-emerging x11-libs/libpciaccess did not bring a solution to this particular installation issue. It was not imidiatelly obvious what has been the source of this issue.

Another ebuild had also a installation issue. Before reading the following error message one would need to know zsh has been set as the default login shell for users and for the root. Back to the error message that has been printed while installing app-editors/gvim :

>>> Source compiled.
>>> Test phase [not enabled]: app-editors/gvim-8.0.1298

>>> Install gvim-8.0.1298 into /var/tmp/portage/app-editors/gvim-8.0.1298/image/ category app-editors
make -j2 -C src DESTDIR=/var/tmp/portage/app-editors/gvim-8.0.1298/image/ DATADIR=/usr/share install-icons
make: Entering directory '/var/tmp/portage/app-editors/gvim-8.0.1298/work/vim-8.0.1298/src'
if test -n "/var/tmp/portage/app-editors/gvim-8.0.1298/image/"; then \
        /bin/sh install-sh -c -d /var/tmp/portage/app-editors/gvim-8.0.1298/image//usr/share/icons/hicolor/48x48/apps /var/tmp/portage/app-editors/gvim-8.0.1298/image//usr/share/icons/locolor/32x32/apps \
    /var/tmp/portage/app-editors/gvim-8.0.1298/image//usr/share/icons/locolor/16x16/apps /var/tmp/portage/app-editors/gvim-8.0.1298/image//usr/share/applications; \
fi
if test -d /var/tmp/portage/app-editors/gvim-8.0.1298/image//usr/share/icons/hicolor/48x48/apps -a -w /var/tmp/portage/app-editors/gvim-8.0.1298/image//usr/share/icons/hicolor/48x48/apps \
    -a ! -f /var/tmp/portage/app-editors/gvim-8.0.1298/image//usr/share/icons/hicolor/48x48/apps/gvim.png; then \
   cp ../runtime/vim48x48.png /var/tmp/portage/app-editors/gvim-8.0.1298/image//usr/share/icons/hicolor/48x48/apps/gvim.png; \
   if test -z "/var/tmp/portage/app-editors/gvim-8.0.1298/image/" -a -x "" \
           -a -w /usr/share/icons/hicolor \
           -a -f /usr/share/icons/hicolor/index.theme; then \
         -q /usr/share/icons/hicolor; \
   fi \
fi
zsh:9: parse error near `fi'
make: *** [Makefile:2621: install-icons] Error 1
make: Leaving directory '/var/tmp/portage/app-editors/gvim-8.0.1298/work/vim-8.0.1298/src'

Finally a error message that gives slight hints and specifically this particular line:

    zsh:9: parse error near `fi'

The troublemaker is then zsh. Users and roots login shell has been then switched back to the default /bin/bash.

chsh -s /bin/bash

Now everything should be all right. After building the affected ebuild this issue still persisted. Even if the login shell has been revered to its default value, here a installation issue that hit app-text/ghostscript-gpl :

mkdir -p /var/tmp/portage/app-text/ghostscript-gpl-9.21/image//usr/share/ghostscript/9.21/Resource
/bin/sh -c 'for dir in `ls ./lib/../Resource | grep -v CVS` ; do \
  rdir=/var/tmp/portage/app-text/ghostscript-gpl-9.21/image//usr/share/ghostscript/9.21/Resource/$dir ; \
  test -d $rdir || mkdir -p $rdir ; \
  for file in ./lib/../Resource/$dir/*; do \
    if test -f $file; then ./base/instcopy -c -m 644 $file $rdir ; fi \
  done \
done'
zsh:6: parse error near `done'
make: *** [base/unixinst.mak:125: install-resdata0] Error 1

So what has been done wrong that portage still used zsh as shell? Did portage use zsh still as shell? To find the cause of this error the help of the IRC channel was needed and the helpful people in #gentoo on freenode. The source of this issue was a symlink that has been made in the /bin directory to point to zsh :

user@host $ ls -l /bin/sh
lrwxrwxrwx 1 root root       3  2. Mai 18:59 sh -> zsh

On gentoo systems, possibly on other distributions as well, this particular symlink should point to /bin/bash, like in here:

lrwxrwxrwx 1 root root 4 Jan  4 03:18 /bin/sh -> bash

Now the error messages have not given obvious hints and it took me some time to find this out. Additionally it was not my own system that has affected. It is important if one wants to change the login shell, to set it the right way. Since if it done the clumsy way, even if it is working, it might give a error when one has forgotten about it and the clues will not point down directly to the source of a problem.