Background:
We are developing an in house use only cocoa app to help us with some basic sysadmin tasks and complex website deployments. This application is basically a wrapper around many different bash shell commands. The output from these commands will sometimes need to parsed or displayed to the user.
We have played around with NSTask and are able to launch some scripts. However, this seems somewhat cumbersome (needing to set the exact path, passing in each argument separately, etc...). We can use NSTask in this way if this is actually the preferred method.
The biggest challenge so far is setting up the shell environment. We interact with many ruby gems and programs and deploy using capistrano.
The Question is:
How can we interact with the shell with an environment setup like a user? (aliases, rvm, ruby, paths)
The environment variables you'll see set in your shell in Terminal.app are pretty much confined to whatever shell you're using in the Terminal context. It's not picked up by "NSTask" automagically.
But... you do have options. Some of them are described in answers to this related question.
You can set more universal environment variables that do get picked up by NSTask via the "~/.launchd.conf" file, or you can set the shell of "NSTask" to match the one in Terminal (which means you pick up .bashrc or .profile or whatever initializes paths) via "[NSTask setLaunchPath:]" (where the launch path is your shell).
And of course you can also call "system()" from within your tools. This may also pick up the variables set in the "~/.launchd.conf" file.
More information on environment variables is available in this question.
Related
In my home folder in Linux I have several config files that have "rc" as a file name extension:
$ ls -a ~/|pcregrep 'rc$'
.bashrc
.octaverc
.perltidyrc
.screenrc
.vimrc
What does the "rc" in these names mean?
It looks like one of the following:
run commands
resource control
run control
runtime configuration
Also I've found a citation:
The ‘rc’ suffix goes back to Unix's grandparent, CTSS. It had a command-script feature called "runcom". Early Unixes used ‘rc’ for the name of the operating system's boot script, as a tribute to CTSS runcom.
Runtime Configuration normally if it's in the config directory. I think of them as resource files. If you see rc in file name this could be version i.e. Release Candidate.
Edit: No, I take it back officially... "run commands"
[Unix: from runcom files on the CTSS system 1962-63, via the startup script /etc/rc]
Script file containing startup instructions for an application program (or an entire operating system), usually a text file containing commands of the sort that might have been invoked manually once the system was running but are to be executed automatically each time the system starts up.
Thus, it would seem that the "rc" part stands for "runcom", which I believe can be expanded to "run commands". In fact, this is exactly what the file contains, commands that bash should run.
Quoted from What does “rc” in .bashrc stand for?
I learnt something new! :)
In the context of Unix-like systems, the term rc stands for the phrase "run commands". It is used for any file that contains startup information for a command. It is believed to have originated somewhere in 1965 from a runcom facility from the MIT Compatible Time-Sharing System (CTSS).
Reference: https://en.wikipedia.org/wiki/Run_commands
In Unix world, RC stands for "Run Control".
http://www.catb.org/~esr/writings/taoup/html/ch10s03.html
To understand rc files, it helps to know that Ubuntu boots into several different runlevels. They are 0-6, 0 being "halt", 1 being "single-user", 2 being "multi-user"(the default runlevel), etc. This system has now been outdated by the Upstart and initd programs in most Linux Distros. It is still maintained for backwards compatibility.
Within the /etc directory are several folders labeled "rc0.d, rc1.d" etc, through rc6.d. These are the directories the kernel refers to to know which init scripts it should run for that runlevel. They are symbolic links to the system service scripts residing in the /etc/init.d directory.
In the context you are using it, it would appear that you are listing any files with rc in the name. The code in these files will set the way the services/tasks startup and run when initialized.
I have a c++ command line application that I have already compiled into an executable and have added it into my Xcode project. I have also added the "Copy Files" section to the Build Phases tab of the project properties and added my executable with the "Executables" destination. When I build my application I see it in the test.app/Contents/MacOS folder when I View package contents on the test.app that is built.
I also have App Sandbox enabled on the Capabilities tab of the project (so that I can distribute my application through the mac app store.
How can I expose this command line executable that is bundled with my application to the user so that they can run it from the command line (terminal)? I have not been able to find anything on search engines or on StackOverflow about how to get this file (or a symlink to this file) into the users PATH. I tried using an NSTask to create a symlink, but that only works if I disable the App Sandbox (which makes sense). Has anyone done this before? How did you get it to work? Or can these executables only be executed by code within your application?
I don't see a good way to do this. First, a clarification: the PATH is a list of directories that contain executables, not a list of executables; there's no way to add a single executable to the PATH. Instead, what you'd need to do is either put your executable into one of the directories in the user's PATH, or add the directory your executable is in into the PATH.
On OS X, the default PATH is /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin. The first 4 directories shouldn't be modified from the system default, so only /usr/local/bin is a possibility. But creating it (it doesn't exist by default) would require admin (actually root) rights, which isn't allowed by App Store policies. So that's out.
That leaves modifying the user's PATH. The "right" way to do that system-wide is by placing a file in /etc/paths.d, which requires admin (/root) rights, so that's out too. Technically modifying the /etc/paths file would work, but that has the same permissions problem plus it's the wrong way to do customization.
The next possibility is to modify (/create) the user's shell initialization script(s). This'll work, but doing it at all right is going to be messy, because there are several shells the user might use, each with several different possible initialization scripts that the user might or might not have created...
Let's take a very simple case: a user who only ever uses bash, and who doesn't already have any initialization scripts. When a "login" instance of bash starts, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile (in that order), and runs the first one it finds. But your app doesn't know which shell he uses, so you'd better create ~/.profile so zsh and ksh will use it as well. So, your app creates ~/.profile, and puts this in it:
PATH="$PATH:/Applications/MyApp.app/Contents/Helpers"
Great, right? Yup, great, until the user runs something else that wants to set their PATH, it creates ~/.bash_profile, and this overrides your setup. After that, your executable will be in the PATH of zsh and ksh, but not bash. Whee.
And then one day the user decides to use tcsh instead, and it (and csh) have a completely different but equally messy pile of possible init files...
I have a few clojure applications that load the sensitive info off of .properties file in /etc/ and this has worked well so far.
Recently, I have had to deal with a few windows machines added into our server collection and I need to run the clojure applications on there as well. Windows doesn't obviously have or understand /etc/ path and I got around that fact by looking at /etc/ and if that's missing then looking at d:\configs.
But I don't quite like this way of doing it, because, if there is another windows developer looking into it and he doesn't have d:\ or prefers elsewhere for configs it would get messy.
Is there any way I can load a file from clojure, no matter what operating system it is? My initial thoughts were of saving a key-path in the Environment variable and accessing it from clojure.
I am just wondering if there is a better way of doing it.
Thanks.
Have a look at environ. It offers some flexibility when it comes to configuring your Clojure app, letting you choose between a number of options:
environment variables: This seems to be the way to go in Clojureland, so I'd say your initial thought wasn't the worst;
in ~/.lein/profiles.clj: You can store them in the :user profile as Clojure data - that sounds quite nice, I guess;
Java CLI properties: Finally, you can pass them to the java executable directly via the command line.
environ will collect data from all these places.
I installed Ruby on Rails 3 using bash on OSX Lion.
When I wanted to use zsh and do a "rails -v" command I had "Rails is not currently installed on this system".
I just do not understand why. To me it's like "you can access all the files you want with bash not with zsh".
If I want to switch to zsh, will I have to install one more time Rails? delete the old one?
Is it secure and clever to use two shells when developing Rails applications?
What are your best practices?
Thanks in advance.
PS: I am new to programming and my installation is working fine. I even created one app.
EDIT: If you encounter the same problem I would encourage you to read the second answer first to get the rationale then the first one. Thanks to both of them.
While you are running bash, type at the command line echo $PATH.
Now start up your zsh command line, and type echo $PATH.
I bet the Rails path is not included in your zsh, right?
Look in your $HOME dir for .bash* files. See which one has the Rails PATH added.
Find your zsh .* env files and copy/paste the line you found above into the approriate file.
When I say .bash* and .* files, I mean hidden files in your home dir that you'll only find by doing ls -la. If you find a .profile file, that would be a good place to insert this.
I hope this helps.
P.S. as you appear to be a new user, if you get an answer that helps you please remember to mark it as accepted, and/or give it a + (or -) as a useful answer.
I just do not understand why. To me it's like "you can access all the
files you want with bash not with zsh".
As shellter said, you must have directories added to your path in order to run commands from the command line. For more information on PATHs take a look at the Intro to Linux guide. I know you are not using Linux but that section (and lots of others) is very much applicable.
If I want to switch to zsh, will I have to install one more time
Rails? delete the old one?
No, see note on paths above and take a look at the guide.
Is it secure and clever to use two shells when developing Rails
applications? What are your best practices?
It's not really something special to use two shells at once. It depends what you do in each. I often have 6 and 7 shells open, not all for the same thing. That is really up to you and how you work. The number of shells you use is more of a workflow thing than a "best-practices" issue.
I normally have 3 shells open when I do RoR work. One running autotest in the background, one running rails -server, and one where I actually edit files and run emacs. But again, this is not best practice as it is workflow. Do whatever makes you effective.
The only trouble you could get into occasionally running two shells is say, for example, you open a file in one and delete it in another. However, when you do this it is typically very obvious.
PS: I am new to programming and my installation is working fine. I
even created one app.
For Rails, I found this tutorial very helpful.
Also, you said you were new to programming. I don't know if this is the case, but I would suggest starting with basic Ruby, before jumping into Perl. Although the tutorial I linked above covers Rails-flavored Ruby.
Can I have the binary files like .sh as part of the .app in "Package Contents".
I basically have .app which has 2 buttons start/stop which basically kicks off a process to start the server. To keep everything clean, I would like to store the start/stop shell scripts within the .app.
Can I execute those shell scripts from .app?
On the Mac, yes: use the NSTask class’s +launchedTaskWithLaunchPath:arguments: method (for example), after retrieving the path to the binaries with one of the methods on NSBundle’s—-resourcePath, -bundlePath, -pathForResource:ofType:, or whatever.
On iOS... no. NSTask isn’t available.
Yes. You'll want to look at NSTask to run your scripts or other binaries, and find the files using NSBundle's API.