I have a bash script to extract information from exim_mainlog. When the bash script is run from a putty command line (logged in as root), the extracted data is properly written to an output file. However, when the bash script is invoked from a PHP webpage, the grep results are written to the output file, but the exigrep results are not. The PHP webpage lives in a cPanel account.

It does not seem to be a permissions issue because the grep extract from the exim_mainlog, is properly written to the output file while the exigrep extracts are not.

Here is my PHP:

   $output=shell_exec("sh /home/account/public_html/cgi-bin/Log.sh");

Here is the bash script with 3 attempts to extract data. All three work when the script is invoked by the command line "sh /home/account/public_html/cgi-bin/Log.sh", but only the grep results are written (and the exigrep results are not written) when the bash script is invoked by the PHP script:


# grep attempt consistently writes data to the temp.log file
echo "grep" > /home/account/public_html/cgi-bin/temp.log # just a label so the source of the results is known

  grep  "email address" /var/log/exim_mainlog |\
  sed -r -e 's/[[<>]/"&"/g' >> /home/account/public_html/cgi-bin/temp.log

# exigrep attempts do not work when invoked with the PHP above
echo "exigrep" >> /home/account/public_html/cgi-bin/temp.log # just a label so the file location where the exigrep results should be is known
  exigrep  "email address" /var/log/exim_mainlog |\
  sed -r -e 's/[[<>]/"&"/g' >> /home/account/public_html/cgi-bin/temp.log

  exigrep  --no-pager "email address" /var/log/exim_mainlog |\
  sed -r -e 's/[[<>]/"&"/g' >> /home/account/public_html/cgi-bin/temp.log

I also tried "exec" instead of "shell_exec" with the same results.

Based on Fox comment below, I looked to see if the permissions for exigrep were different than that of grep; they were the same (others can execute).

  • do you encounter the same problem if using the full path to exigrep?
    – Fox
    Nov 16, 2020 at 5:42
  • Same results using the path ./usr/sbin/exigrep. Thanks for the suggestion; I'm curious why you thought that might make a difference.
    – Mike A
    Nov 16, 2020 at 15:44
  • 1
    ./? not /? my thought was perhaps exigrep might not be in the PATH when run by php
    – Fox
    Nov 16, 2020 at 20:48

1 Answer 1


In pursuing the inability of PHP called bash script to run/provide exigrep results, I copied the exigrep file located in /usr/sbin/exigrep to the local account directory containing my PHP file. When I changed the bash script exigrep calls to /home/account/public_html/cgi-bin/exigrep, the log file extract worked properly.

So at least I have a workaround.

I conclude that my original problem is not a linux issue but rather a PHP issue. It appears that for some reason PHP cannot execute the system copy of exigrep. Perhaps the fact that it is a Pearl script is a factor.

To further explore this I made a simple exigrep call from the PHP directly (no bash script involved):

$output = shell_exec('exigrep email /var/log/exim_mainlog');
echo "<pre>$output</pre>";

which did not work.

However when my account located copy of exigrep was called, it works correctly:

$output = shell_exec('/home/account/public_html/cgi-bin/exigrep email /var/log/exim_mainlog');
echo "<pre>$output</pre>";

It would be beneficial to understand this better, in that if all Perl scripts will be problematic in this manner, one would have to copy all those needed to the local account directory. Naturally it would be better to change whatever is preventing the exigrep script from being executed in its normal "home".

This is not a very robust solution, but rather a workaround that lets me get results and perform my investigations.

  • It would be interesting to see what your PATH looks like when you run shell_exec. Maybe perl or exigrep aren't accessible from it.
    – Joe
    Nov 22, 2020 at 4:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .