I've tried this code in External Tools with actual document as input. But it doesn't work.
#!/bin/sh
/usr/bin/php -r
Syntax check works as expected
#!/bin/sh
/usr/bin/php -l
Outputs either error message or "No syntax errors detected"
For the external tools, set the "Input" to "Current document" and the command is just php (no options):
php
The output in the bottom pane will be the output of your script. Just keep in mind that this is only going to work for local files.
Edit: screenshots...
You can also one of the many Gedit keywords.
$$GEDIT_CURRENT_DOCUMENT_PATH
$GEDIT_CURRENT_DOCUMENT_URI
Related
Ok, so I have a problem with this thing I found on a MacBook Air. It's called terminal and you can do crazy stuff on it. So anyways, when I enter the command "php" it gives me a multiline console but it doesn' do anything when I run a line of php! For instance, I type echo "Hello World" but it just returns it like a typewriter and nothing happens! Can someone please tell me what is going on, and is there a way to exit this?
Firstly check if you have php properly installed:
type in console:
php -v
you should see version of installed php for ex.:
PHP 7.3.3 ...
to run single line of code from console you do it this way:
php -r 'echo "\nHello World\n";'
where \n is new line character.
to enter interactive mode and run multiple lines of code:
php -a
and once you see:
Interactive mode enabled
php >
type:
echo "\nHello World\n";
and hit [Enter] key.
that's it.
to leave interactive mode type:
exit
note lack of ; at the end.
If you want to run from console a php code that you have in a file:
php -f <path-to-the-file>
but this is a default behavior of php so if you miss flag -f and just type:
php
it will do nothing, expecting you providing it a path to file after the php like in the example with flag -f:
php <path-to-file>
So if a programmer intention is to enter an interactive mode but he types only php without any flags, the php will not warn about missing path to the file so programmer may have the impression he's into php interactive mode as he wanted but this is not true.
to see all possible options in php cli, type:
php --help
I believe if you just type php into the terminal it will start a php server process on the local mac. If you want to run a script you have to cd in to to the working directory and type php filename.php.
If you want to use PHP code directly you must enter php -a without a flag you will just enter in php environment.
When running the php command directly from your command line, it behaves as it is reading a .php from the command line
You noticed that it just echo's back any thing you write toward it, this is the same as it is executing a .php file, its echoíng any html back to the browser
Example:
$ php
sss
<?PHP
echo 'Hello!';
?>
More data!
ctrl + d (to signal that the end of the filehas reached)
Output:
sss
Hello!More data!
In Python, we can add the command line log to a file instead of the console using this command:
python script.py >> mylogfile.txt
How can I do it using PHP? I've tried
php script.php >> mylogfile.txt
but it doesn't work.
I use Windows 10.
I finally found the answer. It's based on the article PHP on the Command Line – Part 1 Article
I first used php script.php > mylog.txt which returns some of the log text to the console, so I thought it's not writing to the log, but it does. I wanted php script.php > mylog.txt 2>&1 which will add any log to the file.
The article says it doesn't work in Windows, but I use Windows 10 and it works.
The error messages are mixed with the normal output as before. But by
piping the output from the script, I can split the errors from the
normal output:
php outwitherrors.php 2> errors.log
This time, you’ll only see these messages:
Opening file foobar.log Job finished
But, if you look into the directory in which you ran the script, a new file called errors.log will have been created, containing the error
message. The number 2 is the command line handle used to identify
standard error. Note that 1 is handle for standard output, while 0 is the handle for standard error. Using the > symbol from the command line, you can direct output to a particular location.
Although this may not seem very exciting, it’s a very handy tool for
system administration. A simple application, running some script from
cron, would be the following:
php outwitherrors.php >> transaction.log 2>> errors.log
Using ‘>>‘, I tell the terminal to append new messages to the existing
log (rather than overwrite it). The normal operational messages are
now logged to file transaction.log, which I might peruse once a month, just to check that everything’s OK. Meanwhile, any errors that need a quicker response end up in file errors.log, which some other cron job might email me on a daily basis (or more frequently) as required.
There’s one difference between the Unix and Windows command lines,
when it comes to piping output, of which you should be aware. On Unix,
you can merge the standard output and standard error streams to a single destination,
for example:
php outwitherrors.php > everything.log 2>&1
It reroutes standard error to standard output, meaning that both get
written to log file everything.log.
I am migrating a set of php scripts from Window 2003 / PHP 5.2 to Windows 2012 R2 / PHP 5.6.7
In the scripts exec commands are used, for example to copy files. Commands could look like this:
exec ('copy "C:\ftp\suppliername\upload\*.*" c:\somefolder\ >> output.log');
You could argue that there are better ways to copy files, but I rather wouldn't like to rebuild these scripts right now.
The problem I have is that when there are no files to copy, the error "The system cannot find the file specified." is now shown, while this wan't the case on the old server.
If you just execute the copy command on the command line, the output looks like this:
The system cannot find the file specified.
0 file(s) copied.
This is the same as what gets written to output.log
So apparently the "0 file(s) copied" is getting suppressed somewhere, but not the error.
So my question is, how do I get rid of the error on the commandline? I thought it would be some configuration in php.ini, but after comparing the php.ini from the old and the new server, I couldn't find any essential differences.
I've tried a few things to suppress the error, but with no success:
Adding a # to the exec command
Adding ob_start() and ob_end_clean() before and after the command
Edit: please do not flag as a duplicate. I did see that question before asking my question. the answers given there do not solve my issue. The main question is, why was it working before, you would think that it should still be possible to get it working the same way without modifications to the scripts.
Try adding "2>&1" to your command.
exec ('copy "C:\ftp\suppliername\upload\*.*" c:\somefolder\ >> output.log 2>&1');
This should redirect the error output to output.log
I suppose that this string is being printed to stderr.
You could try to replace your STDERR as described in the post https://stackoverflow.com/a/3823015/146003.
The essential part of the post consists of the lines:
fclose(STDERR);
(...)
$STDERR = fopen('error.log', 'wb');
You can then get rid of error.log. Although I didn't try, you could try to open NIL (see https://stackoverflow.com/a/313115/146003)
First of all, you are redirecting the output of the copy command to a text file, so it will not be ouput to console.
Do this way instead:
exec ('copy "C:\ftp\suppliername\upload\*.*" c:\somefolder\', $output);
var_dump ($output);
I have a question regarding running a shell command via PHP. My goal is to successfully run compass compile [project] via PHP. I have tried the following:
echo system('compass compile [project]', $s); // prints [31m[0m
echo $s; // prints 1
echo passthru('compass compile [project]', $p); // prints [31m[0m
echo $p; // prints 1
echo shell_exec('compass compile [project]'); // prints [31m[0m
echo exec('compass compile [project]', $e, $ee);
print_r($e); // Array ( [0] => [31m[0m )
echo $ee; // prints 1
I even tried running a shell command to an executable file that contained compass compile test and I still got the same results as the trials above.
My questions
What does [31m[0m mean? Does this represent binary data? Do these represent bash colors as search engines suggest?
As far as I know, the output should be the following:
For kicks, I tried to execute via system(/usr/local/bin/compass compile [project]); and I got the same result. I double checked my path so I know I can execute these commands as expected. Here is the output from echo $PATH:
/usr/lib/lightdm/lightdm:
/usr/local/sbin:
/usr/local/bin:
/usr/sbin:
/usr/bin:
/sbin:/bin:
/usr/games:
/usr/local/games:
/var/lib/gems/1.9.1/bin
Is there a way to compile compass projects using PHP?
I've seen a similar error before.
Typically it is due to the things being output in the bash startup scripts. For example, I had an echo in one of my bash startups that jacked up a lot of scripts till I realized what was causing the problem.
Or, perhaps the user (www-data ?) doesn't actually have a home dir and appropriate startup scripts in place?
You can try this to get a non interactive shell:
exec("/bin/bash -c \"compass compile [project]\"", $e, $ee);
print_r($e);
echo $ee;
If you still have issues, try redirecting the output to a tmp file, an checking it:
exec("/bin/bash -c \"compass compile [project] > /tmp/compass.compile.output\"", $e, $ee);
print_r($e);
echo $ee;
See also: What's the difference between .bashrc, .bash_profile, and .environment?
The issue was fixed by using sass --compass and redirecting the stderr to stdout via echo shell_exec("sass --compass [project] 2>&1");
It was a pretty long and arduous process figuring this out since it's been awhile since I've dabbled in command line programs. Remember that error streams and output streams might be on different outputs. The easiest way to test this is to shovel the output into a file via:
# do this once with a good file and once with a file that will give errors
sass --poll style.scss > output.txt
If output.txt is empty then the error output is on the stderr stream such as the case above. We can correct this by redirecting the stderr to the srdout. For example:
sass --poll > output.txt 2>&1
#shows results
cat output.txt
I created a simple PHP script that redirects the output from one textarea to the other. The code can be found here.
First guess would be a permissions issue. Odds are the user account running PHP (unless you're running this from the command line, I'm guessing that this is the user that the httpd apache daemon is running under) doesn't have the permissions to do what you're asking. The errors are extremely unhelpful, however.
From what I can tell, it looks like an attempt to have the error show up in red on the command line. My guess is that there are hidden (or somehow never printed out) characters in-between the codes. Check out some of your apache and/or PHP error logs to see if anything helpful is showing up there that never made it into the PHP variable. Or, for kicks, try copy and pasting the output with the bash colors into a basic text editor and first delete each character from the beginning one by one... see if anything magically appears. If that doesn't work, try the same in reverse, backspacing from the end. Either way, there's an error occurring, so important that it must show in bold red letters to you, it's just not getting to you.
If it does in fact turn out to be a permissions issue, and it's one you can't remedy through permissions wrangling, you could create an intermediary file that your Apache user has permissions to write to, and your cron user has permissions to read from. Instead of running the code directly from PHP, put it in the file, then run a cron on a frequent basis looking for anything in that file, CHECKING IT FOR VALIDITY, and then running it through the compiler and removing it from the file.
It'd be ugly, but sometimes pretty things don't work.
You guessed it right it is colors but the way it is defined is not right. For more information regarding using colors in console please refer to this document. Also, for compiling SCSS via compass you can use shell_exec command in linux. For more information regarding shell_exec please refer to this document. Let us know how it goes.
I'm currently using the Pygments for PHP plugin that is located here: http://derek.simkowiak.net/pygments-for-php/.
The line that actually calls Pygments from that code is an exec() passed: pygmentize -f html $extra_opts -l $language $temp_name as the command. This all works fine, and I get back the output and it is formatted by the plugin.
What I would like to happen at the same time is for Pygments to create an image of it, so I pass exec() a similar command: pygmentize -f png $extra_opts -l $language -o $full_image_path/$output_file.png $temp_name This is where I run into a problem. The image never shows up in the expected folder.
However, if I var_dump() that command string before I exec() it and take it and run it straight from the command line, it works fine.
I have tried echoing exec('whoami') which tells me that the PHP user is www-data. I've tried giving permissions to www-data and changing ownership to www-data on the folder where I store the images. I've also tried changing permissions to 777 just to see what would happen, and the answer is nothing.
Is there something I'm missing? I'm running out of ideas to try. Thank you!
Edit: Another thing that I've checked is the output from the exec command, and the return value. It outputs an empty array, and it returns 1 as the return value.
Edit 2: After seeing that that directory should be writeable/readable for the PHP user, is it possible that pygments doesn't have permission to write it as a specific user? I'm not sure this makes sense, as when I run it myself it works fine, and in fact, when PHP runs it with the HTML lexer, it is able to run. I'm not very experienced in Python, so I don't know if this is a potential issue.
I guess you cannot do it like this.
$output_file.png
Try
$file = $output_file.".png"
and substitute in the exec
Ended up being an issue with the font that was installed for use by the www-root user. Apparently the one that is used by default for Pygments was installed only for the user that I was running as when I use the command line.
The way I was able to figure this out, was running
exec("$command 2>&1", $out, $code);.
The extra 2>&1 redirects stderr into the output for me to see the issue.
The $out parameter showed the FontNotFound error that pygments was throwing.
I changed the font that Pygments used via the command line using: full,style=manni,cssclass=pygmentize_kbOKBd,font_name='DejaVu Sans Mono' -l php -o /srv/www/path/to/images/uploads/2513732976ad4b7.02729290.png /tmp/pygmentize_kbOKBd after finding which fonts I had available to me.
To see which fonts I had available to me as the user running the script, I just ran fc-list in an exec() command for Ubuntu, and checked the output of that for the list of available fonts.