I have a few installs—notably Node, MacVim, and Taskwarrior—which I installed through the installers available on their websites. Now, having begun to grasp the incredible handiness of Homebrew, I'd like to transfer these applications into brew apps.
I think I could safely uninstall Node, but I'm not sure where all the files live. Trickier yet, I have settings and data for MacVim and Taskwarrior, respectively, in my .vim, .vimrc, and .taskrc files. Is is safe to just move those somewhere, then drop them back into place once I've deleted MacVim and Taskwarrior and reinstalled them via brew?
It's just that everything works right now and I'm nervous that I'll mess it up. Also, if this is a question better posed at Super User (or another forum), feel free to let me know and I'll try to move it to the appropriate location.
Any help is appreciated. This is new stuff for me, but it's pretty exciting.
Do .vim and .vimrc exist in your home directory? If so, you can just leave them in place; Homebrew won't do anything to them and the new MacVim will pick them up automatically. If they are in /usr/local (which I doubt), you can move them and then move them back, I think.
(Note that if you are a Ruby user, you might need to make sure the version of Ruby in your PATH is 1.8.7; rvm system if you use RVM, or brew unlink if you have a later Ruby installed with Homebrew. I just built MacVim with 1.9.2 as my active Ruby, and it just sort of freezes when I launch it.)
I would assume .taskrc would work the same way if it's in your home directory, although I haven't used TaskWarrior.
Related
I have been trying to use GoClipse (0.8.1v2001409161333 - latest available from the goclipse_feature.feature.group) with Eclipse (4.4.2) on Linux (CentOS6.6) with GO (1.4.2-2.el6) installed via yum from EPEL and have only achieved partial functionality.
Intellisense appears to work fine for the built in packages but GoClipse appears to do something weird with it's directory structure that is different from the normal GO workspace layout. The existing structure under source control looks like:
$GOPATH/bin/...
$GOPATH/pkg/...
$GOPATH/src/externalsite/module/version/*.go
$GOPATH/src/externalsite/module/version/subdir/*.go
$GOPATH/src/me/module/*.go
$GOPATH/src/me/module/feature/*.go
When I try and use GoClipse it always appears to insist that the *.go files must be a peer of the bin|pkg|src directories. This means that I either have my *.go files at $GOPATH or tell GoClipse where main.go is ($GOPATH/src/me/module/main.go) and GoClipse creates the bin|pkg|src directories again:
$GOPATH/src/me/module/bin/
$GOPATH/src/me/module/pkg/
$GOPATH/src/me/module/src/
My GoClipse configuration has $GOPATH set appropriately (I have tried with $GOROOT undefined or set to the yum install location to no effect) and when creating the Go project from existing code specifying the location as $GOPATH/src/me/module/ (manually expanding $GOPATH)
Some resources that I have located do not appear to offer any advice on getting GoClipse to respect the proper go workspace structure and I am hoping someone can tell me how to do this.
The following resources might be of interest but they do not solve this difficulty:
How to run a GO project in eclipse with goclipse installed
https://github.com/GoClipse/goclipse
Indeed, goclipse.github.io/releases is the latest update site URL, so you should use the latest version (the URL did change several times since in the span of the previous year). The way Goclipse handles the Go enviroment has changed significantly since 0.8.0, particularly with 0.9.0, which allows creating an Eclipse project on a folder inside a GOPATH 'src' entry. (and other cases are handled better, especially with the builder).
Note: you will need to recreate your Eclipse Go projects after updating (0.10.0 had some internal, non backward-compatible changes).
You might want to consult the changelog for more details: https://github.com/GoClipse/goclipse/releases
For years I have been using MacTeX which installs in /usr/local/texlive, and have recently started using Homebrew to manage some packages (though not — yet — TeX). As a consequence of the adoption of Homebrew, I've changed the owner of all of /usr/local to Me:admin (from root:wheel).
Is this change of ownership safe? Is there a reason that texlive needs to be owned by root?
Normally usr/local is owned by root:wheel so that multiple usr's can access it, so by default everything installed to it is owned by root:wheel. Homebrew takes the rather unusual (but convenient) step of subverting this. It says, look this computer is just being used by one user, so I'll give her control of usr/local. It does this to
Make it more likely that all unixy installs will work for you
Make it safer (if there are any other users using the computer) - as a homebrew user, you'll only screw your own account up wiht homebrew if something goes wrong.
As you installed tex before homebrew it has root:wheel ownership, this has nothing to do with texlive, and everything to do with the normal usage of usr/local. If you change its permissions to Me::admin, then only you will be able to use texlive - I'd just leave it alone :)
Following an initial Trac installation on an Ubuntu 10.04 system, I was overwhelmed with the Plugins that were available.
Some theme installation was messing up my environments. So I removed my environments and tried to re-create them. But Trac still seemed to keep information on the installed environments and installed Plugins.
Even removing both installation and plugins didnt seem to work - doing a fulltext search over the whole
server didnt bring any results either.
Does anyone know where Trac stores the info on any created envinronment + plugins?
Trac will pickup plugins from Python's site-packages directory, as well as the environment's plugins directory. One possibility is that the plugins are installed in a site-packages directory, but regardless you should be able to disable them through the web administration page, or by editing the [components] section of trac.ini. Documentation is available on the TracPlugins page. Check if you have a GlobalConfiguration if someone else setup the initial Trac installation.
I'm preparing to update my Eclipse to 4.2 version and I'd like to solve one problem that has been annoying me since many many years. Right now my installation looks like this:
eclipse folder is located in /usr/local/share. This is a system-wide directory, yet Eclipse requires write permissions for a user, which goes against unix permissions philosophy.
I have a workspace and all plugins that I install go into .metadata folder within this workspace.
What I'd like to achieve is:
first of all, do not install plugins in the workspace directory. I'd like to see plugins installed either somewhere in my home directory or - if it is necessary for the user to have write permissions to eclipse directory - in eclipse directory itself.
take away users write permissions for eclipse directory. This will of course prevent installing plugins there, but I won't mind installing them somewhere in ~
preferable solution would be to take away write permissions for the user to eclipse directory and be able to install plugins within that directory as root. So when I want to add new plugin, I start Eclipse with root privileges, install the plugin (it goes to eclipse installation directory) and then I can use this plugin as non-privileged user.
Although I'm not a linux user, I'm 99% certain that plugins will never be installed into a workspace; that's just contrary to how workspaces and plugins are separated in Eclipse's architecture. A workspace may have configuration/cache data that is stored with file/folder names resembling plugin names, but the actual plugins are stored elsewhere.
I think if you read the multi-user install guide from the online help, you'll find one of the options outlined there will suit your needs.
Take a look at the shared install documentation for instructions on how to setup a base eclipse that a user doesn't have write access to and allow user-local install of plugins.
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fmulti_user_installs.html
I'm trying to update our installer so a user can simply double-click on a file and have all the dependencies and our software installed easily. This is a suite of applications that will are deployed on a clean Ubuntu 8.04 (Hardy Heron) installation. I have investigated making a .deb file, but listing the dependencies doesn't work, because there isn't any Internet access available. And, any script that would set up a local APT repository would still need to be run from the command line. Is there a way to put a .deb file inside of a .deb file?
I know many companies ship shell scripts that you have to chmod +x, and then execute. This is not acceptable. It is ridiculous that this isn't possible; especially considering the distribution and architecture is fixed.
If you are totally confident that it will be installed on the same system every time, you can find the list of package dependencies yourself, fetch them from the Ubuntu repositories, and package them up with your software. You just have to be clear that your software is for a specific version, probably deal with things like keeping up with maintenance releases.
You can also easily install with a script. As for your complaint about making scripts executable, well, I don't know how you're shipping your product, but since you say it's going somewhere without Internet access, I assume it's going to be copied from some kind of media. If you make the script executable when you put it on that media, you're done.
If you'd like to do this using packages, you can create a CD-ROM which contains a package repository. You can find all kinds of information on this with Google Search. For starters, try this - it's a GUI for doing it. http://aptoncd.sourceforge.net/
A makeself self-extracting executable that starts the install script using sudo will work.
The user can either run it from a terminal (after chmod-ing it) or can double-click it and tell it to "Run" from the prompt.
It's possible to put deb-files into deb-files. The only thing you need to do is to configure the appropriate scripts.
A .deb-file consists of:
1x control.tar.gz: contains a file "control" (describes the package) and optional files like "postinst" (script executed right after extraction). There are other files you might include, and Google Search should deliver information about the available scripts.
1x data.tar.gz: contains some structure of root-filesystem which contains files/folders that need to be (re-)placed. Additionally, you may configure the behaviour in the mentioned scripts.
1x debian-binary: as far as I remember, this is simply a version number in a file. I don't know exactly what it means; just remember that in most of the cases this is 2.0.
So you now may put your .deb files in the data-package. Those are extracted by your script... and installed using:
# dpkg -i yourpackage1.deb yourpackage2.deb