In my experience, most software for OS X that installs cli components installs to /usr/local/ and then creates symbolic links to executables in /usr/local/bin/, as not to modify my $PATH. However, the Go installer differs in approach by creating a new entry in /etc/paths.d/ for path_helper to read and then modify my $PATH. Can someone please explain the thinking behind this design decision? Is it more common on Linux to have a lot of path additions instead of symbolic links to executables in an existing directory?
I'd love to get a better understanding of why this choice. I have never seen another software take this approach.
From this thread, the path_helper (source) is:
because automatic software installation (and what's more important UNinstallation) is much easier this way. Many Linux distros switch to .d directories for many configuration files (Apache 2.0 was AFAIK the first program to support this kind of stuff) because it makes administration much easier.
The Uninstall Go section does mention:
If you installed Go with the Mac OS X package then you should remove the /etc/paths.d/go file.
Those files in /etc/paths.d are processed in order (so you can manage PATH order as opposed to symlinks in /usr/local/bin).
Note that path_helper is only called by login shells, not by non-interactive shells.
Sorry for using an answer; I don't have enough reputation points to comment. ((which seems backwards to me))
#jsejksn says "I have never seen another software take this approach."
My /etc/paths.d contains entries for Xquartz, CrossPack-AVR, aria2c and go. From reading google'd articles about /etc/paths.d, I see that ImageMagik also adds an entry to /etc/paths.d.
I'd guess that it's an easy way to let users run binaries without having to mess around with amending the PATH in their own profile scripts, or lose track of symlinks, or whatever.
Maybe sym-links is more of a Gnu thing, while /etc/paths.d is more of a BSD thing?
Personally, I like it.
Related
This is a conceptual question and I hope it fits into Stackoverflow's question and answer style. I wonder what the concept of installing applications is good for. In my naive understanding of operating systems we do not need a registry and to use an application it should be enough to just copy the executable and files onto your drive and launch that.
Am a Windows user but also worked with Linux a bit and noticed that there are package managers instead of installers. But even those do more than just a copy instruction, I guess.
I do not think that all the installers exist only because the common user expects them out of steady habit. So what is the advantage of installers in contrast to developing applications which are designed to run out of a single folder and copy that over?
I would really like if someone could explain that concept.
Installing applications is a way to embed them in the OS. It's a kind of standard, you offer procedures like installing and uninstalling that should have the same functionalities for all applications (even "change" under Windows).
Countless times I've "installed" applications with a single shell script that came with them, and then had troubles removing such programs, having to look for single files. If the programmer uses the standard of the OS to make an executable that can be installed, that won't happen.
You can also easily view a list of the installed programs at any time.
Under Linux, additionally, if we're talking about a package manager, it is convenient for the user to have an easy way to download and install a program by just typing its name.
Last but not least, some applications are required to be installed and recognized by the OS (for example services in Windows).
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!
Why is it that some Mac Apps are perfectly happy to be simply copied into the /Applications folder, and others require installation-wizard software? Are there advantages to the wizards?
You may be interested in what Apple has to say on the subject. This is in Software Delivery Guide.
In particular, check out the two chapters Manual installs and Managed installs.
Some of the points in favor of package installers are:
support for custom installs
support for pre and post operations, such as quitting app and daemons before upgrading
In some cases it is necessary for an application to install support files in other locations; for example, some programs add libraries in "/usr/local/lib" or add binaries in "/usr/local/bin"; others need to install support files in "/Library/Frameworks" or in "/Library/Application Support". For those situations, using the *.pkg and *.mpkg installers is really the best solution available, since dragging and dropping the app won't cut it.
That said, if it is possible to simply drop your application into "/Applications", then distributing a ".dmg" file with your application in it and with instructions to drag-and-drop it to "/Applications" is a much better way of distributing your application than to rely on the "*.pkg" and "*.mpkg" installers. There are also some major downsides to using the *.pkg and *.mpkg installers... they can very easily clobber permissions and destroy important system files, so a drag-and-drop solution is much safer, simpler, and cleaner.
I've put together my very first package with PackageMaker (for a system service), but I am not happy about several faults:
Frequent crashes while applying target permissions to my source files
Package source files are not automatically or easily refreshed
File filter does not work
Is there something else out there more capable of this task? Free is not a requirement.
Yes it is, and yes it's buggy. Apple uses the command line version pretty much exclusively so the GUI tends to have the feeling that it's been slapped together by a summer intern and never tested.
PackageMaker is the standard, for things that need an installer (many regular applications just use a DMG, often with a background image telling the user to copy the bundle to /Applications - eg Firefox does this)
MindVision VISE is a commercial solution you can look at, used by some people, but personally I think the look & feel of the resulting installers is subtly wrong (and slightly retro) - that's a subjective viewpoint of course.
Package Maker works pretty well for many people - though documentation is rather scant; are you sure the problems you're experiencing aren't fixable?
There (now) is a great free alternative to PackageMaker with the simple name "Packages":
http://s.sudre.free.fr/Software/Packages/about.html
It's really easy to use, very stable and mature and even open source (in case you need to hack anything). Plus: it has a well written documentation!
I had the same problem until I added #!/bin/sh at the top of the script. Apparently PackageMaker needs it; I wish the log was a bit more clear about it.
IHIH, Oren
Since Mac OS X 10.6 Snow Leopard it is recommended to use pkgbuild and productbuild instead of PackageMaker.