I am working with bash and still unfamiliar with the difference between .profile, .bashrc, .bash_profile.
My desired result is to have the ruby version and rvm gemset show up on my bash prompt.
I added PS1="\$(~/.rvm/bin/rvm-prompt) $PS1" to .bash_profile (via xcode) and it displays
ruby-1.9.3-p286 John-MacBook-Air:~ john$
What I trying to get is
ruby-1.9.3-p286#rails3 $
With "rails3" being the output of rvm gemset.
How do I get John-MacBook-Air:~ john removed from the prompt?
I tried adding the line in the .profile, and .bashrc with no luck but it seems to work in the .bash_profile. Any clarification between these files would be greatly appreciated. I am running rvm on a Mac.
SOLUTION
include the following to the .bash_profile
PS1='\W \$ '
PS1="\$(~/.rvm/bin/rvm-prompt) $PS1"
the prompt looks like
ruby-1.9.3-p286#rails3 ~ $
This line is the problem:
PS1="\$(~/.rvm/bin/rvm-prompt) $PS1"
What you're saying there is "add my rvm prompt to PS1" and then put the pre-existing PS1 at the end. The system's default PS1 is setting this:
PS1='\h:\W \u\$ '
In that setting \h is the hostname (here 'John-MacBook-Air'), \W is the current working directory with your home directory abbreviated to ~, \u is your user's login name (here 'john') and \$ will show a dollar sign if you are a regular user and an octothorpe (#) if you're logged in as root. On OSX, that is set by default in /etc/bashrc. If you want to change the prompt, you need to customize the latter part of the prompt rather than just re-entering $PS1 as is back into the new setting. Removing the hostname is common, but I would very strongly recommend against removing the current working directory. It's very useful information when in a terminal session. Just my two cents.
To see what you can put there, take a look for information about setting your prompt in Bash.
I am working with bash and still unfamiliar with the difference between .profile, .bashrc, .bash_profile.
That depends on your system configuration. Read the manpage for that. You can also change the behaviour either system- or userwide by including one from the other.
Here are few notes to understand better.
Per-login initialization. (or: session startup) There are startup files which are only executed for login shells. On my system, they only set environment variables. (That makes sense, because environment variables are inherited).
Those may be called /etc/profile or ~/.profile for plain sh. If bash is your shell and you have ~/.bash_profile or ~/.bash_login, it will prefer those (in this order) instead by default.
Note that changes to session startup files have no effect until you login next time. Also, you need to make sure to export variables to the environment like PS1=something ; export PS1.
Per-process initialization. For Plain sh, there is no default per-process initialization file, but you can set the ENV environment variable to point to one. For bash, there is also the BASH_ENV variable, and the ~/.bashrc file. The per-process initialization file is the place where you can store per-process shell settings (those who can't be inherited through the environment), e.g. aliases or function definitions.
If you just want to see if a particular file is executed, you can always echo something, or touch some file like echo TEST or touch /tmp/test.
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 am wanting to program Minecraft mods using forge. I am going through the standard installation to begin creating mods, but I have run into an issue. I ran the code "gradlew setupDecompWorkspace eclipse" and it is telling me "ERROR: JAVA_HOME is not set and no 'java' command could be found in your PATH. Please set the JAVA_Home vairable in your environment to match the location of your Java installation." Is it possible to change something else or do something else that will allow me to program? I also cant change the environment variables.
You can change environment variables, even without being an administrator.
The easiest solution is to use set to temporarily change the environment variable for only your session (IE, it'll get reset when you close your command prompt):
set JAVA_HOME=C:\Program Files\Java\jdk1.8.0_91
gradlew setupDecompWorkspace eclipse
Obviously, you'd change the location given to a different one if you have the JDK in a different location.
If you want to change it more permanently, you can use the setx command. Setx keeps the changes you made between sessions (and, more importantly, you don't need to be an administrator, since changes are only made to your account). Note that running setx doesn't apply the changes to the current command prompt window, only future ones; you'd need to close and reopen command prompt after setting the path.
Run
setx JAVA_HOME "C:\Program Files\Java\jdk1.8.0_91"
and then close and reopen your command prompt, and it should keep the path set. (Note that again, you'd want to use the path for your java installation; also it needs to be surrounded by quotes here).
If you don't want to run set each time, you can probably edit gradlew.bat and put the same set command at the top of it.
Simply open gradlew.bat with a text editor and then put
set JAVA_HOME=C:\Program Files\Java\jdk1.8.0_91
at the top of it (again, replace the path with the correct one for your version).
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 am getting started with Meteorjs. I'm a windows user so I downloaded the windows installer package Release 0.7.0.1-win2. I use gitbash for my command line interface and can't get it to recognize meteor. I get the error "sh.exe": meteor: command not found". It works fine in windows command line but I prefer gitbash.
How do I get meteor to work with gitbash?
I have the perfect answer for you since I literally just solved the issue myself.
First of all make sure meteor works in the default windows command prompt. Next open git bash and check if the following command works:
cmd //c meteor
This runs the command meteor as if you were in the command prompt.
Next step is to set up an alias in git bash so you don't have to type that out each time.
Open git bash and enter the following:
vim ~/.bashrc
this will open/create the bashrc file in VIM, press i to insert and type the following:
alias meteor="cmd //c meteor"
Save and exit vim by first pressing the Esc key then press the ":" key. Now you should be able to enter commands in VIM. Type "wq" and press enter which will write into your .bashrc file and exit vim.
Almost there! Now that you are back in git bash, all you need to do is point to your .bashrc file by entering the following:
source ~/.bashrc
Now you will be able to run meteor commands straight from git bash! Hope that helped!
Here's the fix:
The problem is because of .bat files not being handled properly by
MinGW
Go to this directory - C:\Users[your username]\AppData\Local\.meteor
You should see a meteor.bat file there. Create a new file called "meteor" (without any extension and ""). Open it with notepad and paste the following:
#!/bin/sh
cmd //c "$0.bat" "$#"
save the file and now run git bash. You should be able to use meteor command in git bash.
Details
To run a *.bat command from MinGW's MSYS shell, you must redirect the execution to cmd.exe, thus:
cmd //c foo.bat [args ...]
The foo.bat command file must be in a directory within $PATH, (or you must specify the full path name ... using slashes, not backslashes unless you use two of them for each path name separator). Also, note the double slash to inform cmd.exe that you are using its /C option, (since it doesn't accept the -c form preferred by the MSYS shell.
If you'd like to make the foo.bat file directly executable from the MSYS shell, you may create a two line Bourne shell wrapper script called simply foo alongside it, (in the same directory as foo.bat), thus:
#!/bin/sh
cmd //c "$0.bat" "$#"
(so in your case, you'd create script file meteor alongside meteor.bat).
In fact, since this wrapper script is entirely generic, provided your file system supports hard file links, (as NTFS does for files on one single disk partition), you may create one wrapper script, and link it to as many command file names as you have *.bat files you'd like to invoke in this manner; (hint: use the MSYS ln command to link the files).
Credits to: Keith Marshall on SO and rakibul on Meteor Forums
It shouldn't be too hard - you just need to make sure that the meteor.bat file is in your executable. Check with echo $PATH from the bash console if it is already there.
For me, the meteor 0.7.0.1-win installer appended meteor's folder to the path automatically. However, you can add it manually with:
export PATH=$PATH:/path/to/user/folder/AppData/Local/.meteor
(On CygWin my user folder is at /cygdrive/c/Users/adam - I'm not sure what the equivalent path would be on git bash).
If you like, append that line to your ~/.profile to make sure meteor gets added to the path when the console opens.
Finally, on Windows the executable file is meteor.bat. I made a symbolic link to the filename meteor, just so I wouldn't have to type the .bat:
cd /path/to/user/folder/AppData/Local/.meteor
ln -s meteor.bat meteor.
Please have a look at the issue https://github.com/sdarnell/meteor/issues/18
I would suggest maybe creating a trivial wrapper script or alias that invokes LaunchMeteor.exe with the original arguments.
After more research on google I see that there isn't an implemented way to do this yet. The guys at meteor are working on it and accepting pull requests if you have a solution. The conclusion I came to is to use Vagrant and virtualbox to set up a ubuntu vm for meteor development. You can find info at this site: http://win.meteor.com/ on how to install virtual machines and provision to work with meteor.
I'm trying to write a .screenrc file that I can use to set up for a developing on a particular project - It will start a few screens, cd to the right places, open up the right files in an editor, and set some environment variables needed for testing.
I can't get the environment setup to work.. I've tried putting this in `~/.screenrc:
setenv PATH ~/src/my_proj/bin/:$PATH
This doesn't work, and I think the problem is that after screen sets PATH, the regular shell initialization scripts kick in and change it on me.
I don't want to disable the regular shell init scripts. Is there any way to make screen setenv after the shell is initialized? Or alternatively, can screen set a variable to read-only?
I'd do it with some bash magic instead. Try adding something like this to your ~/.screenrc file:
screen -t "window" bash -ic 'PATH=~/src/my_proj/bin/:$PATH bash'
For more details and to have this set for newly created windows using Ctrl-a Ctrl+c or Ctrl-a c see my answer to a different post: https://stackoverflow.com/a/21717641/1413849
for me the line
setenv PATH /home/someuser/bin:$PATH
in the screenrc file did the trick.
I think the expansion of '~' to '/home/someuser' is bash specific and will not work within the screenrc.
There's no way that screen can change the environment variables of a shell process once that process has launched, nor is there any way to make an environment variable read-only (values are stored in each process's memory, and each process has full access to them).
(Well, there might be some ugly system-specific way to do it, but it's the kind of thing Unix-like systems are designed to keep you from doing.)
You'll need to modify your shell's initialization script so that it retains the existing value of $PATH, possibly adding to it, rather than setting it to some new value ignoring its existing value.
If you want to do this conditionally, you can test for the existence of $STY, which is set only if the shell (or any other process) is running under screen.
Also, screen's setenv command doesn't seem to recognize the ~ character. I tried adding a similar setenv to a temporary screenrc, and $PATH contained a literal ~ character. bash seems to recognize the ~ syntax in $PATH, but other shells do not. Replace the ~ by $HOME, which screen does recognize.
For me, I just set environment in ~/.bash_profile or ~/.bashrc
case $TERM in
screen*)
export PS1='[\u:screen \w]\$ '
;;
*)
export PS1='[\u \w]\$ '
;;
esac
It worked, enjoy it.