This has been bugging me slightly.
I know you can do
php foo.php
or
php -f foo.php
Is there no way to just launch a script with the execute bit set
./foo.php
Given the folowing:
#!/usr/bin/php
<?php
exit('hello');
I get "Could not open input file" or " bad interpreter: No such file or directory" depending on if there's whitespace after "bin/php".
Instead of #!/usr/bin/php, using #!/usr/bin/env php is a better solution. This will look up the PHP binary in the PATH environment variable. This is much more robust & crossplatform. BSD for example installs PHP in /usr/local/bin/php.
Further, you will need to make sure this is the first line, and that the script has the executable bit set, to set it for everyone (Generally OK) use: chmod a+x script.php
Also make sure you have the CLI SAPI enabled. Run php -v top verify, it should show something like:
[~]% php -v
PHP 5.3.3 (cli) (built: Jul 22 2010 16:21:30)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
Check if you have nothing before '#!', like an UTF-8 BOM
Check if you don't have anything at the end of the line, like CR (\r) befor the final LF (\n). The CR goes there if you write the file in Windows with windows line endings (CR LF) and may be interpreted as a part of the interpreter path.
The example code you've given seems OK and works for me (I added the the closing ?> though)
If you can run the file with /usr/bin/php foo.php there's something weird going on. Just a wild guess, but maybe you text editor leaves a BOM (byte order mark) at the beginning of the file, so that the #! aren't the very first two bytes in that file. (you can find out by doing hexdump -C foo.php | head)
From the php(1) manpage:
TIPS
You can use a shebang line to automatically invoke php from
scripts. Only the CLI version of PHP will ignore such a first line as
shown below:
#!/bin/php
<?php
// your script
?>
So, the shebang method does work. I'm getting ": No such file or directory" if I set line endings to something other than "unix" in Vim. Are you using DOS line endings in your script?
Related
I'm running this command to run Drush which is basically a PHP CLI for Drupal, in the running container:
docker-compose -f ../docker-compose.test.yml exec php scripts/bin/vendor/drush.phar -r public_html status-report
The output if this command is fine, it's the list of status information about a specific Drupal instance in the container. I won't be pasting it here as it's long, and irrelevant.
Now let's filter this information by piping it into grep:
docker-compose -f ../docker-compose.test.yml exec php scripts/bin/vendor/drush.phar -r public_html status-report | grep -e Warning -e Error
The result is:
Cro Error L
Gra Warning P
HTT Error F
HTT Warning T
Dru Warning N
XML Error L
Which is wrong, it looks like it has been cut to pieces, and most of it is missing.
Now, if we will disable allocating of pseudo-tty by adding -T flag:
docker-compose -f ../docker-compose.test.yml exec -T php scripts/bin/vendor/drush.phar -r public_html status-report | grep -e Warning -e Error
The output is correct:
Cron maintenance Error Last run 3 weeks 1 day ago
Gravatar Warning Potential issues
HTTP request status Error Fails
HTTPRL - Non Warning This server does not handle hanging
Drupal core update Warning No update data available
XML sitemap Error Last attempted generation on Tue, 04/18/2017
Why is that?
Bonus question, which probably will be answered by the answer to the previous one: Are there any important side effects of using -T?
Docker version 18.06.1-ce, build e68fc7a215
docker-compose version 1.22.0
UPDATE #1:
To simplify things I saved the correct output of the whole scripts/bin/vendor/drush.phar -r public_html status-report into a file test.txt and tried:
docker-compose -f ../docker-compose.test.yml exec php cat test.txt | grep -e Warning -e Error
Interestingly the output is correct now with and witout -T, so it has to have something to do with Drush/php, although I'm still interested what can be a cause of this.
PHP 7.1.12 (cli) (built: Dec 1 2017 04:07:00) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.1.12, Copyright (c) 1999-2017, by Zend Technologies
with Xdebug v2.5.5, Copyright (c) 2002-2017, by Derick Rethans
Drush 8.1.17
UPDATE #2:
To isolate problem further I put all content in a PHP file, that is simply printing it, and after:
docker-compose -f ../docker-compose.test.yml exec php php php.php | grep -e Warning -e Error
I'm getting a correct output!
So it has to have something to do with how Drush is printing its messages, but I fail to see what it can be. That could be pretty interesting if we could figure this out.
UPDATE #3:
Ok guys, that's actual magic. The problem happens also with running drush without any commands, to list all available ones. The list of commands is broken when output is being piped, so this can be tested without actual Drupal instance.
Now I want to present you magic.
In drush, output for list of available commands in being generated in commands/core/help.drush.phpin function drush_core_help(). There is this call: drush_help_listing_print($command_categories); I looked into it. Inside is a call drush_print_table($rows, FALSE, array('name' => 20)); that is responsible for generating part of the output that's getting broken.
So inside of it, I decided to intercept the output, just before the last call to drush_print(), by adding simple file_put_contents('/var/www/html/data.txt', $output);
And now it's time for the absolutely magical part for me.
When I execute:
docker-compose -f ../docker-compose.test.yml exec php scripts/bin/vendor/drush/drush -r public_html
The last group of commands can be checked in this file, and in my case it's:
adminrole-update Update the administrator role permissions.
elysia-cron Run all cron tasks in all active modules for specified site using elysia cron system. This replaces the standard "core-cron" drush handler.
generate-redirects Create redirects.
libraries-download Download library files of registered libraries.
(ldl, lib-download)
libraries-list (lls, Show a list of registered libraries.
lib-list)
BUT, if I execute the same command, but the output will be piped or redirected, so for example:
docker-compose -f ../docker-compose.test.yml exec php scripts/bin/vendor/drush/drush -r public_html | cat
SOMETHING DIFFERENT WILL BE SAVED INTO A FILE:
adminrole-update U
p
d
a
t
e
t
h
e
a
d
m
i
n
i
s
t
r
a
t
o
r
r
(and the rest of the broken output)
So the fact of piping/redirecting of the output, influences execution of the command, before the pipe/redirection actually happens.
How is that even possible? O_o
It's not uncommon for a command-line program to change its output presentation based on whether its output is a terminal, or not. For example, ls by itself, with no options, displays files in a columnar format. When piped, the output changes to a list of one-file-per-line. You can see this in the source code for GNU ls:
case LS_LS:
/* This is for the 'ls' program. */
if (isatty (STDOUT_FILENO))
{
format = many_per_line;
set_quoting_style (NULL, shell_escape_quoting_style);
/* See description of qmark_funny_chars, above. */
qmark_funny_chars = true;
}
else
{
format = one_per_line;
qmark_funny_chars = false;
}
break;
You can emulate the behavior of ls | ... with the explicit argument ls -1, and this too is not uncommon: programs that implicitly change their output presentation often provide a way to explicitly engage that alternate presentation.
Support for this isn't just a convention: it's actually a requirement for ls in POSIX:
The default format shall be to list one entry per line to standard output; the exceptions are to terminals or when one of the -C, -m, or -x options is specified. If the output is to a terminal, the format is implementation-defined.
This all may seem magical: how does ls know it's got a pipe following it since it comes before the pipe? The answer is quite simple, really: the shell parses the whole command line, sets up the pipes, and then forks the respective programs with the input/output wired to pipes appropriately.
So, what part of the command is doing the alternate presentation? I suspect it's an interaction between the environment of your exec and the column width calculation in drush. On my local environment, drush help | ... doesn't produce any unusual results. You might try piping to (or through) cat -vet to discover any unusual characters in the output.
That said, regarding docker-compose specifically: based on this thread, you're not the only one who has encountered this or a similar issue. I've not trawled the docker source code, but - generally - not allocating a pseudo-tty will make the other end act like a non-interactive shell, which means things like your .bash_profile won't run and you won't be able to read stdin in the run command. This can give the appearance of things not working.
The thread linked above mentions a work around of this form:
docker exec -i $(docker-compose ...) < input-file
which seems reasonable given the meaning of -i, but it also seems rather convoluted for basic scripting.
The fact that -T makes it work for you suggests to me that you have something in your .bash_profile (or similar login-shell-specific start up file) that's changing certain values (maybe COLUMNS) or altering the values in such a way as to have the observed deleterious effect. You might try removing everything from those files, then adding them back to see if any particular one causes the issue.
I didn't read that very detailed question, but from glancing over it, I'd say the -T option to the exec subcommand is essential if you want to process stdout and stderr in the environment where you execute docker-compose.
I am using Boris—"A tiny little, but robust REPL for PHP". To be more specific, I am using WP-CLI's implementation of Boris (wp shell—it replaces the $boris command prompt with wp>).
I was wondering if it was possible to pipe the command line output to say, a text file. For example, I want to capture my PHP info to a text file. Here is what happens when I execute phpinfo();
wp> phpinfo();
phpinfo()
PHP Version => 5.3.14
System => Darwin Macintosh-HD.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64
Build Date => Jul 4 2012 17:23:04
Configure Command => './configure' '--with-mysql=/...
//phpinfo() output continues here
I want to redirect this output from the standard display to a text file. I know this is bash syntax, but this is what I want to achieve in theory :
wp> phpinfo(); > phpinfo.txt
// phpinfo.txt now contains phpinfo() output
Is there any way to make this work?
You should be able to use the bash syntax on the command that opens the shell, try it there.
EX:
wp_shell > output.txt
Where "wp_shell" is the command that opens your prompt. You might be able to pass phpinfo directly to the prompt as well if you want to not have to open it, if there is a way to pass direct script to it as with the default php CLI.
I often find PHP's interactive mode—php -a—very useful, but it would be far more useful if I could start it and have a few commands executed right away to initialize my environment. Things like run the autoloader, set up a few use shortcuts for namespaces, etc.
Here's an example:
include "../../autoloader.php";
use App/Foo/Bar as Bar;
I thought maybe I could just add these lines to a text file initialize.txt and then start the interactive mode with php -a < initialize.txt, but that didn't work.
How can I do this?
As Tomas Creemers mentioned, you have to use auto_prepend_file PHP flag to auto-require a file. For example:
<?php
# foo.php
function bar() { print "Bar.\n"; }
You can load the PHP interpreter like this:
php -d auto_prepend_file=$PWD/foo.php -a
Session:
Interactive shell
php > bar();
Bar.
Or you can include file manually:
php -a
Session:
Interactive shell
php > include 'foo.php';
php > bar();
Bar.
You can use the php.ini setting auto_prepend_file to specify a file that should always be executed before the actual file.
According to the documentation on interactive shell, this setting is also active there.
Assuming you don't want to do this initialization for every single time you start PHP, I would suggest creating a copy of your php.ini file (call it 'php.ini-interactive', for example) and specify that configuration file with the -c option: php -c /path/to/php.ini-interactive -a.
According to a comment (by "Ryan P") on the documentation page for PHP interactive shell, php -a does not always do the same thing:
Interactive Shell and Interactive Mode are not the same thing, despite
the similar names and functionality.
If you type 'php -a' and get a response of 'Interactive Shell'
followed by a 'php>' prompt, you have interactive shell available (PHP
was compiled with readline support). If instead you get a response of
'Interactive mode enabled', you DO NOT have interactive shell
available and this article does not apply to you.
You can also check 'php -m' and see if readline is listed in the
output - if not, you don't have interactive shell.
Interactive mode is essentially like running php with stdin as the
file input. You just type code, and when you're done (Ctrl-D), php
executes whatever you typed as if it were a normal PHP (PHTML) file -
hence you start in interactive mode with '<?php' in order to execute
code.
I do not have a copy of PHP with interactive shell available. I only have interactive mode, apparently. I have tested (see below) and can confirm that files configured with auto_prepend_file are executed in interactive mode. However, you may want to reconsider using it if you get the same symptoms as me:
cat /tmp/prepend.php
Output:
<?php
echo 'cookies are people too!';
Further:
grep auto_prepend_file /etc/php5/cli/php.ini
Output:
auto_prepend_file =
grep auto_prepend_file /etc/php5/cli/php.ini-interactive
Output:
auto_prepend_file = /tmp/prepend.php
php -a
Session:
Interactive mode enabled
php -c /etc/php5/cli/php.ini-interactive -a
Output:
Interactive mode enabled
cookies are people too!
Segmentation fault
php --version
Output:
PHP 5.4.4-14+deb7u2 (cli) (built: Jun 5 2013 07:56:44)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
(Keyboard input in that last interactive mode run is only a return followed by Ctrl + D.)
Solved by restoring Windows to previous state
The message (The system cannot find the path specified.) shows...
1) When i open new CMD (Win+R => cmd). It starts with introduction. (on line 3)
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
The system cannot find the path specified.
C:\Users\ViliamKopecky>
2) When i execute some command like cmd /C dir (or cmd /C php -v or whatever) (on line 2)
C:\Users\ViliamKopecky>cmd /C dir
The system cannot find the path specified.
Volume in drive C is Windows7_OS
Volume Serial Number is 8230-1246
...
C:\Windows\System32>cmd /C php -v
The system cannot find the path specified.
PHP 5.4.8 (cli) (built: Oct 16 2012 22:30:23)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
3) (the most annoying) when i run exec function from PHP or Node.js or probably any scripting lang. (which are probably runned from inside as cmd /C <command>)
The message does not show...
1) when i execute the command right from the cmd (or mingw, ...)
C:\Users\ViliamKopecky>dir
Volume in drive C is Windows7_OS
Volume Serial Number is 8230-1246
Directory of C:\Users\ViliamKopecky
Let's start with simple command from cmd.
php -r "exec('dir', $stdout, $stderr); print(implode(\"\n\", $stdout), $stderr);"
and the result is like this (the directory test is empty - that is correct):
E:\test>php -r "exec('dir', $stdout, $stderr); print(implode(\"\n\", $stdout), $stderr);"
The system cannot find the path specified.
Volume in drive E is www
Volume Serial Number is 0C99-95EC
Directory of E:\test
09.11.2012 22:42 <DIR> .
09.11.2012 22:42 <DIR> ..
0 File(s) 0 bytes
2 Dir(s) 13 495 296 000 bytes free
int(1)
Which shows that the command dir has is executed from php correctly. Only thing thats wrong is the second line - The system cannot find the path specified. - that should not be there.
This message is output by exec from PHP (and also from Node.js as require('child_process').exec("dir", function(err, stdout, stderr) {console.log(stderr)});)
When I execute command right from cmd (or mingw, etc.) it executes correctly without the message. Environment variable PATH seem ok. Problem is just executing from script environment through exec functions.
How to get rid of that annoying message? Thanks
The problem is that some program has been set to autorun when you run cmd.exe.
In my case it was ANSICON that was installed... and then I moved the file without properly uninstalling.
I found a solution in this blog post:
http://carol-nichols.com/2011/03/17/the-system-cannot-find-the-path-specified/
The short version is to find
HKCU\Software\Microsoft\Command Processor\AutoRun
and clear the value.
This message can mean a path in the PATH enviromental variable doesn't exist.
The following PowerShell command will print missing paths.
($env:path).Trim(";").Split(";") | ? {-not (test-path $_)}
e.g.
> ($env:path).Trim(";").Split(";") | ? {-not (test-path $_)}
C:\Program Files\CMake\bin
C:\Program Files\SDCC\bin
C:\Users\wjbr\AppData\Local\Programs\Microsoft VS Code\bin
References
http://carol-nichols.com/2011/03/17/the-system-cannot-find-the-path-specified/
https://javarevisited.blogspot.com/2017/01/the-system-cannot-find-path-specified-error-in-command-prompt.html
This actually looks like a startup error with PHP, not with your code. Does
php -r "echo 1;"
also throw the same error? If so, your php.ini file or an include may be pathed incorrectly.
php -i
should give you more info.
I think you should try this out ! I had the same issue and solved it like this :
ok type : cd\windows\system32
After that you will see this: System32/:
Type what you want (ex:ipconfig):
System32: ipconfig
Then that should do it !
:)
I'm trying to run bash script in PHP but can't run it.
php -v
PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch (cli) (built: Jun 13 2012 17:19:58)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
Ubuntu 12.04 LTS 64 bit.
My php code:
$cmd='/www/var/pl/bash.sh';
$retval =-1;
exec( $cmd, $output ); //executing the exec function.
foreach( $output as $tmp )
{
echo "$tmp <br>";
};
bash.sh:
#!/bin/bash
swipl --quiet -s /var/www/pl/ples.pl -g "f(R, gel), writeln(R),open('/var/www/pl/in.txt',write, Stream),
write(Stream, (R)),
nl(Stream),
close(Stream)" -t halt.
What am I doing wrong?
And I can run bash.sh in the Linux terminal.
When you run the script in the terminal you are executing it under the account you are logged in to. You have a shell setup with a search path etc.
When php executes the script, it has not a shell setup, and runs under the webserver user account. When executing:
make sure you have complete paths to your file, swipl is not enough, it should be /path/to/swipl
make sure the webserver process has enough access rights to get everything it needs.
Most likely it is either a path or permission problem; for example the user the web application runs as, has no idea where the swipl program is.
Add 2>&1 to the command line before exec'ing it, so that it tells you what the problem is. Or you can find the stderr output into the web server error log (or PHP error log; check its path and settings in php.ini).