composer icon indicating copy to clipboard operation
composer copied to clipboard

Wrapper for shell binaries does not handle signals

Open Chi-teck opened this issue 1 year ago • 3 comments

Currently the shell wrapper starts a sub-process for the original binary. The can mess POSIX signal handling. Can it use source or exec instead?

Also wonder if there is a way to install package binaries without wrappers.

Ref: https://github.com/drush-ops/drush/issues/6137

Chi-teck avatar Oct 18 '24 04:10 Chi-teck

The binary proxies in vendor/bin/.. are not wrapper processes, they are just php scripts including the original file, so that should not cause any problems in terms of signal handling.

I assume the problem you see is when using composer scripts to run a binary via a script handler?

Seldaek avatar Oct 19 '24 20:10 Seldaek

Sorry I had a look at the drush issue, and I have more context now, so my question there would be.. why isn't it the bin/drush not just a php script? Because I'd think if you use ./vendor/bin/drush.php example it works as well, and it's just the bash proxies that are causing trouble.

But anyway we probably should fix it if it's borked, I'll need to investigate this some more and try to repro it though.

Seldaek avatar Oct 19 '24 20:10 Seldaek

@Seldaek drush ships a shell-script (https://github.com/drush-ops/drush/blob/13.x/drush) as primary entrypoint. Its only task is to disable xdebug (export XDEBUG_MODE=off). It is a lightweight alternative to https://github.com/composer/xdebug-handler. It calls drush.php afterwards.

Afaik its not possible to do it in php, because the env var needs to be present before the php-process is started.

webflo avatar Oct 19 '24 21:10 webflo