I'm trying to read the windows registry to figure out what scripting environments are installed and where the stand alone interpreter executables are available.
When I did python, for example, I searched for
HKEY_LOCAL_MACHINE/SOFTWARE/Python/PythonCore/InstallPath
This gives me the install path for the python executable for the environment, this allows me to find if I have python 2.7, 3, etc and where those exes are.
I'm looking for something similar for Lua for windows.
I must use the registry for this search.
What Nicol said. You will be better served by scanning PATH against the list of known executables (but even that is not a guarantee as many of my local installs are not in PATH). Still, I think there is a better chance of finding those scripting engines that don't leave their traces in the registry. Or maybe use a combination of mechanisms.
Lua does not have an install path. Lua does not have an installation. Lua is not like Python, with an installer that puts everything in one specific place and sets up registry and PATH entries and such.
The standalone interpreter does not have a mechanism to query its location. If you're interested in learning the Lua version, you can always check the _VERSION variable field. But other than that, no, there is no mechanism for doing what you want.
Related
I am just starting out in Tcl and am trying to properly configure an editor and interpreter for use. On Tcl's download page it is recommended to use ActiveState's ActiveTcl, but I am learning Tcl for possible production use and want to avoid paying for it.
I tried setting up Eclipse's DLTK to use for learning, but from what I found I need to direct it to the tclsh executable to use it as the interpreter. In Tcl version 8.6.6, I can't find anything that will work. The supposed formats (I'm on Windows) should follow what's seen here, as I've seen this a few examples/tutorials.
As a last resort, I tried following the Windows instructions here to use my MS Visual Studio 2015 work with this, but there is no such vcvars file (what's asked for when reading makefile.vc after downloading Tcl).
I would really like to use Eclipse for this, so I guess my question is as follows: How do you use tclsh as a Tcl interpreter in Tcl 8.6.6?
ActiveTcl isn't a pay-for product. (ActiveState have some of those, but their language distribution isn't one of them as long as you're not after a support plan.)
To configure Eclipse to use the right installed version of Tcl, go to the Tcl → Interpreters page in the main Preferences panel. That lets you Add… an interpreter, which essentially just requires you to find where the tclsh you want to use is on your filesystem, and to give it a name. I use names like “Tcl 8.6” in my installation, so it isn't exactly rocket science. The DLTK system can find out pretty much everything else once it knows where the interpreter implementation is, but if you have several set up (e.g., I have both 8.5 and 8.6) then you'll need to say which one is default using the checkboxes in the list in the Interpreters pane.
(I've verified the above against Eclipse Neon running on OSX, but I don't think it will vary very much with other versions or platforms.)
I'm writing a Common Lisp application. I'd like to have a Bash script which will serve as the entry point to the application. Currently, I've written the script so that the user must pass in their name of the Common Lisp implementation to run it, so I would write ./script.sh clisp for GNU CLISP but someone with SBCL would have to write ./script.sh sbcl. This is necessary since, unlike languages like Python and Ruby, Common Lisp implementations do not have any standard name or standardized way of invoking them.
Is there any trick to detecting which Common Lisp implementation is installed, perhaps an environment variable or something? Basically, I'm looking for something better than forcing the user to pass in the name of the implementation.
You could use Roswell, which provides ways to set the implementation on a user or invocation level. You still need wrapper scripts, but roswell standardizes them.
Install the cl-launch Unix utility program which implements the abstraction described in #bishop's answer. The utility will detect most implementations of Common Lisp and can be used to execute a script or dump an executable which calls the content of a script (loads faster).
TL;DR: I don't think there's a trick, but you need not require the clisp interpreter on every invocation.
This is a relatively common pattern: you have a bash script that depends upon a certain executable being available, and it may well be available, but in different locations, possibly with the user having their own compiled version and/or the system having several alternatives.
The approach I've seen boils down to this algorithm:
If there is an environment variable that specifies the full path to an executable, prefer that
Otherwise, if there is a configuration file in the user's home directory that specifies the location, and possibly other parameters, prefer that
Otherwise, if there is a configuration in /etc that specifies the location, and possibly other parameters, prefer that
Otherwise, ask the system package manager to list the packages matching your application's typical installation names
The first three are easy enough to implement using the bash test functions and, I'm guessing, if you got this far you know how to do that. (If not, ask and I'll post examples.)
It is the fourth point that becomes interesting. There are two variables to deal with. First, determining the package manager in the installed environment. There are no shortage of these, and I've seen both table approaches (mapping OS to a package manager) and inquiry approaches (looking for executable that match expected names like rpm, yum, emerge, etc). Second, determining the package name appropriate for your package manager. This too can be tricky. On the one hand, you're probably safe iterating through the list of known executable and grepping the list. On the other hand, your package manager may provide "virtual" or "alternative" packages that generically provide a service, regardless of the specific implementation. For example, you could grep the portage tree for dev-lisp and be reasonably sure to find one installed package.
The easiest case is when your script is meant to be run in a small number of well-known environments: implement the one or more of the first three points to the let the user override the script's auto-selection, then your script's auto-selection just iterates over the known alternatives in your known environment until it finds one it prefers.
The hard case is when you have to support multiple environments. You end up writing an abstraction layer that knows about the different possible package managers and how to interrogate those package systems for various packages, either at a generic level or for specific packages. Having done this for a script set that deployed on AIX, HP-UX, Solaris, a couple of Linux distros, and cygwin Windows I can say: not fun.
As I read your question, you have a script that will be distributed to different users' machines whose environments you don't control. The only requirement of these target machines is they have bash and at least one Common LISP interpreter installed. From this, I inferred you couldn't install any loaders. However, if you can install, require, or detect the presence of any of the launchers mentioned in other answers, that will certainly save a ton of work.
Instead of having a different download of a program for Windows and Linux, would it be possible to make the download be a cross-platform script/executable that can download the correct installer from an FTP server and start that? What language should I write it in? The only one I can think of would be Java, but I don't want to take the time to learn it. I can't write it in Python or BASH, because most Windows machines don't have these installed. How should I do this?
Cross-platform executable(like an exe or a.out or ELF) is out of question. An executable is never cross-platform when Windows is involved. The scripting languages(or JIT compiled) have to be brought in for this purpose. We are in a CHICKEN-AND-EGG paradox. You may have to detect the OS the downloader is using, using a Javascript script in your website page and decide on what is to be done next etc...
Although not exactly what you are looking for, below are some pointers.
The best tool I know of, for multi-platform installers, is Flexera Software's InstallAnywhere. That might be a bit costly. For free options I would look into options like:
PERL
PYTHON (but this is out of question as per your post, but look at the end of my post for more options for Python)
Although writing the installer in any of the above languages might mean a lot more work, they provide you unmatched flexibility and complete control.
Perl requires that you install Perl interpreter and modules on Windows. But this also seems to be out of question for you. So you may avoid the headache by looking into:
PAR
pp
For Python go through:
py2exe
pyinstaller
I enjoy developing in Haskell, but am presently confronted with a challenge. At my place of education, I don't have administrative rights on my account. I want to debug/test while there. I need a way to run Haskell code without installing haskell-platform or ghci or anything else requiring of an administrative level of privilege. For instance, a web site which will run haskell code (abeit limited to not include file access of course) or a java utility (or standalone .app, though java is preferred due to the nature of the "parental controls"), or something else I haven't thought of. Source or compiled Java, Flash, and source code in Ruby or Python are preferred to native code. This is on Mac OS X 10.6, for reference.
You can install GHC without admin privileges, but you'll have to build from source. Check out the Building on MacOS X for more details.
Essentially, like any other open-source project, you can compile code and install it, generally, anywhere on your filesystem like into a folder in your home folder (I often use the ~/.local folder for that purpose).
As the linked page mentions, you can also use MacPorts and install it to any place you can write to. Once MacPorts is installed you can install GHC.
EDIT
As pointed out by Carl in the comments below, you don't need to build from source. Just grab the binary tarball from http://www.haskell.org/ghc/download_ghc_7_4_1#binaries.
In addition to all the other ideas, several companies will rent you virtual (cloud) linux servers for a few cents an hour. You have root on those and can install whatever you want, then freeze the image until you need it again.
Normally this might not be advantageous over a local solution if you can make one work, but a possible extra benefit would be that your work can stay on a single "computer" which you could access while sitting in front of any variety of modern PC that might be available to you on a given day.
An alternative not only for Haskell is http://ideone.com/
For the website option, TryHaskell will hardly cut it, it's way to limited.
codepad, OTOH, is more liberal, and should be of more use.
But honestly the bindist option is the best one, clearly!
If you truly can't install anything, then there's
http://tryhaskell.org/ -- like GHCi, but you can't load modules, which means not only that you can't use many standard functions (say, the functions in Data.List), but also that you can't use certain language features (like user-defined algebraic data types).
I also remember a hpaste-style site which executes its code -- and allows you to have private pastes -- but I can't remember it at the moment. Edit: I was thinking of http://codepad.org/ -- thanks #Mog
Try http://hiji.tinyrocket.se/ It is a haskell interpreter written using javascript.
http://ghc.io/ GHC.IO is a version of the Haskell interactive interpreter, ghci, that runs online in a web browser.
You just need to install homebrew, which you can do without root rights if you do so in your home directory. You can then brew install cabal-install
which will automatically install cabal and ghc, or brew install stack to install stack.
There is a web-based interpreter for Haskell at http://tryhaskell.org/. However, it may not provide enough functionality for your requirements.
I wrote a program in Perl, and now I want to send it to buddy. I don't want him having any kind of bother with launching it.
How do I make some package which he can just click and have all things ready to launch?
PS. I can ask him to download ActivePerl and install it beforehand.
PPS. I don't need to hide .pl sources from him. I need though automatic download and install of all required CPAN modules.
Also, what if in future I will need to scale it for production delivery? Meaning, it will be not a buddy on the receiving side, but Mr. Client?
I have used pp with great success. It can package a Perl interpreter and used modules all together into an executable file.
Then again there is always B::C which provides a perlcc utility, but I haven't had as much luck with that.
For easy distribution to windows clients, its hard to beat PerlApp, Par::Packer (aka pp), or Cava Packager.
Although I like Joel's suggestion best I'd want to point out another solution for you. As it seems you're targeting Windows you could also use the portable version of Strawberry Perl. Install the modules you need, add your script/application to it, setup a simple batch script to launch it with the portable environment and you're set.
The biggest downside compared to the pp (PAR::Packer) solution is that the size of your application will be rather big as pp only includes that what is necessary.
You might be looking for IndigoStar's perl2exe:
Perl2Exe is a command line program for converting Perl scripts to executable files. This allows you to create stand alone programs in Perl that do not require the Perl interpreter. You can ship the executable files without having to ship your Perl source code. Perl2Exe can generate executables for Windows and Unix target hosts.
Of course, the easiest way would be if your clients could run perl.
Yoy may wish to try Cava Packager. It can produce executables from Perl code on Windows, Linux and Mac OS X. It takes an alternative approach to PerlApp, pp and perl2exe. You should probably try them all and decide which you like best.
Note: As indicated by my name, I am affiliated with Cava Packager.
Par::Packer will do the job for you, without any fuss and is completely free. As long as you have installed the correct dependencies, you simply (on a windows machine) open a command prompt, CD into the directory where your perl source (e.g. 'samplefile.pl') resides and type: pp -o sampleprogram.exe samplefile.pl. After a minute or so, 'samplefile.exe' is compiled, and you can send it to your friend to run
Perl2Exe is a proprietary solution, and although it is good, is not free
Good luck!