I have a simple php script which parses the user input from html form. Since Python does string processing so well, I actually wrote the parser in python. So I forward the user entered string to python script for processing using
$query = "avocados"; // from HTML form
$handle = popen("./NLParser.py $query","r");
$read = fread($handle,2048);
pclose($handle);
when I execute the php from command line interpreter, I get the desired output. But when I visit the same php file from a browser, I get empty string from fread(). I tried checking if the $handle is FALSE and I also read from stderr, no problems there. Please help me figure out this inconsisteny.
I tried running
phpinfo();
The php.ini file used by command line php interpreter was
Loaded Configuration File => /etc/php5/cli/php.ini
and the same entry on web was
Loaded Configuration File /etc/php5/apache2/php.ini
I am using Ubuntu 14.04.1 LTS with PHP Version 5.5.9-1ubuntu4.4. All the files have permission set to 755
Try changing the owner and group of NLParser.py to the ones of your server.
Related
I've set up a small web app that passes user data to a python script. Python is supposed to go to work, create a file on the webserver, and allow the user to download it. However, the script execution seems to stop where the Python write() command is issued.
Python:
print("Writing to '" + filename + "'")
f = open('backups/' + filename, 'w')
f.write(self.output())
f.close()
print("Done!")
PHP:
$user = escapeshellarg($_POST['user']);
$password = escapeshellarg($_POST['password']);
$command = './backup.py '.$user.' '.$password;
print(exec($command));
Actual result:
Python does create a file in the desired directory but it remains empty. 2. Python never outputs "Done!" (Because permissions are denied)
Expected result:
Python creates a file with data
Python proceeds to print "Done!" which is output to the calling PHP script
I've done the following:
www-data has group write permissions (drwxrwsr-x) for the directory ./backup
The #!/usr/bin/env python3 shebang is present in the python file
The python file is executable
When I change to user www-data with sudo su www-data and then start the php commandline, and enter the above command invoking my Python script, the file is created correctly!
If I start a builtin php server, it also works fine, only if the php script is handled through apache, it doesn't work
I have officially wasted an entire day of my life on this.
The permissions were all right.
What was happening is that the python script failed ONLY if it was being invoked through my php script and ONLY if that was being served by Apache.
Looking through the Apache error log revealed that the python script failed because it could not write bytes to the file and ascii conversion failed because there was unicode data in the output.
So doing f = open(filename, 'wb') solved the issue.
This behaviour was not observed on my development machine or through the built-in PHP server. Still wonder why there's a difference in file handling. Would appreciate an answer if anyone has one.
I have a php script which calls a shell script as below -
#!/bin/bash
timestamp=$(date +"%d-%m-%Y %H:%M:%S")
echo $timestamp >> results
The php script -
<?php
$mycmd = exec('/bin/bash exectest.sh',$op,$er);
var_dump($mycmd);
var_dump($op);
echo $er."\n";
?>
The php script returns error code 1 for $er but when i tried to modify the shell script to just print instead of writing to a file. the Php script then returns 0 and succeeds.
Any ideas of where I need to fix this?
I have tried giving the full path for the script and also this is the same case when i tried using a python script in place of a shell script.
Your observation indicates that this is most likely a permission problem, e.g. the user running PHP does not have write permission to either the results file in its current working directory or the directory itself (if the file does not exist yet).
It happened to be running on an AFS machine hence required afs priviledges for httpd.
fs sa . http write
sorted the issue.
I've a PHP script that uses cURL to perform certain tasks. At the moment, I have the script running every 10 minutes. This is what I'm running via Windows Task Scheduler.
C:\wamp\bin\php\php5.4.3\php.exe -f C:\wamp\www\autoscripts\index.php
However, for some reason, whenever the argument quoted above is run through the command line, I get the error "Fatal error: Call to undefined function curl_init()". The script works perfectly when I access it via the browser. Is there any reason why PHP isn't able to access the cURL extension via the command line?
Most likely running from command line does not use any ini file that loads the extensions. Open phpinfo() from the browser, copy path to loaded ini file and change your task to:
C:\wamp\bin\php\php5.4.3\php.exe -c "C:\path\to\php.ini" -f C:\wamp\www\autoscripts\index.php
Figured it out. Basically, on WampServer, there are TWO php.ini files that you need to be aware of.
C:\wamp\bin\php\php5.4.3\php.ini
C:\wamp\bin\apache\apache2.2.22\bin\php.ini
Forgot that the command line uses a different ini file than the web server. :(
I have ImageMagick, IIS 6, Ghostscript, and PHP 5.3.1 installed on a Windows Server 2008 box and am trying to convert a PDF file into a JPG thumbnail.
However, it doesn't seem to be working-- the call to exec() produces a return code of 1 (which to my understanding, means that some general error has occurred). The output variable is simply an empty array. $output is simply an empty array. The same occurs if I use system() instead of exec()
Running the command from the command line seems to work, so my initial guess would be a simple permission issue... The directory is writable by PHP because the script that uploads a PDF to the directory works, and I have verified that everyone has permission to write to the directory as well.
Also, safe mode is off.
Any ideas as to what the issue could be?
Relevant code:
<?php
$output = array();
$ret = 0;
echo exec('convert D:\content\myfile.pdf[0] D:\content\myfile_thumb_1.jpg', $output, $ret);
var_dump($ret);
?>
Note: While I would test this on Apache on Mac OS X, I can't seem to get ImageMagick or Ghostscript installed correctly.
I've also ensured the following:
Correct case for the file names (all lowercase anyways)
Using the full path of convert.exe in addition to simply convert.exe
UPDATE:
After checking the task manager, convert.exe is being run and is taking up CPU time, suggesting to me that it is file permissions of some sort... I'm going to check it out now.
It turns out there was a permission issue with something in IIS-- the website ran under a different user than the command from CMD, which obviously results in it not working under IIS because it has lesser permissions than from CMD.
Ok, I am trying to create an email logger, that uses a PHP shell script. I have set up CPanel to pipe emails to my script. I am sure this is all configured properly. However I am having problems with the script, well any script for that matter when running it from the shell.
here is an example.
#!/usr/local/bin/php –q
<?php
/* Read the message from STDIN */
$fd = fopen("php://stdin", "r");
$email = ""; // This will be the variable holding the data.
while (!feof($fd)) {
$email .= fread($fd, 1024);
}
fclose($fd);
/* Saves the data into a file */
$fdw = fopen("mail.txt", "w+");
fwrite($fdw, $email);
fclose($fdw);
/* Script End */
?>
Real simple, right? Read from STDIN and write to a file...I thought something was wrong, not able to read STDIN for some reason. Hosting provider allows it, allow_url_open and allow_url_include are both on.
When executing the script via SSH I get the following error:
Could not open input file: âq
So once again I thought that was the script telling me, that is could not read from STDIN
So I tried just a simple script.
#!/usr/local/bin/php –q
<?php
echo 'Hello World';
?>
Same thing:
Could not open input file: âq
So it appears that the PHP program is telling me it is unable to open the script? The script is located in $HOME/mail/forward (CHMOD 755) and the script itself is CHMOD 755, as well the file mail.txt is CHMOD 755
I am really stumped on this.
I just experienced this issue and it was because I was trying to run a script from the wrong directory.. doh! It happens to the best of us.
Have you tried:
#!/usr/local/bin/php
I.e. without the -q part? That's what the error message "Could not open input file: -q" means. The first argument to php if it doesn't look like an option is the name of the PHP file to execute, and -q is CGI only.
EDIT: A couple of (non-related) tips:
You don't need to terminate the last block of PHP with ?>. In fact, it is often better not to.
When executed on the command line, PHP defines the global constant STDIN to fopen("php://stdin", "r"). You can use that instead of opening "php://stdin" a second time: $fd = STDIN;
I landed up on this page when searching for a solution for “Could not open input file” error. Here's my 2 cents for this error.
I faced this same error while because I was using parameters in my php file path like this:
/usr/bin/php -q /home/**/public_html/cron/job.php?id=1234
But I found out that this is not the proper way to do it. The proper way of sending parameters is like this:
/usr/bin/php -q /home/**/public_html/cron/job.php id=1234
Just replace the "?" with a space " ".
Windows Character Encoding Issue
I was having the same issue. I was editing files in PDT Eclipse on Windows and WinSCPing them over. I just copied and pasted the contents into a nano window, saved, and now they worked. Definitely some Windows character encoding issue, and not a matter of Shebangs or interpreter flags.
When you use php CLI argument -q doesn't exist.
I had the same problem when I wrote script in the Windows (eclipse) and I tried run them on Linux. Every line in file from Windows is ended by \r\n. I had to delete \r in first line that contained parser path:
When \r was deleted from first line (mcedit shown \r as ^M) script ran correctly.
Due to windows encoding issue for me
I experienced this "Could not open input file" error. Then I obtained the file using wget from another linux system, and the error did not occur.
The error ws only occurring for me when the file transited through windows.
I know its stupid but in my case i was outside of my project folder i didn't have spark file.
For me the problem was I had to use /usr/bin/php-cgi command instead of just /usr/bin/php
php-cgi is the command run when accessed thru web browser.
php is the CLI command line command.
Not sure why php cli is not working, but running with php-cgi instead fixed the problem for me.
The actual root cause is that the hyphen before "q" on the first line is actually not a standard ASCII hyphen(U+002D), but an en-dash(U+2013). The "a" with the funny hat that PHP reported was the first clue, and then if you look closely the "dash" is too big. This is the kind of thing word processors do to code.