I have problem with following script:
$ exec('mode con /status', $tmp); print_r($tmp);
It runs the command and gives me result, but also I get every time error message too:
The system cannot find the path specified.
I just want get terminal window size $COLS x $ROWS
Used system: PHP 5.4 + Win7
Test results here:
C:\#home\Devel>C:\php\php.exe -v
PHP 5.4.13 (cli) (built: Mar 15 2013 02:05:59)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with Xdebug v2.2.2, Copyright (c) 2002-2013, by Derick Rethans
C:\#home\Devel>C:\php\php.exe -r "exec('mode con /status', $tmp); print_r($tmp);"
The system cannot find the path specified.
Array
(
[0] =>
[1] => Status for device CON:
[2] => ----------------------
[3] => Lines: 1200
[4] => Columns: 160
[5] => Keyboard rate: 31
[6] => Keyboard delay: 0
[7] => Code page: 775
[8] =>
)
How can I get rid of this error message!?!
Thanks.
Related
Suppose there are leading zeros in IPv4 address representation such as 012.012.012.012.
To suppress the leading zeros, I simply write the following code, and it works as I expected on my Mac:
% php -r 'var_dump(long2ip(ip2long("012.012.012.012")));'
Command line code:1:
string(11) "12.12.12.12"
% php --version
PHP 7.3.25 (cli) (built: Dec 25 2020 22:03:38) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.25, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.25, Copyright (c) 1999-2018, by Zend Technologies
with Xdebug v3.0.1, Copyright (c) 2002-2020, by Derick Rethans
But this simple piece of code doesn't work on CentOS 7, it seems like ip2long("012.012.012.012") returns false value:
$ php -r 'var_dump(long2ip(ip2long("012.012.012.012")));'
string(7) "0.0.0.0"
$ php --version
PHP 7.3.25 (cli) (built: Nov 24 2020 11:10:55) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.25, Copyright (c) 1998-2018 Zend Technologies
$ cat /etc/redhat-release
CentOS Linux release 7.8.2003 (Core)
Both PHP versions are identical and I would expect them to return exact same values. I also read the ip2long docs and tried to find if there is any special options/configurations for this behaviour, but no luck.
Could someone lead me in the right direction?
What makes them different? And what should I do?
OK, I found the culprit. Different implementation of inet_pton(3) between LLVM and GCC leads this behaviour, as Russ-san commented. There was a bug report about the exact same problem 6 years ago. It seems PHP v5.2.10 had started using inet_pton instead of inet_addr according to this patch, that's why older versions of PHP treat each chunks as octal.
test.c
#include <stdio.h>
#include <arpa/inet.h>
#define INADDR "012.012.012.012"
int main() {
struct in_addr inaddr;
if (inet_pton(AF_INET, INADDR, &inaddr) == 0) {
printf("Invalid: %s\n", INADDR);
}
else {
printf("Valid: %s\n", INADDR);
}
return 0;
}
Mac
% cc test.cc && ./a.out
Valid: 012.012.012.012
Linux
$ cc test.cc && ./a.out
Invalid: 012.012.012.012
I gave up using ip2long / long2ip built-in functions and now trying to use https://github.com/mlocati/ip-lib
>>> \IPLib\Address\IPv4::fromString("1.2.3.12")->toString(true);
=> "001.002.003.012"
>>> \IPLib\Address\IPv4::fromString("001.002.003.012")->toString();
=> "1.2.3.12"
No problems so far.
EDIT: As the comment below by Bacon Bits suggests, I needed to save as UTF8
I'm trying to execute any php script in Powershell on windows 10.
Looks like it's eating the "<" of the script and then treating the file as a normal file.
sample php script:
<?php
echo "why?";
?>
Result of running script:
C:\php\php .\test.php
? p h p
e c h o " w h y ? " ;
? >
Version information:
C:\php\php -v
PHP 7.3.5 (cli) (built: May 1 2019 13:16:56) ( NTS MSVC15 (Visual C++ 2017) x64 )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.5, Copyright (c) 1998-2018 Zend Technologies
I was running the cgi version earlier with nginx and it seemed to work fine in that context.
I run the artisan:
php artisan down --message "Going down for maintenance" --retry=60
[UPDATE] OR run it like #Remul suggested:
php artisan down --message="Going down for maintenance" --retry=60
then both gives me the error:
[Symfony\Component\Console\Exception\RuntimeException]
Too many arguments, expected arguments "command".
If run command with no spaces like this:
php artisan down --message "Going_down_for_maintenance" --retry=60
No error occurs
I am using php 7.0.14
I figured out:
Problem is actually how php is getting arguments from command line
In vendor/symfony/console/Input/ArgvInput.php I could understand that php gets argfuments like this:
0 => "artisan"
1 => "down"
2 => "--message=Going"
3 => "down"
4 => "for"
5 => "maintenance"
6 => "--retry=60"
So to even make sure I made a script of my own with this content:
<?php
var_dump($argv);
And I run it:
php -v;php test_argv.php "parm with space" other_parameter
The output was:
PHP 7.0.14 (cli) (built: Jan 30 2017 15:45:33) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
array(5) {
[0]=>
string(13) "test_argv.php"
[1]=>
string(4) "parm"
[2]=>
string(4) "with"
[3]=>
string(5) "space"
[4]=>
string(15) "other_parameter"
}
I run it in other machine with a different version of PHP and look at my results:
PHP 7.1.5 (cli) (built: Sep 19 2017 10:48:01) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
with Xdebug v2.5.4, Copyright (c) 2002-2017, by Derick Rethans
array(3) {
[0] =>
string(13) "test_argv.php"
[1] =>
string(15) "parm with space"
[2] =>
string(15) "other_parameter"
}
Looks like in php 7.0 and 7.1 argv parsing is quite different, one ignores the double quotes as string delimiter and the later don't
This is an unrelated problem, but this was the place where Google sent me as I made this mistake... soo..
The other common reason to get:
Too many arguments, expected arguments "command".
Is that you are providing an argument, when the artisan script is expecting an option. So you need to change
./artisan yourcommand:yoursubcommand some_kind_of_input
to
./artisan yourcommand:yoursubcommand --an_option=some_kind_of_input
The error just generally means that artisan was not expecting an additional argument of any kind to this command...
I had the same issue, just need to escape the message using backslashes:
php artisan down --message "Going\ down\ for\ maintenance" --retry=60
This message is available in a JSON formatted file named storage/framework/down generated by php artisan down command.
You can open that file and modify it.
Goodluck
This is stumping me... I'm using the exact example from:
http://php.net/manual/en/mongodate.todatetime.php
but I'm getting:
PHP Fatal error: Call to undefined method MongoDate::toDateTime()
<?php
$d = new MongoDate(strtotime("2014-11-18 11:01:25"));
var_dump($d);
var_dump( $d->toDateTime() );
?>
The exact output I get is:
object(MongoDate)#1 (2) {
["sec"]=>
int(1416330085)
["usec"]=>
int(0)
}
PHP Fatal error: Call to undefined method MongoDate::toDateTime() in /xxx/testmongodate.php on line 5
PHP version:
$ php -v
PHP 5.5.9-1ubuntu4.9 (cli) (built: Apr 17 2015 11:44:57)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies
PHP config:
$ php -i | grep mongo
/etc/php5/cli/conf.d/20-mongo.ini,
mongo
mongo.allow_empty_keys => 0 => 0
mongo.chunk_size => 262144 => 262144
mongo.cmd => $ => $
mongo.default_host => localhost => localhost
mongo.default_port => 27017 => 27017
mongo.is_master_interval => 15 => 15
mongo.long_as_object => 0 => 0
mongo.native_long => 0 => 0
mongo.ping_interval => 5 => 5
I have been successfully using this installation to insert into and read from an actual mongo database, but now I'm trying to work with MongoDate objects as they are read out of mongo, trying to format them for insert into another database... that is why I'm looking to use this method... but it doesn't seem to be found... ??
$ uname -a
Linux server1 3.13.0-52-generic #86-Ubuntu SMP Mon May 4 04:32:59 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
For anybody coming to this question late (as I did), the likely issue is that the PHP is using a different Mongo driver. There are currently 2 and the below code is for the legacy driver.
The solution with the legacy driver is to get the date from the Mongo Date using the PHP date function:
<?php
$d = new MongoDate(strtotime("2014-11-18 11:01:25"));
$newdate = date('Y-m-d H:m:s',$d->sec);
var_dump( $newdate );
?>
We use PDO connector on product environment and recently we facing a new issue. Somehow the mysql FOUND_ROWS() returns 0
I have also tried to run the SQL queries manually in mysql console but FOUND_ROWS() returns correct count in console.
What i found: PDO broken, mysqli works
Testing code:
<?php
$db = new PDO('mysql:host=dbhost;dbname=projectname;charset=utf8', 'projectname', '***');
print_r($db->query("SELECT SQL_CALC_FOUND_ROWS `id_sales_order` FROM `sales_order` WHERE RAND() > 0.8 LIMIT 0, 1")->fetchAll(PDO::FETCH_ASSOC));
print_r($db->query("SELECT FOUND_ROWS()")->fetchAll(PDO::FETCH_ASSOC));
$mysqli = new mysqli("dbhost", "projectname", "***", "projectname");
print_r($mysqli->query("SELECT SQL_CALC_FOUND_ROWS `id_sales_order` FROM `sales_order` WHERE RAND() > 0.8 LIMIT 0, 1")->fetch_assoc());
print_r($mysqli->query("SELECT FOUND_ROWS()")->fetch_assoc());
Results:
Array
(
[0] => Array
(
[id_sales_order] => 13
)
)
Array
(
[0] => Array
(
[FOUND_ROWS()] => 0
)
)
Array
(
[id_sales_order] => 7
)
Array
(
[FOUND_ROWS()] => 670336
)
Versions:
Mysql Server version: 5.6.21-70.0-log Percona Server (GPL), Release 70.0, Revision 688
PHP 5.4.33 (cli) (built: Sep 20 2014 16:20:03)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies
MysqlI Support => enabled
Client API library version => mysqlnd 5.0.10 - 20111026 - $Id: c85105d7c6f7d70d609bb4c000257868a40840ab $
PDO Driver for MySQL => enabled
Client API version => mysqlnd 5.0.10 - 20111026 - $Id: c85105d7c6f7d70d609bb4c000257868a40840ab $
I have had the same problem before however I fixed it by using fetch(PDO::FETCH_COLUMN).
print_r($conn->query("SELECT FOUND_ROWS()")->fetch(PDO::FETCH_COLUMN));