BASH 4.3.42 Errors - error importing fucntion definition for BASH_FUNC_module Fedora 23 (F23)

[taz77]

I have been trying to resolve this but I haven't been able to on my own. Hoping someone else here has some insight. Running the latest Drush (via Composer global install) I get errors in bash on Fedora 23 which is using Bash version 4.3.42.

This error:

sh: scl: line 1: syntax error: unexpected end of file
sh: error importing function definition for `BASH_FUNC_scl'

and:

sh: module: line 1: syntax error: unexpected end of file
sh: error importing function definition for `BASH_FUNC_module'

Repeats itself eight times per drush call. Drush still runs without a problem. Just blasts your terminal with loads of text.

I have axed the .drush/ folder and re-run drush init. That does not change the problem. Googling the error gets a lot of hits for many other issues.

Ideas?

[weitzman]

No idea.

Try Drupal Answers.

[taz77]

The problem is with Drush and the latest version of Bash shell. That is why I posted this here.

[taz77]

https://stackoverflow.com/questions/10496758/unexpected-end-of-file-and-error-importing-function-definition-error-running

[mtift]

I have also experienced this problem on Fedora. It's not clear to me where to put the unset module command.

[taz77]

Agreed. It's a compatibility issue that will grow once the newer versions of bash are more mainstream. They just don't realize it here yet. The maintainers are quick to close rather than diagnose.

[greg-1-anderson]

Not sure this is caused by new versions of bash; this apparently was a problem for some folks in 2011. See: http://gridengine.org/pipermail/users/2011-November/002019.html

I suspect that this problem is Fedora-specific. It would be helpful if a Fedora user could provide more diagnostic information on some of the suggested workarounds.

[mtift]

Hey, Greg! I run Debian on most of my machines, and I've never encountered this problem before. Previously, my workflow was to check out the drush git repo and then switch branches when I switched back and forth between Drupal 7 and Drupal 8 projects. I only encountered this on a newer laptop that seems to do (other tasks) better with Fedora (but not this), so I think you might be correct that this Fedora-specific. The errors I encountered looked exactly like the ones mentioned in the first comment of this issue.

However, apparently git branch switching is (no longer?) necessary. So for me the solution was simply to follow the install instructions on http://docs.drush.org/en/master/install/ and all seems to work, and I happily switch back and forth from D7 to D8. That might not work for others, but it suits my needs.

[taz77]

@greg-1-anderson All the probing and google searching I did came back to the shell script being executed. I spent a lot of time on it before I posted the issue here because my research had come to the conclusion that the problem is with the shell script.

The bash shell in Fedora is pretty far ahead of most distro's. My Mac only has v3.2.57 running Yosemite.

[taz77]

Here is an example of one of the things I found and it was mentioned on other pages that the issue was with semi-colons in the bash shell scripts. That all the lines needed to have semi-colons at the end.

https://stackoverflow.com/questions/10496758/unexpected-end-of-file-and-error-importing-function-definition-error-running

[taz77]

Here is another good blog post pertaining to the export function.
https://kb.brightcomputing.com/faq/index.php?action=artikel&cat=2&id=239&artlang=en

I will make a note to myself to spin up some other machines and see if I can replicate this in another distro.

[iamorangehat]

It appears the call to pcntl_exec is causing the message(s).
Not a drupal admin but our drupal admin asked me to take a look at it. He had me test using "drush8 core-status" as a test. To fix(?) I set $use_pcntl_exec = FALSE (below function_exists near line 326) to use proc_open instead of pcntl_exec in /includes/startup.inc and that eliminated the error. He still needs to do testing after this change to see if broke anything doing that change.
This a work-around as it is probably a bash or perhaps pcntl_exec problem. I'm still looking at it.

[taz77]

@iamorangehat I will give this a test too. Maybe post a patch for others to use in testing.

[iamorangehat]

After finding the command I felt was causing the issue, I noticed that if the function_exists returns a FALSE (if pcntl_exec function is not available) so it falls through to use proc_open. I added a line to force it to FALSE. We could have probably added pcntl to the disable_functions in php.ini and did the same thing without changing the startup.inc though not sure what parm in disable_functions, i.e. pcntl or pcntl_exec

