I've installed Syntastic plugin in vim. I can't get it to work. I've tried :SyntasticEnable but no luck. SyntasticEnable python in my vimrc doesn't work either (in fact, it doesn't even parse the command, an error is shown when I try to add it to my .vimrc : Not an editor command: SyntasticEnable python).
How can I know what's going on? Syntastic isn't showing errors when I call it from vim. Does the first error (not and editor command in my .vimrc) indicates something I'm unaware of?
I have in my .vimrc:
set statusline+=%#warningmsg#
set statusline+=%{SyntasticStatuslineFlag()}
set statusline+=%*
let g:syntastic_enable_signs=1
let g:syntastic_auto_loc_list=1
I have a python.vim in ~/.vim/syntax_checkers as well. I can already use Pyflakes for python files, it works GREAT but I would like to have Syntastic functionality in other files/extensions I need when developing applications.
Is pyflakes on your environment path? If it is not, then you must add it to your path, or modify syntax\checkers\python.vim and add the full path to the binary.
There are two lines you have to modify:
if !(executable("pyflakes"))
and also
let makeprg = 'pyflakes %'
In my case. I wanted Syntastic to work with PHP on my Windows machine. So I had to modify those two similar lines in php.vim to be:
let s:php_executable = "C:\\Uniserver\\usr\\local\\php\\php.exe"
if !(executable(s:php_executable))
and
let makeprg = php_executable . " -l %"
If your path contains spaces, you'll have to surround them in double quotes in the makeprg variable. Also with html.vim, the single quotes in makeprg must be replaced with double quotes, (you'll have to re-escape everything inside).
let s:libfolder = "C:\\Program Files (x86)\\GnuWin32\\bin\\"
let s:tidyexe = s:libfolder . "tidy.exe"
let s:grepexe = s:libfolder . "grep.exe"
if !executable(s:tidyexe) || !executable(s:grepexe)
and
let makeprg="\"".s:tidyexe."\" -e % 2>&1 \\| \"".s:grepexe."\" -v \"\<table\> lacks \\\"summary\\\" attribute\""
Have you tried to make sure Vim has the right value set for $PATH?
:echo $PATH
If not, try putting this in your .vimrc:
let $PATH=substitute(system("echo \$PATH"), "\r\*\n", "", "g")
Then shutdown and restart vim. If it works, you won't have to manually update the plugin's source files to manually include the path to the executables.
(found this via: https://superuser.com/questions/380535/getting-man-path-through-vim )
Related
I just cannot fathom how to get the PHP exec() or shell_exec() functions to treat a '*' character as a wildcard. Is there some way to properly encode / escape this character so it makes it through to the shell?
This is on windows (via CLI shell script if that matters, Terminal or a git-bash yields the same results).
Take the following scenario:
C:\temp\ contains a bunch of png images.
echo exec('ls C:\temp\*');
// output: ls: cannot access 'C:\temp\*': No such file or directory
Permissions is not the problem:
echo exec('ls C:\temp\exmaple.png');
// output: C:\temp\example.png
Therefore the * character is the problem and is being treated as a literal filename rather than a wildcard. The file named * does not exist, so from that point of view, it's not wrong...
It also does not matter if I use double quotes to encase the command:
echo exec("ls C:\temp\*");
// output: ls: cannot access 'C:\temp\*': No such file or directory
I have also tried other things like:
exec(escapeshellcmd('ls C:\temp\*'));
exec('ls C:\temp\\\*');
exec('ls "C:\temp\*"');
exec('ls "C:\temp\"*');
And nothing works...
I'm pretty confused that I cannot find any other posts discussing this but maybe I'm just missing it. At this point I have already worked around the issue by manually programming a glob loop and using the internal copy() function on each file individually, but it's really bugging me that I do not understand how to make the wildcard work via shell command.
EDIT:
Thanks to #0stone0 - The answer provided did not particularly answer my initial question but I had not tried using forward slashes in the path and when I do:
exec('ls C:/temp/*')
It works correctly, and as 0stone0 said, it only returns the last line of the output, which is fine since this was just for proof of concept as I was not actually attempting to parse the output.
Also, on a side note, since posting this question my system had been updated to Win11 22H2 and now for some reason the original test code (with the backslashes) no longer returns the "Cannot access / no file" error message. Instead it just returns an empty string and has no output set to the &$output parameter either. That being said, I'm not sure if the forward slashes would have worked on my system prior to the 22H2 update.
exec() only returns the last output line by default.
The wildcard probably works, but the output is just truncated.
Pass an variable by ref to exec() and log that:
<?php
$output = [];
exec('ls -lta /tmp/*', $output);
var_dump($output);
Without any additional changes, this returns the same as when I run ls -lta /tmp/* in my Bash terminal
That said, glob() is still the preferred way of getting data like this especcially since
You shouldn't parse the output of ls
I've an issue while using exec on php, maybe I didn't understand how it works.
The problem is: I wanna execute a binary file named 'test.exe'. That program takes data from an input file 'input.xml' and create an new file 'output.xml' with some modification on those data.
The below command line works perfectly on windows cmd :
>cd C:\Test
>test.exe C:\XML\example.xml C:\XML\example.out.xml
But a php script like this :
exec('C://Test//test.exe C://XML//example.xml C://XML//example.out.xml');
Doesn't work like suspected;
Each time I get beside the empty generated file example.out.xml another file named gmon.out.
I don't know what kind of file it is. Is it possible that this file will be the source of my problem?
Any idea?
You're using the wrong slash, you should be using a double backslash (one to be printed, and another to escape it). Using // will be literally translated to // so PHP will try to find C://Test//test.exe and fail.
The corrected syntax would be either
exec('C:\\Test\\test.exe C:\\XML\\example.xml C:\\XML\\example.out.xml');
or
exec('C:/Test/test.exe C:/XML/example.xml C:/XML/example.out.xml');
I need to have my Python program open a file, use some of the data in it, and spit out a different file. I'm having several issues, and was hoping if someone could definitively tell me if they are permissions based and if so, how to fix them. My Python program works through the terminal.
Here are some areas I've identified where it doesn't work:
import matplotlib.pyplot
infile = open('/correct_pathway/textfile1.txt','r')
outfile = open('/correct_pathway/textfile2.txt','w')
It is having troubles on all of these separately. I didn't know there could be permissions issues while importing a module, but there are. Also the files are globally read/writable that it is trying to open.
EDIT: Sorry, that was unintentionally vague and had a typo in the code that was not actually there. The PHP code as written on the webpage is as follows (it works if I call in a much simpler python program, so there is no problem I can think of here):
<?php $command= '/usr/bin/python /correct_pathway/program.py';
$temp = exec($command, $output);
print_r($temp); ?>
The code is supposed to open the infile, read a number off of it, and then write that number to the outfile as well as print off a different number. The printed number should be displayed on the webpage. This all works fine through the terminal, just not on the webpage.
Thanks in advance!
To define how a file should be opened, i.e. read or write, the syntax is to surround the r or w with quotes. So your above code should look like the following.
import matplotlib.pyplot
infile = open('/correct_pathway/textfile1.txt','r')
outfile = open('/correct_pathway/textfile2.txt','w')
see if you can access the files with the quotes added.
I was running over a sample script and hit on this particular issue.
The script starts off by setting
$docroot=$_SERVER['DOCUMENT_ROOT'];
For writing to a file,
#$fp = fopen("$docroot/../parts/partsorders.txt",'ab');
is used. But no matter what, this fails to write to the file.
After a tinkering with it for a while, I set the command to
#$fp = fopen('$docroot/../parts/partsorders.txt','ab');
used single quotes instead of double quotes and it worked fine!
My question is, isn't the former double quoted format supposed to work instead of the single quotes. What is happening here ?
Here is the stripped down code, guys (Assume that the file exists in the server) :
<?php
$docroot=$_SERVER['DOCUMENT_ROOT'];
$outputstring = "herpderp";
?>
<html>
<head>
<title>Quotes</title>
</head>
<body>
<?php
#$fp=fopen("$docroot/../parts/partsorders.txt","ab");
flock($fp, LOCK_EX);
if(!$fp) {
echo "<p><strong>Failed.</strong></p></body></html>";
exit;
}
fwrite($fp,$outputstring,strlen($outputstring));
flock($fp,LOCK_UN);
fclose($fp);
echo "<p>Order written.</p>";
?>
</body>
</html>
There are differences between single and double quoted strings in PHP. Single quoted strings do not cause the expansion of variable names while double quoted strings do. See here. Why your code works when you use the variable name with single quoted strings doesn't make sense to me. Furthermore, it's a bad idea to use # in front of your fopen commands, it will prevent you from seeing the error output.
The double quote one is the one that should evaluate $docroot for you. What the single quote should do is try to open a file that actually has $docroot as a string in it's path. Does
#$fp = fopen($docroot . '/../parts/partsorders.txt','ab');
yield the same result?
And do you use #to supress errors? In that case it should be before the function I think
$fp = #fopen($docroot . '/../parts/partsorders.txt','ab');
But don't do that when trying to find errors in your application. The thing is that you could very well get an error that it can't find the file and you just don't notice.
UPDATE
Thanks to pinkgothic for his comment, firstly for providing the correct terminology and secondly for pointing out that this answer is wrong.
I have experimented with the theory that shell is trying to expand the environment variable $docroot and found that shell expansion is not possible in fopen().
I tried the following code and got this error (I have a file called test.txt in my home directory)
$fp = fopen( '$HOME/test.txt', 'rb' );
//PHP Warning: fopen($HOME/test.txt): failed to open stream: No such file or directory in php shell code on line 1
So unless the OP has some configuration which allows shell expansion in fopen(), my answer is, as I say, incorrect.
The string $docroot/../parts/partsorders.txt is being sent directly to the operating system shell. As there is no $docroot variable set it is replaced by an empty string, so it is the same as using
#$fp = fopen('/../parts/partsorders.txt','ab');
Which is an absolute path starting from /, the document root.
#run from shell (bash)
~$ echo $docroot/../parts/partsorders.txt
/../parts/partsorders.txt
After my comment, I had a night's sleep and realised fopen() may not actually use/be like realpath() (which expects all segments to be set, even the ones that are irrelevant for the final normalised path).
It doesn't.
Accordingly, the reason your file is opened is actually fairly simple:
'$docroot/../parts/partsorders.txt'
...which is read as "pastorders.txt in the 'parts' folder which is a folder found in the folder above the '$docroot' folder which is in the current working directory" collapses to...
'parts/partsorders.txt'
...because fopen() simply vanishes $docroot/.. away without checking that $docroot exists. (Functions like realpath() do check it, which was throwing me off.)
So, your file is actually in <current working directory>/parts/partsorders.txt. (Since you're opening the file with the a flag, if it didn't exist there before, it was definitely created there.)
Whatever your $_SERVER['DOCUMENT_ROOT'] contains, it seems it's not what you want. Additionally, in some setups, you can't reasonably .. above $_SERVER['DOCUMENT_ROOT'] - permissions actually won't let you.
If that environment variable outright isn't set (if that's even possible; but I think this demonstrates the problem even if it isn't), the path is quite different:
"$docroot/../parts/partsorders.txt"
...becomes:
"/../parts/partsorders.txt"
...which tries to get up the hierarchy past the root point (/), which would of course not work.
I suggest echoing out or logging $_SERVER['DOCUMENT_ROOT'] and taking a look at what it actually contains, and if it's what you expect it to be.
What might be worth looking for is __DIR__ (or in older PHP versions, dirname(__FILE__)), which takes the directory the file. As long as the file knows where it is, you can just read out files relative to its location.
I'm working with the PHP CLI on windows at the moment to write some small desktop command-line apps.
I wanted to know if and how it may be possible to:
Clear the screen (cls would be the normal command but exec() won't work with it)
Change the color, change the color of parts of the output (seen this in programs before)
Make the command line horizontally bigger - things quickly get unreadable
Is any of the above possible from inside a PHP script?
On Windows, in the standard CLI prompt, you cannot output in colour (as in the answer by Spudley).
You can change the size of the window as a user by right-clicking the command window's title bar and selecting Properties, then ammending values in the Layout tab. I do not think it is possible to ammend the width of the CLI within PHP.
You can check the width of the CLI window on Windows using the function I wrote here
See the PHP manual page for working with the commandline
To directly answer each of your bullet points:
There is a comment on that page which gives a function that can clear the screen. I'll quote it here for you:
<?php
function clearscreen($out = TRUE) {
$clearscreen = chr(27)."[H".chr(27)."[2J";
if ($out) print $clearscreen;
else return $clearscreen;
}
?>
There's also another comment which explains how to change the colours. Again, I'll quote it:
<?php
echo "\033[31m".$myvar; // red foreground
echo "\033[41m".$myvar; // red background
?>
and to reset:
<?php
echo "\033[0m";
?>
You should read through the rest of that page for a whole load more suggestions on how to manipulate the CLI.
The only part of your question that leave unanswered is the third bullet point. Sadly, I don't believe you'll be able to do this, and I don't think it's possible to horizontally resize the Windows command line window.
Hope that helps.
I created a small backup script with PHP, and from what I can remember, you can print backspace characters to remove content. Not really ideal though.
Just google'd it: http://www.php.net/manual/en/features.commandline.php#77142
As far as the third question goes, I suggest you witch the default command line to Console 2. It is a great replacement that not only lets you use any width you like (as long as it fits your screen), but also supports command history, tabs, and some UI sugar.
The provided code will not work under Windows because PHP under windows does something to the command window. I am not sure what PHP does but I wrote a simple Freebasic program with only two lines:
cls
end
I then compiled it and ran it under a regular command line window. It cleared the screen without any kind of a problem. I then did the following in PHP:
<?php
echo "This is a test\n";
system( "cls.exe" );
exec( "cls.exe" );
passthru( "cls.exe" );
?>
When I ran the program it did nothing more than just the "This is a test" line. Thus, there is some kind of suppression going on with PHP that looks for and stops any kind of escape sequence from occurring. Until this is fixed in PHP - you will never be able to do a cls, nor use curses, ncurses, or any other library. What has to be done is to integrate something like FreeBasic's windowing methods as some kind of a class (or maybe just a C set of routines) that will open a new window via THAT language's methodologies and use them to do the text window. Then all of the escape sequences will work. Until then - they won't.
What I find weird about this is that PHP was originally written in Perl and Perl will do ncurses on Windows without any problems. Perl will also allow all escape sequences to work. So there is just something being done on the Windows compile that is causing this problem.