I try to execute a command "wget" to download a file on my server A and then execute a python who will scrypt argument in this file.
My script:
switch ($_POST["parse"]) {
case 'parse1':
shell_exec("wget http://localhost/".$file_path);
shell_exec("python /opt/lampp/htdocs/mysite/api/scripts/script_parse.py ".$file_path." 1");
echo $file_path;
break;
default:
echo "no";
break;
}
However (I'm with local xampp under debian), the file is not downloaded and I have a page that loads into space when I try to execute the script (with or without file) but that does nothing .
So I'm looking since last night but I can not.
Besides, I like to avoid that the page load until the end of script execution.
Instead of shell_exec() and wget to download the file, use "file_get_contents()`. It supports both the HTTP and the HTTPS protocols, among many others, and it'll also give you an informative error message if downloading fails.
You will also need to add some error handling to your code, as stated in the comment by Arek. Since that is the only way you can properly handle the situations where something goes wrong, and they will. Not only for your sake, to make it easier to detect and debug, but also for your users.
Read the PHP manual, find out what values the different functions return in case of errors, and check against these. If any of the functions does return an erroneous value, then show an error message to the user and abort the rest of business logic (the stuff your code is really meant to do).
Related
In a php script I have some test and after the script the html page.
When a test fail i call die("Test 1 failed");
If no test fail the php script reach the end ?> and then load the html code after the php script.
Is this a good procedure? Or I need to write die() or exit() before the end of php script?
No you don't have to write that and this is not best practice. If the script reaches the end without fatal errros it will exit.
If this means "testing" for you, you're wrong. Testing should be done using unit tests. For php there is phpunit. Give it a try, that's the proper way of testing your code.
Edit: As CompuChip says in a comment, the only useful use case for exit is when you're writing a php based shell script that should return an error code. See the parameter section of the documentation for the exit() function.
You should never be using die() or exit in your production PHP scripts except in very specific cases. Instead, re-work your code paths to simply show an error message to the user rather than exiting the script early.
No you don't need that, but when writing console PHP scripts, you might want to check with for example Bash if the script completed everything in the right way. That's when you use exit() or die()
Is the die() or exit() function needed in the end of a php script?
No, PHP will end the script itself. If the script is an included file (called from another file) then it will end script in the included file and then continue with any code in the original file after where you included (if there is any code).
So you put die() or exit() where ever you want or need it.
For testing, put it after each block of code you test. I use them in some parts of testing if I just want PHP to show me something then stop, such as print out an array to make sure it's being constructed correctly etc.
eg:
print_r($array);
exit();
For other code tests, I sometimes just echo "Section A worked", etc, such as within if/else. If I want to know if a particular part of code is working or if some criteria is being met or not (basically, it lets you trace where PHP itself is going within your code).
All that said, don't use die() or exit() in production code. You should use a more friendly and controlled messaging setup. For security reasons and visual, as you could potentially give them some info like "ERROR Failed to load SomethingSecret". Also it doesn't look pretty when you page only half loads and then puts out an on screen error message which likely means nothing to the end user.
Have a read through this:
PHP Error handling: die() Vs trigger_error() Vs throw Exception
No !
This is not recommanded to use it
Use trigger_error or error_log to log the tests in your error.log. Then check it.
No you don't have to use these functions at the end of the script, because it exists anyway at the end of the script.
No need to put a die or an exit at the end of the scipt.
But you may use exit to terminate your script with a specific exit code (by default it's 0).
E.g
$ php -r "/* does nothing */;"
$ echo $?
0
$ php -r "exit(123);"
$ echo $?
123
http://php.net/exit
From the documentation:
The link to the server will be closed as soon as the execution of the
script ends, unless it's closed earlier by explicitly calling
mysql_close().
https://secure.php.net/function.mysql-connect
Nope, you don't need to call die() or exit(0 if you have another code to run, like you HTML code
Well this isn't true, I'm sure there's a reason, but I can't find it!!
I have a script that can take around 10 minutes to execute. It does a lot of communicating with an api on a service that we have that use. It pulls a bit of a fingerprint of everything every 24 hours. So what it's doing is pretty aside from the point. the probm I'm finding is the script stops executing somewhat randomly!!
I can't find any errors that would cause my script to stop executing, even with
//for debugging
error_reporting(E_ALL);
ini_set('display_errors', '1');
on for debugging, it's all clean. I've also used
set_time_limit(0);
so that it shouldn't ever time out.
With that said, I'm not sure how to get any more debug info to figure out what it's stopping. I can say that the script should NOT be hitting any memory limits or anything. I mean that should throw an error, and I've gone through and cleaned this script up as much as I can see to clean it up.
So my Question is: What are common causes for a cron ending when it shouldn't? How can I debug this more effectively?
You could try using a register_shutdown_function() to define a codeblock that will execute when the script shuts down. Then create a variable across the main code execution points in the cron with details of what is going on. In the shutdown function write this into a log and check your log to see what state the program was in when it stopped. Of course, this is based on the assumption that your code is not totally erroring out.
You could also redirect the standard echo statements and logs into a log file by using
/path/to/cron.php > /path/to/log.txt 2>&1
2>&1 indicates that the standard error (2>) is redirected to the same file descriptor that is pointed by standard output (&1).So, both standard output and error will be redirected to /path/to/log.txt
UPDATE:
Below is a function/flow that I usually use in my crons:
function addLog($msg)
{
if(empty($msg)) return;
$handle = fopen('log.txt', 'a');
$msg = $msg."\r\n";
fwrite($handle,$msg);
fclose($handle);
}
Then I use it like so:
addLog("Initializing...");
init();
addLog("Finished initializing...");
addLog("Calling blah-blah API...");
$result = callBlahBlah();
addLog("blah-blah API returned value". $result);
It is more tedious to have all these logs, but when cron messes up, it really helps!
For eg. when you look at your log.txt and if you see something like:
Initializing...
Finished initializing...
Calling blah-blah API...
And there is no entry which says blah-blah API returned value, then you know that the function call to blah-blah messed up.
What are common causes for a cron ending when it shouldn't?
The most common in my experience is that the cron user has different permissions or different environment variables than the way that you're executing it from the command line.
Make your cronned program dump its environment to a temporary file and see if it's what you expect.
Hello i need some help with this code in the install.php which has to run first before the program but it brings an error pointing on the fflush i don't know what to do please help?
<?php
fflush();
authTableCreate();
announceTableCreate();
classTableCreate();
studentTableCreate();
classmembersTableCreate();
attendanceTableCreate();
assignmentTableCreate();
messageTableCreate();
supportTableCreate();
if (!authCheckUserExists('admin')) { // this is their first install probably
$randpass = 'admin' . mt_rand();
authAddUser('admin', $randpass, 100, 100); // create default superuser account
announceAddAnnouncement('Welcome', 'This is the default start page for IntraSchool. You should change this to something that describes how the system works within your school.');
?>
<p>Congratulations! You have successfully setup <em>IntraSchool</em>. You may now login with the username <em>admin</em> and password <em><?=$randpass?></em>. Please change the password to something you can remember.</p>
<?php
} else {
?>
<p>The installation script has reinitialized any deleted tables.</p>
<?php
}
page_footer();
?>
fflush() requires the handle of the file to be flushed. It is likely a typo for flush(), however as it's apparently at the start of the file that would do nothing at all. You should just delete the line.
It's only a warning though, so the rest of the script has probably been executed. If it's a once-only setup script then you probably do not need to run it again.
Here's the documentation - always a good place to start.
My understanding of your code is limited, so I'm not sure what you're trying to accomplish here (in particular, it looks like you're doing database operations, for which fflush should not be necessary). That said, here's a little background:
fflush flushes an open file to disk. You need to provide it with a file handle to flush.
When you're writing to a file on your disk, the operating system will often store up a bunch of your data and write it all to the disk at one time, rather than writing each byte as you send it. This is primarily for performance reasons. Sometimes, however, you need to get that data written at a particular point in your program. That's what fflush is for. But for fflush to work, you need to tell it what file you're talking about - that's the file handle mentioned in the documentation.
From inside my index.php file, say, I'd like to check if another PHP file executes without error (and include it, if so), and if it does in fact fail and returns a fatal error, I'd obviously like to not include it. Any suggestions? Thanks...
You may use -l parameter of php CLI:
php -l filename.php
and parse the output.
$o = `php -l filename.php`;
if (strpos($o, 'No syntax errors detected') !== false) {
echo 'No errors';
} else {
echo 'There are errors';
}
You probably don't want to run the second file separately. That said, you can do one of two things...
1.) if you really want to use it as an include that executes separately you could call it with something such as CURL and have it output either the expected result or a failure message that would then be read and acted on accordingly.
2.) Include your function/class/etc execution in a try/catch statement to properly handle any errors encountered. http://php.net/manual/en/language.exceptions.php might help you a little more with this method.
This runs the script as a separate process, with no shared variables/functions/state/scope etc...
$cmd = 'php file.php';
exec($cmd, $ar, $exit_status);
$wasFatal = $exit_status == 255;
There's a real good chance it gets run with a php.ini that's different than whatever your webserver php.ini is, so expect differences in config and maybe even php version.
I have a PHP script that creates other PHP files based on user input. Basically, there are files containing language specific constants (define) that can be translated by the user. In order to avoid runtime errors, I want to test newly written files for parse errors (due to "unusual" character sequences). I have read several posts here on SO (like PHP include files with parse errors) and tried a function that uses
$output = exec("php -l $filename");
to determine whether a file parses correctly. This works perfectly on my local machine, but at on the provider's machine, the output of calls to exec("php ...") seems to be always empty. I tried a call to ls and it gives me output, leading me to the assumption that PHP is somehow configured to not react to command line invocations or so. Does anyone know a way around this?
EDIT: I forgot to mention, I had already tried shell_exec and it gives no result, either. In response to sganesh's answer: I had tried that too, sorry I forgot to mention. However, the output (second argument) will always be an empty array, and the return value will always be 127, no matter if the PHP file to test has syntax errors or not.
I had the same problem. The solution that worked for me was found in running-at-from-php-gives-no-output. I needed to add output redirection.
$output = exec("php -l $filename 2>&1");
You can try with exec second and third arguments.
second argument will have the output of the command.
third argument will have the return value.
And exec will return only last line of the command.
$filename = "a.php";
$output = exec("php -l $filename",$op,$ret_val);
print $output."\n";
print $ret_val."\n";
var_dump($op);
By executing shell_exec(), you can see the output as if you executed that file via command line. You can just see if there is an error right here.
<?php
if (strpos(shell_exec('php -l file.php'), 'Syntax Error')) {
die('An error!');
}
There may also be a possibility that shell_exec() or exec() may be disable by your host.
Nice idea to check the file validity :-)!
Now, from the PHP manual for exec():
Note: When safe mode is enabled, you can only execute files within the safe_mode_exec_dir. For practical reasons, it is currently not allowed to have components in the path to the executable.
Can you check if this is not the case for you?
Also, can you check by providing the full path of the PHP interpreter in the exec() instead of only php. Let me know how you fare.
Pinaki
the correct way is to add >2&1 as tested on a windows system using imagemagick!
I worked around my original problem by using a different method. Here is what I do now:
Write a temporary file with contents <?php include "< File to test >"; echo "OK"; ?>
Generate the correct URL for the temporary file
Perform HTTP request with this URL
Check if result equals "OK". If yes, the file to test parses without errors.
Delete temporary file
Maybe this could be done without the temporary file by issuing an HTTP request to the file to test directly. However, if there is a parse error and errors are suppressed, the output will be empty and not discernible from the output in the case of a file that gives no parse errors. This method is risky because the file is actually executed instead of just checked. In my case, there is only a limited number of users who have access to this functionality in the first place. Still, I'm naturally not entirely happy with it.
Why the exec() approach did not work, I still do not know exactly. pinaki might be right by suggesting to provide the full path to the PHP executable, but I cannot find out the full path.
Thank you everyone for answering, I upvoted you all. However, I cannot accept any of your answers as none of your suggestions really solved my problem.