[greg-1-anderson]

If function_exists('pcntl_exec') is returning FALSE, why did you need to force it to false? Was that a typo?

[iamorangehat]

No, I was getting TRUE on my system so I forced it to false so it fell through to proc_open. Sorry for the confusion.

[bperet]

I just installed Drush globally via composer on CentOS 6.8 and am getting the same error:

# drush status
sh: module: line 1: syntax error: unexpected end of file
sh: error importing function definition for `BASH_FUNC_module'
 PHP executable         :  /usr/bin/php
 PHP configuration      :  /etc/php.ini
 PHP OS                 :  Linux
 Drush script           :  /opt/drush-8.x/vendor/drush/drush/drush.php
 Drush version          :  8.1.2
 Drush temp directory   :  /tmp
 Drush configuration    :
 Drush alias files      :

If I "unset module" from BASH then it seems to work OK.

[taz77]

Fedora updates and Drush updates. This still spams the hell of out my screen every time I run drush.

drush cc all sh: module: line 1: syntax error: unexpected end of file sh: error importing function definition forBASH_FUNC_module'
sh: scl: line 1: syntax error: unexpected end of file
sh: error importing function definition for BASH_FUNC_scl' sh: scl: line 1: syntax error: unexpected end of file sh: error importing function definition forBASH_FUNC_scl'
sh: module: line 1: syntax error: unexpected end of file
sh: error importing function definition for BASH_FUNC_module' sh: scl: line 1: syntax error: unexpected end of file sh: error importing function definition forBASH_FUNC_scl'
sh: module: line 1: syntax error: unexpected end of file
sh: error importing function definition for BASH_FUNC_module' sh: scl: line 1: syntax error: unexpected end of file sh: error importing function definition forBASH_FUNC_scl'
sh: module: line 1: syntax error: unexpected end of file
sh: error importing function definition for BASH_FUNC_module' sh: scl: line 1: syntax error: unexpected end of file sh: error importing function definition forBASH_FUNC_scl'
sh: module: line 1: syntax error: unexpected end of file
sh: error importing function definition for BASH_FUNC_module' sh: scl: line 1: syntax error: unexpected end of file sh: error importing function definition forBASH_FUNC_scl'
sh: module: line 1: syntax error: unexpected end of file
sh: error importing function definition for BASH_FUNC_module' sh: scl: line 1: syntax error: unexpected end of file sh: error importing function definition forBASH_FUNC_scl'
sh: module: line 1: syntax error: unexpected end of file
sh: error importing function definition for BASH_FUNC_module' sh: scl: line 1: syntax error: unexpected end of file sh: error importing function definition forBASH_FUNC_scl'
sh: module: line 1: syntax error: unexpected end of file
sh: error importing function definition for BASH_FUNC_module' [notice] 'all' cache was cleared.

[iamorangehat]

Try this:
in /etc/php.ini
disable_functions = pcntl_exec

[taz77]

The above works!

[bke-daniel]

Same here on CentOS 6.x and 7. Installed via Composer.
Solution provided by @iamorangehat works, thanks lad!

[artforlife]

@iamorangehat Thanks, it worked on Amazon CentOS!

[nvaken]

How would you go about changing that value on a shared hosting solution? In that situation I'm - ofcourse - unable to edit the php.ini.

[iamorangehat]

@nvaken , Then you need alter drush so it doesn't use pcntl_exec by editing the code.
in directory: drush9/vendor/drush/drush/includes (or drush8 or whatever)
vi startup.inc
Find the lines below (usually somewhere near line 330)
// Always use pcntl_exec if it exists.
$use_pcntl_exec = function_exists("pcntl_exec");
And under those lines add:
$use_pcntl_exec = FALSE;
That should fix it.

[grayside]

This thread points to the function_exists() being an unpredictable indicator of function availability. Near the bottom of the thread is this idea:

strpos( ini_get( 'disable_functions' ), 'posix_getpwuid' )

So maybe we need to have two levels of checks for availability of pcntl_exec?

[febbraro]

This is exactly the problem I'm having. The function is disabled in php.ini, but function_exists is returning true.

[root@671d6f2970b3 /]# php -i | grep disable_functions
disable_functions => pcntl_exec => pcntl_exec
[root@671d6f2970b3 /]# php -r "print ini_get('disable_functions');"
pcntl_exec
[root@671d6f2970b3 /]# php -r "print function_exists('pcntl_exec') ? 'yes' : 'no';"
yes
[root@671d6f2970b3 /]# php -r "print strpos(ini_get('disable_functions'), 'pcntl_exec') === false ? 'no' : 'yes';"
yes

[whitingjr]

I came across the same compile error building Netty using Fedora. I installed the package libtool.x86_64. The installation provided the missing function definitions. Allowing my build to complete successfully.

[weitzman]

Fixed, AFAICT.

[manavk]

Solution provided by @iamorangehat works for me, thanks..!

[nerdoc]

I just downloaded Drush 8 via composer (for D7) on CentOS7 (host on uberspace.de), and it is not fixed there - is this just fixed in Drush9?

[iamorangehat]

You will probably need to still do this:
in /etc/php.ini
disable_functions = pcntl_exec

[nerdoc]

@iamorangehat Thanks, works perfectly.

[cristian100]

Wooonderful!! @iamorangehat it worked for me on CentOs 7 Thanks!

[greg-1-anderson]

It would be more helpful to focus on the solution by @whitingjr. Disabling pcntl_exec is an inferior solution that may have undesirable side effects on Drush 8, and probably makes Drush 9.6.0 nonfunctional.

[dexp-io]

Add the command below to ~/.bash_profile or ~/.bashrc file then logout/login again.

unset module

Or simple run quick command:

echo "unset module" >> ~/.bash_profile && source ~/.bash_profile

[dirkd]

Fwiw the core issue is how Drush8 is retrieving the system's shell environment. The code at

drush/includes/startup.inc

Lines 31 to 42 in 03539df

	if (empty($env)) {
	exec('printenv', $env_items);
	foreach ($env_items as $item) {
	// Each $item is 'key=value' or just 'key'.
	// If $item has no value, then explode will return
	// a single array, [0 => 'key']. We add a default
	// value of [1 => 'value'] to cover this case. If
	// explode returns two items, the default value is ignored.
	list($key, $value) = explode('=', $item, 2) + array(1 => '');
	$env[$key] = $value;
	}
	}

operates under the assumption that every environment variable printed by printenv occupies exactly one line. On Fedora-based systems (e.g. Fedora, CentOS, RHEL) this assumption does not always hold. On those systems the following environment variable is defined when the package environment-modules installed:

BASH_FUNC_module()=() {  eval `/usr/bin/modulecmd bash $*`
}

The origin of this envvar with a newline character is that the function containing a semicolon is exported into the environment via export -f in /usr/share/Modules/init/bash.

This is parsed into the the $env-Array by drush as:

array(
    [BASH_FUNC_module()] => () {  eval `/usr/bin/modulecmd bash $*`
    [}] =>
)

As this is passed into pctnl_exec() further down the line (

drush/includes/startup.inc

Line 422 in 03539df

$error = pcntl_exec($found_script, $arguments, $env);

) this causes the executing shell to emit the syntax error. Since $env is not used when executing via proc_open the error is only showing when using pctnl_exec().

So possible mitigations are indeed unsetting the env variable module in the calling environment - if you don't need its functionality - or populating $_ENV by adding E to the variables_order to skip the printenv-parsing.

To ultimately fix this the environment retrieval should probably be adjusted to cope with multiline environment variables.

[Peneheals]

It is still a problem, just got the above error in an RHEL 7.8 system. I agree with @dirkd : "To ultimately fix this the environment retrieval should probably be adjusted to cope with multiline environment variables."

It also worth to mention that the above mentioned disable_functions = pcntl_exec in the /etc/php.ini can temporarily fix the error.