• Antipole

    (@antipole)


    I hope SKS can help here… I use a great plugin called SitePush to synchronise between my live and test sites. Unfortunately, SitePush was abandoned some years ago by its developer, so there is no support. It has continued to work well for me – until very recently.

    I have found the problems, but do not understand why it is failing. It checks that it has access to mysql, mysqldump and rsync with, as one example, the code:

    if( ! @shell_exec("mysql --version") )
    			SitePushErrors::add_error( 'mysql not found, not configured properly or PHP safe mode is preventing it from being run.' );

    This test is failing, in that null is being returned and the error case set up.
    However, if I execute the shell command “mysql —version” it does return the version details, so it seems to be configured properly. SafeMode is OFF.

    Now for the oddity: if I comment out the test and let it proceed despite the error, everything works as it should – the calls using shell_exec to invoke mysql work fine. [This further confirms that SafeMode is indeed off.]

    So it appears to be a problem with returning the result of shell_exec.

    So what has changed since it was working as intended? I have updated to WordPress 5.2. Also I moved up to PHP 7.1. I have reverted to PHP 5.6, the lowest that WP 5.2 allows, but this has not fixed it.

    So I could just remove the checks and things appear to work. But that seems foolhardy.

    If someone can suggest why this problem has arisen, I would really appreciate it.

Viewing 3 replies - 1 through 3 (of 3 total)
  • Kyle Pott

    (@kylepott)

    Good afternoon! Since the check is calling for the shell to launch mysql with the version flag, my guess is that there may be logic comparing versions further in the script. Since the software is out of date, you may have updated an application beyond what the original script was expecting. Alternatively, there could be a parsing error with the mysql version return string.

    If the original developer simply wanted to verify that mysql was installed, another way they could have implemented this check would be: which mysql or locate mysql which return the paths of the mysql binaries – which, in my opinion, are more helpful than asking for the mysql version.

    Have you inspected the code to see if version numbers are compared elsewhere? It’s my opinion that simply avoiding this check would be fine. As you’ve said, you’ve verified that the code is still working and this seems like a trivial validation to me.

    Kyle

    • This reply was modified 7 years ago by Kyle Pott.
    DesignSmoke

    (@designsmoke)

    It might be easier to just check that the MySQL module is installed in php, as it relies on MySQL in the first place:
    eg:
    function_exists('mysql_connect')
    or
    extension_loaded('mysql') || extension_loaded('mysqli')

    Thread Starter Antipole

    (@antipole)

    Thanks for the suggestions.

    The plugin has a settings page, which uses the function_exists approach and confirms that all is well. The shell_exec to read the version number seems to be an extra belt & braces check before starting the work. It does not check the version number – merely that the call returns something.

    I have removed these final checks, given the settings page checks anyway, and all now works as it should. That leaves me vulnerable to loss of the functions, when I would need to return to the settings page to sort that out. But that is a small price to pay for getting the plug in functioning again.

    Thanks again.

Viewing 3 replies - 1 through 3 (of 3 total)

The topic ‘Problem with returning value from shell_exec’ is closed to new replies.