I am having the following problem:
When I want to run an uncompiled Lua script in Apache, I just add #!/usr/share/lua at the beginning of the file, so far everything works fine.
But if I want to compile it with luac to have it run a bit faster I cannot add any text to the file, as it is compiled binary data (which still needs to be interpreted by the Lua interpreter, and cannot be executed on its own).
Is there a way to tell Apache to always have /usr/share/lua interpret files with the .lua (or .luac to mark them as compiled) extension?
I'm not aware of a way to do this as a CGI script, as the CGI spec basically requires that the shell can figure out how to run a file based on the hashbang at the beginning.
However, you could write a simple CGI handler in Lua that does a loadfile() on the .luac file and then executes it. You can set .luac files to be handled by this script with the following directives in a .htaccess or httpd.conf file:
# Files of a particular file extension
AddHandler my-file-type .xyz
Action my-file-type /cgi-bin/program.cgi
In this example from the docs, program.cgi would be passed the filename requested by the URL so you could parse it and run that file.
Related
I have a .cmm file which helps in debugging of Qcomm chipsets.
This file has a line : cd ../../../../../modem_proc
When I run this same cmm file using T32 GUI, it runs fine and does the work. But when I am trying to run the same file using windows command line using,
C:\T32\bin\windows64>t32mqdsp6.exe -c C:\T32\config.t32 -s D:\path\to\xxx.cmm
Following error is thrown in T32: syntax error in B::cd ../../../../../modem_proc
What am I missing here? I have no hands-on experience with T32 what-so-ever.
The problem probably results from different working directories. Type
PRINT OS.PWD()
in the GUI and add it to the top of the script. I'd suspect they are different.
Don't use working directory relative paths, instead use paths relative to the script, e.g.
CD ~~~~/../../../../modem_proc
The four tilde (~) symbols mean "directory of the currently executed script". There's still a possible issue with this solution when using multiple GUIs and the intercom, but for most use-cases this should be OK.
When starting TRACE32 (up to build 99518) without option "-s", it starts a default script t32.cmm form your TRACE32 installation directory. But t32.cmm is not executed, when "-s" is used.
So probably your t32.cmm is changing your working directory. If so you can fix the issue by adding the line
DO ~~/t32.cmm
to the top of your script xxx.cmm.
See also https://www.lauterbach.com/frames.html?help_autostart.html
The default working path is also set by the TRACE32 configuration file. That is the file passed with "-c". So if your are using a different configuration file than C:\T32\config.t32 when starting your TRACE32 GUI the normal way, then you should use that configuration file also when starting TRACE32 from the command line.
To get the path of the configuration file usually used, start TRACE32, execute command AREAand then command PRINT OS.PCF()
Furthermore dev15 is probably right here https://stackoverflow.com/a/53671657/4727717:
Use paths relative to the PRACTICE script (cmm-file) by starting each path with four tildes.
Using a .user.ini file with extension=geoip.so (or mysqli.so) I'm trying unsuccessfully to load the relevant module: in the phpinfo() page of Php 7.1 (or even Php5.4) the module is never shown.
1) The .user.ini file is working correctly because I'm able to modify the variable memory_limit.
2) The phpinfo() function correctly shows the extension_dir folder containing .so extensions that I want to load (in the php.ini file this variable is not present, however).
3) The php error log contains no message.
Every suggestion is welcome.
The .user.ini files can only set certain PHP ini settings. It just so happens that the extension setting is not one of them. In fact, according to the manual, the extension setting is only valid in the core php.ini file. So put the extension=geoip.so in your main php.ini file.
As a side note: I use Ubuntu/Debian for most of what I do with PHP. The standard PHP distro that is available through the Debian package archives has extra code compiled into it that allows for a distributed configuration. The way this works is the SAPI module scans a conf.d directory and includes any ini files. Typically when you package an external PHP extension for Debian (which I might add is a pain - I've done it for my own extensions) you include a little ini file that includes the extension (e.g. extension=myext.so). The package installs it in the distributed config directory and it is included into the php.ini file when PHP spins up. Perhaps you meant to install a Debian-based config like this?
Another side note: Since you are probably using a CGI SAPI and might want different sites to load different modules (exclusively), you could perhaps look into getting the Web server to point the CGI PHP at a different php.ini file. I'm just presuming you want to achieve something like this. However loading modules for certain directories using .user.ini files is just not possible.
Try disable or configure selinux. Check selinux audit log.
I am not root. I have written and placed a script in the cgi-bin of my apache server. The code is too long for here, but in a nutshell, the script is called from a browser and a filename argument is also passed as a URL parameter. The script takes the filename, locates the file and reads it. The file contains a simple list of files/locations to be copied. The script iterates through each line of the file and copies the file on that line from the current server to a remote server using ssh and standard rsync commands. It's all pretty standard stuff.
The script runs perfectly from command line, all files are copied correctly. When launched from the browser, the script appears to function perfectly. It throws no errors and debug logs tell me everything was copied fine, only the actual files themselves are not actually copied.
I'm assuming it has something to do with the script being run by apache (or wwwroot) in the cgi-bin, which is not the script owner, as I am. As I am not root, I cannot change ownership or use sudo. Any ideas on getting this to work?
I'm able to run a Go application as a website with Apache using the following code.
hello.go:
package main
import (
"os"
)
func main() {
os.Stdout.WriteString("Content-Type: text/html; charset=UTF-8\n\n")
os.Stdout.WriteString("Hello!\n")
}
.htaccess:
AddHandler cgi-script .exe
I compile the app using go build hello.go and going to http://localhost/hello.exe works as expected.
But now I have to recompile after every change I make in the sourcecode.
Is it somehow possible to tell Apache to run hello.go (Apache should run go run hello.go) when visiting http://localhost/hello.go?
By the way, this is only to speed development, not for production!
Go is a compiled language, you'd need to compile it first. There currently aren't any interpreters/VM's for Go.
You're best bet is to just have a process/cron job that checks for the .go file being newer than the binary, and rebuilding it when it notices the file changed.
https://github.com/howeyc/fsnotify is a package that allows you to watch files for changes.
You could use gorun which enables you to put a #!/usr/bin/gorun line at the top of the file so it is run like a script. gorun will compile it on the fly then run it. I've used it quite a bit for making golang scripts and I expect it would work for CGIs too.
You'd have to mark the script as executable (chmod +x) and tell apache that the .go extension was executable.
Not sure I'd recommend this for production but it should work reasonably efficiently as gorun has a cache.
An easy solution would be to use a tool which re-compiles your code on changes to the source files. For example GoWatch.
Or try it yourself by using fsnotify as Erik already stated. Example: Simple Compile Daemon.
You could also invoke go run in your CGI script.
I recently modify the "include_path" var in my php.ini file. Before you ask, I restarted the apache service. The change work for every pages we access from a web browser.
The problem is the cron jobs doesn't seems to consider that change. When I do a phpinfo() inside the cron job, it uses the same php.ini file than the web server and it is the one I changed, but the value beside "include_path" is the old one.
So is there a way to "restart" crontab?
Or maybe there is another problem?
Several systems use a separate php.ini file for web and CLI. You will need to make changes in that one as well: How to find the php.ini file used by the command line?
The easiest way to find this file is to run this at the command line: php --ini which will result in output like this:
user#computer:~$ php --ini
Configuration File (php.ini) Path: /etc/php5/cli
Loaded Configuration File: /etc/php5/cli/php.ini
Scan for additional .ini files in: /etc/php5/cli/conf.d
What you see as "Loaded Configuration File:" is where you need to add your changes.
EDIT: Another option, is in your CRON script use set_include_path() to make the change at runtime.
PHP generally has two .ini files. One for in-webserver (SAPI) and one for command-line (CLI) usage. If you modified only the SAPI one, then anything running from CLI (e.g. cron jobs) will not see the change.
do a php -i at the command line to see where PHP is looking for its ini file while in that mode.