First some background. I recently installed some software (TeX live actually), and the binaries were placed by the installer in a non-standard location (/usr/local/texlive/2011/bin/x86_64-linux). No problem, because I can change the $PATH in to include this directory. However, I use latex inside Makefiles, and Make said it could not find 'latex'. I eventually realized that Make asks the kernel to run latex in a shell-independent way. Thus I moved all my latex executables to /usr/local/bin and everything works, presumably because the kernel can now see the executables.
If this is correct, my question is: where does the kernel look for executables when asked to run a program when this is independent of a shell?
The kernel doesn't look for executables - it is always told the (absolute or relative) path. All program executions (I believe) basically come down to calling the execve() function, which needs to be told the path of the executable.
When you call programs using just their names, it's up to whatever is interpreting your commands (shell, make) to locate the program. Alternatively, library functions such as execlp() can be used, which do the path resolution themselves (see "Special semantics").
Related
I am running a MediaWiki (1.34.1) on a Windows server. The wiki contains some Lua modules which are executed by the Scribunto extension running Lua 5.1.4.
Up to now I am using the luastandalone but I would like to use the luasandbox engine (should be faster).
With the lastest PHP luasandbox release 4.0.2 PECL provides a Windows DLL (https://pecl.php.net/package/LuaSandbox/4.0.2/windows).
With this DLL is it possible to run luasandbox under Windows?
How can I install/configure the PHP/MediaWiki/Scribunto environment to use this DLL?
Yes, it is possible to use LuaSandbox under Windows with IIS, and is in fact an especially convenient way to do so, You simply install the necessary Lua binary as a PHP extension into your existing PHP interpreter (which you know is working, because MediaWiki is implemented in PHP).
I discuss this at some length in this conversation on the MediaWiki page Extension Talk:Scribunto but I'll provide the essentials here as well:
I did finally get Lua working under IIS on Windows 10, with PHP 8.0. The trick was, I abandoned the luaStandalone binary entirely, and instead downloaded the (just released less than 2 months ago) PHP luaSandbox extension from PECL:
https://pecl.php.net/package/LuaSandbox
Click on "DLL", then choose the build that matches your PHP install (for me it was PHP 8.0, x64, non-thread safe — the details are at the very top of the long, long output of php.exe -i from a command line), and download the provided zip file. After extraction, only two files are important:
php_luasandbox.dll, a PHP extension module that goes wherever the rest of your extensions are. (For me, C:\Program Files\PHP\v8.0\ext\.)
lua5.1.dll, an embeddable Lua interpreter that gets installed in the directory where the php.exe binary lives. (For me that was C:\Program Files\PHP\v8.0\, the parent directory of the extension location).
After that, just edit your php.ini to add:
extension=php_luasandbox.dll
and edit LocalSettings.php to include:
$wgScribuntoDefaultEngine = 'luasandbox';
(making sure to remove or comment out any lines about luaStandalone).
Relaunch IIS, and that should be that. If you have MediaWiki working at all, you've already got PHP running, so using Lua that way, as a PHP extension, just makes eminent amounts of sense.
As I note in the MediaWiki discussion, there's some degree of controversy over this because the Lua developers themselves are sort of down on the notion of a "sandboxed Lua". They do not believe it to be a technically viable method of restricting Lua's access to and consumption of system resources. But on Windows, most of the restrictions they recommend imposing on the standalone binary are not available from the OS anyway, making the situation even more confusing/unclear.
I have a working version of my project in eclipse.
I exported the project as a runnable jar.
Extracted (after converting to .zip)and tried to compile a particular java file from the command prompt
(Doing it this way since I have a project requirement, where input parameter inside that particular file can be modified and recompiled/run by users who wont have Eclipse)
I have used some external libraries( for Eg:json-simple,gson etc).They arent getting recognized , during compilation.
But if I run the class file(from the Eclipse compiled version), it gets executed properly
a)Tried to compile from root folder(using package name)
javac packageName.javaFileName.java
b) and went inside the package and compiled directly.
javac javaFileName.java
The a)part didnt compile at all saying classNotFound. The b)part started compiling but threw an error where none of the external libraries got recognized.(Getting --> error: cannot find symbol for places wherever the code/import of the external lib is used)
a)Tried to compile from root folder(using package name) javac
packageName.javaFileName.java b) and went inside the package and
compiled directly. javac javaFileName.java
The a)part didnt compile at all saying classNotFound.
Yes. javac requires you to specify a filesystem path to the (first) source(s) to compile. You appear instead to have tacked .java onto the end of the desired fully-qualified class name. Probably you want to compile from the root of the unpacked jar, specifying a correct path:
javac [options] package/name/className.java
for class package.name.className. (You can also compile from a different working directory if you specify an appropriate option, as discussed below.)
The b)part
started compiling but threw an error where none of the external
libraries got recognized.(Getting --> error: cannot find symbol for
places wherever the code/import of the external lib is used)
If the class you're compiling depends on others that also need to be compiled then javac would likely make a similar complaint about them. Either compile from the root (as in (a)), or specify the path to the source root via the -sourcepath option. Either way, there's no reason to descend into the source tree to compile.
But the external libs are actually a separate, albeit related, question. You don't need to compile these, but you do need to tell javac to use them as sources of classes. You would do that via the -classpath option, which you can abbreviate to -cp. If those were packaged in the jar itself (i.e. a "fat jar") then that should be fairly easy, something along these lines:
javac -cp .:lib/dependency1.jar:lib/dependency2.jar package/name/className.java
The "lib" part may vary, and the separator definitely differs depending on OS (on Windows it is ;, whereas on Mac / Linux / Solaris is is :, as shown).
If the external libs were not packaged into the main jar then the procedure is the same, but you might have a bigger challenge finding the needed jars. Also, such a jar is probably not runnable if you move it to a different machine. Nevertheless, you should probably look in META_INF/MANIFEST.MF, as it should contain the needed information.
I want to use porg in my LFS distro. It's similar to checkinstall, it uses LD_PRELOAD.
1. If you read the README:
CheckInstall currently is unable to track any file system changes made
by statically linked programs
I think it refers to the commands like mkdir, mv, ln, etc. So I should not have any problems with this. Am I right?
2. Then, the main problem:
NOTE ON SUID/SGID PROGRAMS: CheckInstall can't track their actions
because of some limitations in the LD_PRELOAD system that
installwatch uses. This is good for security reasons, but it can
generate unexpected results when the installation process uses
SUID/SGID binaries.
What does it mean? I don't care if I lose track of some files. I do care if there will be unexpected results, or if I can't install correctly the package.
Also, how many packages have this problem?
In case coreutils (mkdir, mv, etc. ) on your system are statically linked (i.e. running file on them reports "statically linked") porg will not be able to track their operations and thus some installed files may go untracked. Statically linked executables are second-class citizens in Linux and LD_PRELOAD does not support them.
Setuid executables indeed sanitize LD_PRELOAD before usage - they ignore all files which have slashes in name (so that only files from standard system paths can be loaded) and also require that shared library itself has setuid bit set. So in your case you'll need to locate porg's preloaded library and set setuid bit on it (via chmod a+s libxyz.so). BTW it may make sense to ask porg authors to do this change in their distro. I don't think this will cause any problems in a typical package as installers typically don't need to run setuid programs (like mount, passwd, sudo).
As the title says, how to use luadoc in ubuntu/linux? I generated documentation in windows using batch file but no success in ubuntu. Any ideas?
luadoc
Usage: /usr/bin/luadoc [options|files]
Generate documentation from files. Available options are:
-d path output directory path
-t path template directory path
-h, --help print this help and exit
--noindexpage do not generate global index page
--nofiles do not generate documentation for files
--nomodules do not generate documentation for modules
--doclet doclet_module doclet module to generate output
--taglet taglet_module taglet module to parse input code
-q, --quiet suppress all normal output
-v, --version print version information
First off, I have little experience with Luadoc, but a lot of experience with Ubuntu and Lua, so I'm basing all my points off of that knowledge and a quick install that I've just done of luadoc. Luadoc, as far as I can see, is a Lua library (so can also be used in Lua scripts as well as bash). To make documentation (in bash), you just run
luadoc file.lua
(where file is the name of your file that you want to create documentation for)
The options -d and -t are there to choose where you want to put the file and what template you want to use (which I have no clue about, I'm afraid :P). For example (for -d):
luadoc file.lua -d ~/Docs
As far as I can see, there is little else to explain about the actual options (as your code snippet explains what they do well enough).
Now, looking at the errors you obtained when running (lua5.1: ... could not open "index.html" for writing), I'd suggest a few things. One, if you compiled the source code, then you may have made a mistake somewhere, such as not installing dependencies (which I'd be surprised about, because otherwise you wouldn't have been able to make it at all). If you did, you could try getting it from the repos with
sudo apt-get install luadoc
which will install the dependencies too. This is probably the problem, as my working copy of luadoc runs fine from /usr/bin with the command
./luadoc
which means that your luadoc is odd, or you're doing something funny (which I cannot work out from what you've said). I presume that you have lua5.1 installed (considering the errors), so it's not to do with that.
My advice to you is to try running
luadoc file.lua
in the directory of file.lua with any old lua file (although preferably one with at least a little data in) and see if it generates an index.html in the same folder (don't change the directory with -d, for testing purposes). If that DOESN'T work, then reinstall it from the repos with apt-get. If doing that and trying luadoc file.lua doesn't work, then reply with the errors, as something bigger is going wrong (probably).
I am currently relearning Ocaml and am in the need of a good editor. There is a new editor from OcamlForge: OCamlEditor http://ocamleditor.forge.ocamlcore.org/. Prerequisite for installation is Lablgtk2.
Installing Lablgtk2 on windows is not straight forward and there is good instruction here: http://wwwfun.kurims.kyoto-u.ac.jp/soft/lsl/install-win32.txt
I have completed the first two steps and in the third step, as warned, it is failing on the native code version. This is where I am left stranded. How do I check to see if the assembler is on my path? What am I missing here?
Please help me move forward from this point.
You have an MSVC installation, right? By default MSVC doesn't add command-line tools (cl - compiler, ml - assembler, link - linker) to the PATH (and needed directories to INCLUDE and LIB). But it provides a shell script to do this - MSVS9\Commnot7\Tools\vsvars32.bat. Copy it somewhere to the PATH so that you can easily call it any time needed. Then, before running ocaml compiler call vsvars32.bat to setup the environment. You can make this environment permanent by looking at changes to %INCLUDE%, %LIB% and %PATH% variables made by this script and adding them manually to environment variables of current user (usual windows gui insanity - My Computer -> Additional -> Environment variables).