Why doesn't `concurrently` use the shell it's being executed in?

[ursi]

I'm trying to use concurrently to execute some bash functions in my shell that work fine when executed alone. However, they fail when being run with concurrently. After adding echo $0 to the functions, I realized that they're failing because concurrently is executing them with /bin/sh instead of bash.

[gustavohenke]

Because that's hard to do properly.
concurrently used to, back in v3.0.0 to <3.3.0, but it caused some fun issues, such as #61.

Checking $SHELL is generally OK, however, if you start a different shell type (e.g. from /bin/bash, start /bin/zsh), $SHELL will still reflect the old value.
On Windows, there's %COMSPEC%, but that's just the default shell, not the current one.

To determine the current shell with precision, it's necessary to run something like ps -p $$, but that's an extra process that the user mightn't be expecting + it's slightly more costly than env variable checking.
Maybe not too important?

I'd be happy to tackle this and actually run on current shell, but debugging issues for me as a maintainer becomes quite hard when the shell detection is environment-depending.

[ALameLlama]

I understand testing all the situation might be difficult, would it be possible to put this behind some kind of optional flag? with a warning saying things might not work as expected?

[gustavohenke]

Yeah! I think something like an env variable CONCURRENTLY_SHELL=<current | /some/shell/bin> concurrently ... would provide a good enough transition in case this proves stable enough?

[ALameLlama]

Yeah sounds good, I noticed concurrently running as sh being an issue when I was trying to get zsh/bash hooks to fire off but wasn't. hopefully being able to change that will make it more flexible