slibtool: https://dev.midipix.org/cross/slibtool/c/f23d994

There are instance of /bin/sh and /bin/bash being hard coded in slibtool.

    /* work around non-conforming uses of --mode=install */
    if (!(strcmp(iargv[0],"/bin/sh")) || !strcmp(iargv[0],"/bin/bash"))
        iargv++;

https://dev.midipix.org/cross/slibtool/blob/f23d994/f/src/logic/slbt_exec_install.c#_593

    /* work around non-conforming uses of --mode=uninstall */
    if (!(strcmp(iargv[0],"/bin/sh")) || !strcmp(iargv[0],"/bin/bash"))
        iargv++;

https://dev.midipix.org/cross/slibtool/blob/f23d994/f/src/logic/slbt_exec_uninstall.c#_280

This is a problem because users could end up using a different shell.

export CONFIG_SHELL=/bin/dash

And then in sudo they end up executing the following command.

INSTALL_BACKUP='' slibtool --tag=disable-static --quiet --mode=install /bin/dash ../../install-sh -c -o 0 -g 0 libsudo_util.la /var/tmp/portage/app-admin/sudo-1.9.5_p2-r1/image/usr/libexec/sudo;

With one of the hard coded shells it will pass the options, -c -o 0 -g 0 to install-sh while with with another shell such as /bin/dash or /bin/mksh it will pass the options to the shell instead which is not correct.

GNU libtool does not have a problem with this.

It also arguable that sudo should not be doing this and that users should stick to CONFIG_SHELL=/bin/sh, but it would be much better if the shells were not hard coded at all.

The list of shells can also be grown, but that will be a potentially moving goal post which would not be ideal to maintain.