id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	blockedby	blocking	branch_state	votes
3692	[PATCH] More sophisticated shell type detection method	alllexx88		"{{{
    * Make tests on shell binary instead of trying to guess shell type from
      path. Most supported shells set specific variables, hence by testing
      whether such variables are set, we can guess shell type in a more
      reliable way. This works with bash, zsh, tcsh and fish. For guessing
      dash or BusyBox ash (which are treated the same), we run a more peculiar
      test on whether shell supports expansion in PS1 as a prompt string. The
      latter test is also designed to diffirentiate a legacy pre 1.20 BusyBox
      ash, which allows to apply printf workaround in the case of such shell.
    * Remove chdir command from subshell initialization code, and use full
      paths for init_file instead. Changing dir only allows to use relative
      init_file paths, but can instead potentially lead to some problems, as
      previously noted in the comments; so by not doing this we add additional
      layer of protection against bugs.
    * Remove unneded SHELL_SH shell type, and 'name' mc_shell_t  field, since
      the latter was only being used as arg0 when initializing subshell, and
      it looks like all shells work fine regardless of arg0, except for zsh,
      (so we just leave arg0 as ""zsh"" for it), and we use path as arg0
    * Also add a little error verbosity in scope of detecting shell type and
      subshell initialization
}}}

This fixes such issues as:
* Detecting `bsd-csh` as `tcsh`, and wasting 10 seconds on launch while waiting CWD
* Detecting anything that's linked to `busybox` as busybox ash with CONFIG_ASH_EXPAND_PRMT enabled, and possibly wasting those 10 sec again
* Failing to detect a shell type if a version/arch/whatever is appended to its name
* Failing to detect a shell if it's just 'sh': some link resolving tests are being carried in master, but they can fail in many ways
* Leaving user wondering why they have no subshell (added verbosity isn't perfect, but at least it's a start)

This has been tested to recognize all supported shells correctly, and discard these shells with some verbosity immediately (saying which shells are supported, while this `$SHELL` not):
* bsd-csh
* BusyBox hush
* BusyBox ash with disabled CONFIG_ASH_EXPAND_PRMT
All regardless of their names (except the already mentioned zsh, and `busybox`: it needs the name to deduct the applet from it, but as long as `busybox` recognizes it, it's fine: either ash, sh, or bash)

I should also point out that beyond subshell initialization related functions different shell types are not being differentiated, so, say, we shouldn't worry about `bash` behaving in a bourne shell compatible way later on if it has been initialized fine.

Since almost all modern shell set some specific internal variables, adding new shells now boils down to finding a way to emulate `precmd` (if not present), choosing the right variable, and in case it uses syntax other then Bourne, C or Fish, adding a new test command for the syntax.

I have tried to comment new functions thoroughly, so I hope the code should be readable.

Hope this will be considered useful."	enhancement	new	major	Future Releases	mc-core	master						no branch