I was reading a blog post about installing git, and it says it will be installed in /usr/bin/git
When I check my version using $ which git, terminal shows /usr/local/bin/git. Same result when I checked for Ruby. Does it make different where Git, Ruby or Rails are installed? Can I change that if it's possible?
Normally, it should not matter. But, usually, /usr/local/bin is ahead of /usr/bin in the PATH environment variable. So, in future, if another version of the same software, lets say git, is installed into /usr/local/bin, that will take precedence over the one installed in /usr/bin. You can of course manipulate your PATH environment variable to suite your needs.
run this command to see if multiple versions of git have been installed
which -a git
It does not matter as long as all of them are accessible in your PATH for commands.
Is your concern about where the actual repositories will be located - the place where GIT repositories are located is not necessarily the same place where GIT itself is installed.
You probably could change it. It might not be worth it.
It will probably be easier just to leave it and remember.
This is sorta like windows install path. Default will be "Program Files" but it often can be changed.
Note that different versions of Windows have differently named program files. This can be an example of such differences also.
Finally it could be that your ruby installed GIT, and that is the path that Ruby chose.
As long as /usr/local/bin/git is in your PATH you should not notice any differences.
Related
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).
We are creating a new installer and want a tool to compare the new installation with the old installation. Is there a tool to do a snapshot comparison with a list of differences?
Could you be more specific about what installation do you mean? If the differences are on file-level, you may use simply diff command with -r option (if you are on NIX system). You may also run for example rsync -nav --delete to see the differences. It really depends on your environment.
i have a directory with some .php files in it...do i need to install symfony in that directory so that i can run symfony commands from that directory?? i tried: pear channel-discover pear.symfony-project.com
and got:
Channel "pear.symfony-project.com" is already initialized
the i tried: pear install symfony/symfony
and got:
WARNING: configuration download directory "/build/buildd/php5-5.3.2/pear-build-download" is not writeable. Change download_dir config variable to a writeable dir to avoid this warning
Cannot install, php_dir for channel "pear.symfony-project.com" is not writeable by the current user
how do i fix this please? must i run it as sudo??
thanks
If I remember well, Symfony is "system-wide" if installed through PEAR (like you are trying to do).
Now it is recommended by the manual to do a "standalone" install through SVN. See http://www.symfony-project.org/gentle-introduction/1_4/en/03-Running-Symfony
As well, the sandbox will bring a "standalone" installation of Symfony (you will have to be in the project root directory to be able to run the symfony commands)
EDIT
Example of quick install using SVN:
mkdir /path/to/symfony
cd /path/to/symfony
svn checkout http://svn.symfony-project.com/tags/RELEASE_1_4_0 .
but it should be better to follow the manual and configure the external SVN sources.
I run servers where I have applications that use different versions of symfony simultaneously. I found it much easier to deal with the SVN checkout than the PEAR insteall.
So what I've done is do an SVN checkout of each revision that I need
into it's own folder. In my case i check them out to
/usr/share/symfony/(version)
Then I configure the ProjectConfiguration.class.php to reference whatever version is needed, using the line:
require_once '/usr/share/symfony/1.x.x/lib/autoload/sfCoreAutoload.class.php';
If I need to switch to a different symfony version, I can just change that config.
That is, assuming all my code is compatible with that version
I mainly do ruby on rails development on my machine but from time to time I end up using other laptops for RoR development. It would be nice if there was something (maybe shell?) which basically bring all the gems installed on my machine to some other machine without leaving any footprints. It's basically a really light VM without the OS stuff.
If it matters, I'm using a mac. Ideally I would like to keep that virtual environment in my dropbox and basically when I use some other machine, I would just get it from my dropbox and start coding and not have to worry about setting up the environment.
Similar to Jacob's answer, I'd recommend using RVM, but I'll expand on it. Here's some brainstorming ideas:
RVM stores its sandbox in your home directory at ~/.rvm. All Ruby instances, plus the associated gems will be stored there. It's a simple addition to the ~/.bashrc file in your Mac to initialize RVM so it's known by the shell when you log into the account. It's also a simple rm -rf ~/.rvm from the commandline to remove the RVM sandbox from the account, followed by removing the line from the ~/.bashrc.
So, basically, by setting up RVM correctly and installing your Ruby installation on one machine, you're 90% of the way to having it available for multiple machines.
I'm pretty sure Ruby will install without any dependencies on a current Mac OS using RVM, but there's a couple libraries that can improve the experience. After installing RVM, but before installing any Rubies, run rvm notes. That will show you what else to install. You'll need the current XCode to compile a Ruby, but only on the machine you do the compiling on. Once it's installed you should be able to move a RVM controlled Ruby around to other Macs by copying the ~/.rvm directory. So, not only would you have the gems, you could have a particular version, or versions, of Ruby, plus the associated gems, so your regression tests could work too.
If you use MacVim you could install it in ~/bin and have the GUI version. I haven't tried running it from there, but it seems like it'd work. You might need to create an alias from /Applications to the one in ~/bin for double-clicking.
MacVim comes with a shell script called mvim to launch it from the command-line. I have a bunch of softlinks to mine letting me call it from the command-line in various ways: gvim, and the gvim varients like gvimdiff and gview. You could do the same by adding ~/bin to your PATH and making the links locally in that dir to MacVim's mvim.
You could build a tarball of the vim config, vim installation and RVM sandbox, copy that to another Mac, expand it, add ~/bin to your PATH and append the needed RVM initialization line in ~/.bashrc, open a new command-line, and have your editor plus Ruby sandboxes.
It's a minor variation on how my Mac and Linux boxes are set up. I haven't tried bundling everything together, but, on Macs that are the same OS version, it should work.
Consider using rvm to manage different gem configurations. If you want you can store your rvm configurations in your dropbox (rather than in ~/.rvm, where they go by default) so that your gemsets are synced across machines.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
First a bit of background.
I have been working on the MS platform for my entire development career. Up until 2 weeks ago, I had never booted any other OS than 98/XP/Vista. I started using VSS long long ago, and made the change to SVN about 2 years ago. With SVN I use TortiseSVN and use the standard branch/tag/trunk setup.
My projects are also self contained, meaning I can go to a fresh dev box, pull down a single repository, open VS, press F5 and it will run (most of the time). All dependencies are stored in a lib folder, source code is in a src folder, etc...
In an effort to learn new things, I've decided to build a Ruby on Rails application and have created a Ubuntu based development machine. I have a SVN server up and running and am working with another person on this project. He happens to be using a Mac for his development machine.
And now for the issues.
I seem to be struggling with how to manage the various versions of ruby, rails and all of the plugin's I'm working with. I also seem to be struggling with using SVN on Ubuntu.
So Ubuntu comes with Ruby pre-installed. I want to say it's version 1.8.5. Either way, I had a bunch of gems to install for the plugin I'm using (Community Engine). Being new to *nix, I didn't use sudo when installing them and ran into all sorts of issues. I ended up blowing away Ruby completely and starting fresh. That seemed to work.
The problem is though, that after I commit my code, and the other guy gets latest, he has to go through the whole process of installing gems.
What is the best practice for managing gems and plug-ins in a RoR application? I don't care if a zillion files get added to SVN. Diskspace and network bandwidth are cheap. I just don't know how to do this correctly.
So on to SVN.
I have installed RapidSVN, but very frequently run into issues with folders getting locked. A couple times I realized my mistake, others, I had no clue why. But in both scenarios, i couldn't fix it. I ended up making a backup of my code, pulling down a new working copy, then manually moving over changes and being a bit smarter when committing them to the project.
I actually RTFM a bit last night and found that I'm supposed to create a bookmark for my repos, then do a "checkout working copy" from that bookmark. I'm not sure why, but ok, that's what the manual says...
What are some best practices for using SVN on a RoR project on Ubuntu?
I'm literally looking for a step by step process on this one.
edit
I forgot to mention, I use NetBeans for my IDE, although i have not looked to see what kind of SVN support it has, if any. I looked at RubyMine, and would love to use it, but it appears to be too unstable right now.
For plugins, I'd personally recommend just sticking them in the vendor folder and add them to SVN as if you'd written the code yourself. Piston was also a great solution, but switched away from it when all the common plugins started moving to github (piston has been unreliable since then)
For gems, hopefully you're using rails 2 or higher. You should be listing the gems you require in your config/environment.rb using config.gem. Here's a bunch of information about that feature
What this means is that if you add a new gem, the next time your co-worker updates, his rails app won't boot until he's got the neccessary gems. He can then install them in one step using sudo rake gems:install
You can take this one step further, and put your gems in the vendor directory. This is commonly known as "vendor everything." The easiest way to do this is to list all the gems you use in environment.rb as above, and then run rake gems:unpack. There are 2 problems with this approach however, so I prefer not to use it myself.
If you have 10 apps and they each vendor their gems, you end up keeping 10 copies of common gems in subversion, which makes updating all your sites a whole lot slower.
This may not be an issue for you, or may be worth putting up with, it's just a personal preference.
Some gems (such as mongrel or hpricot) have native extensions written in C. What this means is that when you install them, the .c source code is downloaded, and gcc gets run to compile it specifically for your system.
If you installed a native C extension on ubuntu, then put it in the vendor folder, and later on tried to run that on OS X (or even possibly a different version of ubuntu) it would most likely crash your ruby process and bring your app down.
If all your gems are pure-ruby ones, then this is not a problem, but it's just something to be aware of.
Many people use piston or desert to manage plugins and install gems into Rail local vendor folder (stored under SVN).
http://www.rubyinside.com/advent2006/12-piston.html
http://pivotallabs.com/users/brian/blog/articles/459-build-your-own-rails-plugin-platform-with-desert
I also recommend using geminstaller which will help you both install all the same gems and the same versions of them
http://geminstaller.rubyforge.org/
I use SVN from the command line but if you were more comfortable with TortiseSVN you might want to try IDEs that have SVN nicely integrated like RadRails and NetBeans. The IDEs have very similar graphical SVN managers similar to Tortise, if you want to work on the cmd line just find a simple 10 minute SVN tutorial and you should be good to go.
I have never heard of rapid SVN and the normal SVN tool has always worked just find with me, hardly ever causing the locking folders issue.
Orion mentioned having to rebuild gems that have been vendored when sharing them between different OS's - you can use the gems:build rake task to rebuild them automatically.
First, figure out svn from the command line. The svn-book is on line. It's not too hard to do svn status or svn commit -m "blah". Most problems come if you use OS functions to delete or rename files. Use the svn commands for that.
Next, if rapidsvn is not working out for you, try svn-workbench. Hate to say it, but none of the linux svn GUI tools that I have seen are as good as tortoisesvn.
Plugins and svn are an issue. There is a tool called piston that aims to clear that up, though I don't use it. I check out the plugins into my vendor/plugins directory. If a new version comes out that I really want, I use my trusty update_plugin bash script to update the plugin:
#!/bin/bash
# reinstall the plugin in an svn friendly way
plugin="some_plugin"
plugin_url="http://some_server/some_plugin/trunk"
for f in site1 site2 site3
do
echo $f
cd ~/rails/$f
svn delete vendor/plugins/$plugin
rm -rf vendor/plugins/$plugin
svn -m "remove $plugin" commit
script/plugin install $plugin_url
svn add vendor/plugins/$plugin
svn -m "add $plugin" commit
done