I installed PHP GTK in C:\php-gtk but when I go to run it like from the command line like this
cd C:\php-gtk2
php demos\phpgtk2-demo.php
It gives this error
Please load the php-gtk2 module in your php.ini
My ini file has this content (it is called php-cli.ini)
[PHP]
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; About the php.ini in PHP-GTK ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; This file introduces the php.ini settings that you will need in order to
; run PHP-GTK on your system. You may also need other settings from PHP's
; standard php.ini file, e.g. to load further extensions or otherwise control
; PHP's behaviour in matters such as error reporting. Please add those in
; the upper part of this file, in the PHP section.
; You should use PHP's CLI executable to run PHP-GTK. This php.ini file
; should be in the same directory as the PHP executable, to avoid conflict
; with any other copies of PHP that may be installed on your machine.
; The first thing you will need to do is tell PHP where you want it to look
; for the PHP extension libraries (php_*.dll or php_*.so files) on your system.
extension_dir = "./ext"
; Make sure that php-gtk2.dll under Windows, or php-gtk2.so under Unix, is in
; the directory named in extension_dir alongside any other shared PHP extensions
; you intend to use, and tell PHP to load it.
extension = php_gtk2.dll
;extension = php_pdo.**
;extension = php_sqlite.**
;extension = php_pdo_sqlite.**
[Date]
; Defines the default timezone used by the date functions
;date.timezone =
[PHP-GTK]
;;;;;;;;;;;;;;;;;;;;;;
; PHP-GTK extensions ;
;;;;;;;;;;;;;;;;;;;;;;
; Extensions written for PHP-GTK are in the format php_gtk_*.dll (Windows) or
; php_gtk_*.so (Unix), written here as a comma-separated list. The library
; files need to be in the same directory as the PHP-GTK library, along with
; any other PHP extensions you are using.
;php-gtk.extensions = php_gtk_libglade2.dll,php_gtk_sourceview2.dll
;;;;;;;;;;;;;
; Code Page ;
;;;;;;;;;;;;;
; The string variables used for titles and other text values in GTK+ are
; encoded in UTF-8 internally. A code page is needed so that PHP-GTK 'knows'
; which character set is being used, and can convert it to UTF-8 as necessary.
; If your environment uses UTF-8 already, you can set the codepage directive
; to UTF-8 to skip the conversions.
; The default codepage setting in PHP-GTK 2 is ISO-8859-1, but you can also
; use either OEM (e.g. 850) or Windows Code Pages (e.g. CP1250) here, so
; long as the encoding format you choose is capable of iconv conversion. See
; http://www.microsoft.com/globaldev/reference/cphome.mspx for a list of
; the code pages and character sets that are supported on Windows systems.
php-gtk.codepage = CP1250
What do I need to do? Is there something wrong with the ini file? Do I need to rename it? What is the problem that is tripping up the program?
you can take it a bit further, and not worry about paths, I work in Windows environment and I use relative paths even inside .ini like this:
extension_dir = "ext"
extension = php_cairo.dll
extension = php_mongo.dll
This allows me to move the php-gtk folder anywhere.
As for running my projects I do a similar thing, I create .cmd files like this:
"%CD%\..\..\PhpGtkRuntime\php.exe" "%CD%\index.php"
So you can have for example a central folder and in a subfolder goes php-gtk and in an other one all you projects like this:
php-gtk/PhpGtkRuntime
php-gtk/Projects
The whole idea is that I distribute a folder to the final user with a run.cmd inside it and the user does a simple copy paste of the folder, really nothing else. I have made an example package with MongoDB included and all of it is portable even MongoDB, Check here..
Ok the problem was that I needed to call php-gtk as I had renamed it already
Just solved the problem.
I was trying to run the demo script from the demos folder. But when I tried it with the same folder where the php.exe is it ran smoothly. So there is no problem with the php-cli.ini or no need to worry about this error "Please load the php-gtk2 module in your php-cli.ini"
So Goodluck with PHP-GTK.
Related
When trying to open a file with text editor VIM, I am unable to open the file unless VIM (shortcut) is in my current working directory. As an example, I am able to write start firefox to open a firefox window. However, start vim C:\filepath\filename.txt does not work unless a vim shortcut is in my current directory. How do I get around this?
Also, is there a way to have a program execute a file in the current working directory without having to reference the entire file path? For example instead of Start-Process vim C:\Users\User\Desktop\File\file.txt is there an available path shortcut like Start-Process vim ~\file.txt with ~ representing the current working directory?
The OS need to determine the full path of the exe, no matter what.
There's 2 ways that it will happen.
You're calling the executable from it's working directory
The executable location is in the Windows environment variable.
You can view the PATH variable content through this simple statement
$env:Path -split ';' | sort
You sill see that the Firefox path is listed there, but not the one from VIM.
That's why the former can be started by it's executable name and the latter require the full path.
You need to add VIM directory to your PATH variable if you want to be able to call it just by typing vim
Otherwise, if you have restricted access or don't want to edit that variable, you can also set a $vim variable, then invoke it whenever you want to call the executable.
Regarding the second part of your question
Powershell use the dot as a reference to the current directory .\file.txt.
You can also just specify the filename without anything else file.txt.
Both backslash \ & slash / work for filepath so .\file.txt and ./file.txt are both valid ways to reference the file.
Use ..\ to reference the parent directory (e.g. ..\file.txt)
$Vim = "c:\Path\To\Vim.exe"
& $vim "file.txt"
& $vim ".\file.txt"
#Forward slash also work for paths
& $vim "./file.txt"
I am trying to set a mapping for FileType perl. The mapping is for the case when I forgot to use semicolon at the end of the line.
So first I tried adding in my .vimrc autocmd! FileType perl nnoremap <leader>; $a;<esc> and it worked fine but than I thought of using ftlugin/perl.vim .
So I added the below line in my corresponding ~/.vim/after/ftplugin/perl.vim
nnoremap <buffer> <leader>; $a;<esc>
but it didn't work.
Any idea why it is not working ?
My perl version is perl 5, version 14.
Try putting the file in ~/.vim/ftplugin/perl.vim instead of ~/.vim/after/ftplugin/perl.vim. From :help after-directory:
*after-directory*
4. In the "after" directory in the system-wide Vim directory. This is
for the system administrator to overrule or add to the distributed
defaults (rarely needed)
5. In the "after" directory in your home directory. This is for
personal preferences to overrule or add to the distributed defaults
or system-wide settings (rarely needed).
From :help ftplugin:
If you do want to use the default plugin, but overrule one of the settings,
you can write the different setting in a script: >
setlocal textwidth=70
Now write this in the "after" directory, so that it gets sourced after the
distributed "vim.vim" ftplugin |after-directory|. For Unix this would be
"~/.vim/after/ftplugin/vim.vim". Note that the default plugin will have set
"b:did_ftplugin", but it is ignored here.
One thing I just noticed that was driving me crazy: <buffer> must be lowercase! Out of habit, I uppercase all of my <BRACKET> prefixes... and I had done the same for <BUFFER>. None of my ftplugin mappings worked and I couldn't figure it out... until I wasted hours trying different things, only to find that it must be lowercase <buffer>.
I am running a MATLAB project, which is shared by several users, some running Windows and some running Linux.
In some of the scripts, I need to access files which are in external directories, and which I do not want to add to the MATLAB path.
To accommodate both Linux and Windows, I need to be able to determine the type of OS I'm running, and to set the directory separator accordingly ('\' for Windows, '/' for Linux).
I tried
os = getenv('OS')
(which I saw in some official guide),but it returns an empty string.
I could check the first character of 'pwd', but that's pretty ugly, and I expect that there should be something simpler.
Thanks for any suggestions!
To use correct directory separator you don't need to write code to handle different operating systems. filesep gives you the correct directory separator.
My1stDir = 'Year2012';
My2ndDir = 'Feb';
My3rdDir = 'Day03';
MyDir = [ 'mydata', filesep, My1stDir, filesep, My2ndDir, filesep, My3rdDir ];
In Linux you'll get:
MyDir =
mydata/Year2012/Feb/Day03
In Windows you'll get:
MyDir =
mydata\Year2012\Feb\Day03
Let's see if I can reach the EmacsW32 users on stackoverflow.
I've just installed the patched version of EmacsW32 from http://ourcomments.org/Emacs/EmacsW32.html
I find it very nice that .txt files are associated wth Emacs, so that when you click on one, emacsclient opens it in the running instance of Emacs.
Problem is, for some reason, the buffer is renamed with the old-style shortened file names, so, for example, the buffer with file "activities-2008.txt" is renamed to "ACTIV~1.TXT", which I don't like.
How do I get EmacsW32 not to rename the buffer, and use the whole file name as the buffer name instead ?
Ick, that sucks.
Why not just use the emacsclientw that comes with the standard Windows emacs distribution?
It does have a bit of an issue in that you get an annoying "No error" error box if Emacs isn't already running, but any real emacs user starts emacs first thing when they log on anyway. :-)
Solved.
The problem is not with emacs, but with the way Windows runs a program when a file type is associated in the registry.
In my registry, I had this value for the keys that associate txt files with Emacs:
C:\emacs-23.0.91.1\Emacs\bin\emacsclientw.exe -n "%1"
The problem is the %1, which is replaced by a short file name.
According to this message http://lists.gnu.org/archive/html/help-emacs-windows/2009-05/msg00022.html:
%L is long file names.
%1 is long file names IF
* Explorer can find the exe file (it does not look very hard)
AND
* The file header says it is Win 95 aware Win16 exe, or
* It is a 32 bit program
Else %1 will be a short name.
The solution is to use %L in place of %1 in the reg keys.
On all my Windows servers, except for one machine, when I execute the following code to allocate a temporary files folder:
use CGI;
my $tmpfile = new CGITempFile(1);
print "tmpfile='", $tmpfile->as_string(), "'\n";
The variable $tmpfile is assigned the value '.\CGItemp1' and this is what I want. But on one of my servers it's incorrectly set to C:\temp\CGItemp1.
All the servers are running Windows 2003 Standard Edition, IIS6 and ActivePerl 5.8.8.822 (upgrading to later version of Perl not an option). The result is always the same when running a script from the command line or in IIS as a CGI script (where scriptmap .pl = c:\perl\bin\perl.exe "%s" %s).
How I can fix this Perl installation and force it to return '.\CGItemp1' by default?
I've even copied the whole Perl folder from one of the working servers to this machine but no joy.
#Hometoast:
I checked the 'TMP' and 'TEMP' environment variables and also $ENV{TMP} and $ENV{TEMP} and they're identical.
From command line they point to the user profile directory, for example:
C:\DOCUME~1\[USERNAME]\LOCALS~1\Temp\1
When run under IIS as a CGI script they both point to:
c:\windows\temp
In registry key HKEY_USERS/.DEFAULT/Environment, both servers have:
%USERPROFILE%\Local Settings\Temp
The ActiveState implementation of CGITempFile() is clearly using an alternative mechanism to determine how it should generate the temporary folder.
#Ranguard:
The real problem is with the CGI.pm module and attachment handling. Whenever a file is uploaded to the site CGI.pm needs to store it somewhere temporary. To do this CGITempFile() is called within CGI.pm to allocate a temporary folder. So unfortunately I can't use File::Temp. Thanks anyway.
#Chris:
That helped a bunch. I did have a quick scan through the CGI.pm source earlier but your suggestion made me go back and look at it more studiously to understand the underlying algorithm. I got things working, but the oddest thing is that there was originally no c:\temp folder on the server.
To obtain a temporary fix I created a c:\temp folder and set the relevant permissions for the website's anonymous user account. But because this is a shared box I couldn't leave things that way, even though the temp files were being deleted. To cut a long story short, I renamed the c:\temp folder to something different and magically the correct '.\' folder path was being returned. I also noticed that the customer had enabled FrontPage extensions on the site, which removes write access for the anonymous user account on the website folders, so this permission needed re-applying. I'm still at a loss as to why at the start of this issue CGITempFile() was returning c:\temp, even though that folder didn't exist, and why it magically started working again.
The name of the temporary directory is held in $CGITempFile::TMPDIRECTORY and initialised in the find_tempdir function in CGI.pm.
The algorithm for choosing the temporary directory is described in the CGI.pm documentation (search for -private_tempfiles).
IIUC, if a C:\Temp folder exists on the server, CGI.pm will use it. If none of the directories checked in find_tempdir exist, then the current directory "." is used.
I hope this helps.
Not the direct answer to your question, but have you tried using File::Temp?
It is specifically designed to work on any OS.
If you're running this script as you, check the %TEMP% environment variable to see if if it differs.
If IIS is executing, check the values in registry for TMP and TEMP under
HKEY_USERS/.DEFAULT/Environment