I have recently set up Vagrant on my machine, and the first thing I noticed was that my terminal config was not synced, when I sshed into my server.
For instance I have changed my shell from bash to zsh, which does a lot of beautiful things for me (like removing case-sensitive auto completion). But on my vagrant virtual machine, or on my server, all this cool stuff is now gone. Also stuff like my important aliases is not synced.
Now, what is a proper way to sync stuff like this?
EDIT:
So currently, when I create/remove/edit an alias on my local machine, I have to copy the exact same changes into my VM and all other servers I frequently use. I see this as a very time consuming and unnecessary task.
What I do is version control my dotfiles and I keep them on github. Dotfiles are just the files in your root that start with a dot in the name such as .bashrc or .zshrc. They are "invisible" files, so you have to use ls -a instead of just ls to see them.
Here are my dotfiles: https://github.com/aharris88/dotfiles
When I get on a new machine, I just clone the repository to ~/dotfiles
Then, I have a bash script in there called setup.sh that backs up any old dotfiles that might already be in root into ~/dotfiles_old. Then it creates symlinks to the files that are in ~/dotfiles.
It also installs zsh and oh-my-zsh if it isn't already. It should work for linux or mac os x.
Here is an article describing how to version control your dotfiles: http://blog.smalleycreative.com/tutorials/using-git-and-github-to-manage-your-dotfiles/
Another thing that I do to get a new mac ready is use kitchenplan: https://github.com/kitchenplan/kitchenplan, which can sync a lot more settings, but this probably isn't what you're asking about. Here is my kitchenplan config: https://github.com/aharris88/kitchenplan-config
Related
So, I had an SSD failure last night and have been reinstalling my coding environment again today but have encountered a strange issue: whenever I clone my repos now they're being assigned 700 permissions for every file and folder, which breaks several things in vagrant/puppet/npm/apache, and more specifically it ignores the ACL settings when using rsync to synchronize the files to a virtual machine, leaving them with the same permissions on the host.
I tried manually updating the permissions on all the files, and that worked for most things, but broke something in NPM we need to build our javascript and css, and likewise adding --chmod=ugo=rwX to rsync fixes the permissions sort of, but leaves NPM failing, which worked with the permissions still broken.
After fighting with that for a while I discovered something that appears to be new:
Even with permissions set to 755 (or whatever) on the parent directory, every cloned file under C:\Users\James\ just always defaults to 700. I had previously had my development environment set up in the exact same place without issues, so fairly sure this is something relatively new, but cloning the repos into C:\Code\ or any other location that's not under C:\Users\ creates the files with the expected permissions, and everything works again.
So I guess the moral of the story is: don't clone git repos under the Users directory, unless you want Windows to break all your file permissions.
Recently while at work we were given an older version of ubuntu (12.04) to work with on a vagrant machine.
I wanted to migrate over to fish or zsh due to them being way better then default bash but I'm encountering a weird error where if I navigate to the /vagrant folder (shared onto the local machine as well) every command I run stalls for 5-10 seconds. Outside of the folder it does fine and has no stalling problems.
Has anyone encountered this before or have any ideas on why this could be happening?
Probably some stat or something taking too long to finish. I will suggest to run strace on bash (if you have patient for that :) ).
Such stat can be for example called from your PROMPT, it's common to have there CWD.
I will suggest to not run commands from there if not necessary. You can call commands outside and provide path to there.
Ofcourse you can play with sharing, there is probably some weak point.
I have a repo that has two branches, which i would like to work on simultaneously.
After some reading I found git has a script git-new-workdir.
Im trying run use the script from the git for windows bash but get the following error.
$ git-new-workdir
sh: git-new-workdir: command not found
How do I use this script on windows?
Due to some of the commands in the git-new-workdir functions not existing on windows, the script won't work.
I have found this windows port of the script. Works great for me.
https://github.com/joero74/git-new-workdir
Git 2.5 (Q2 2015) will replace contrib/workdir/git-new-workdir with an official native Git command which works on any OS (including Windows).
The release notes mentions:
does not rely on symbolic links and make sharing of objects and refs safer by making the borrowee and borrowers aware of each other.
That is because the multiple working trees are "linked", or actually recorded in the main repo new $GIT_DIR/worktrees folder.
See "Multiple working directories with Git?" for more.
On my installation, the script file is located in /usr/share/git/contrib/workdir/git-new-workdir.
Perhaps if it's not installed in that version of git, you can just download its raw form and run it with bash /path/to/git-new-workdir. At your preference you can also install it in /usr/local/bin changing permissions when necessary.
I'm having trouble getting post-recieve and post-commit hooks to work correctly with msysgit (Windows 7 Pro/32 and Ultimate/64). For post-commit hook I get the above error if I commit from either git-bash or the console, but it works fine if I commit through git-gui. For a post-recieve hook, all three give the same error.
I'm thinking this is some sort of permission or path error, but don't really have any clue where to start here.
Add the SHEBANG to the first line of hook, like so:
#!/bin/sh
echo "executing post-commit"
exit 0
This had me stumped for a while as well and I saw that adding the shebang fixed it. In SVN world, while in *nix we have a "pre-commit" script and in Windows we had "pre-commit.bat" and SVN automatically picked up the bat file in Windows. Git doesn't seem to pick up a pre-commit.bat ( or any hook ) and adding the shebang to the hook file worked.
I'm using SourceTree and git LFS and had a similar issue: cannot spawn .git/hooks/pre-push.
The fix was to delete the pre-push file (opening it revealed it was badly corrupted) and restart SourceTree at which point it regenerates the pre-push file and everything is back to normal.
If you have the SHEBANG and it still fails, make sure you have <path_to_git>\bin set in your path environment variable.
You'll probably also have <path_to_git>\cmd if you installed it to work from the command-line.
This is an old question, but I've been fighting with this exact problem and this SO question popped up, so I thought it worth the effort to record what worked for me.
In short: I needed to run Apache as a regular user instead of Local System. This was on a legacy test VM I was playing with, so it was only running Windows XP, but it appears that at least on that platform (and possibly others), msysgit just doesn't work properly when running under the Local System account (presumably the root filesystem isn't mapped properly). As a result, no shebang line will work as git-http-backend simply can't execute any msysgit binaries (even with absolute Windows paths).
Switching Apache to run as a regular user account fixed this problem completely. Obviously you need to ensure that the user Apache is running as has permissions to read/write the git repositories, but beyond that, just make sure your shebang line is #!/bin/sh and everything should be copacetic.
Lastly, yeah, this is a big hammer. Ideally you'd be able to use something like suexec on Windows, but a quick googling doesn't indicate an obvious path forward, there. Of course, if anyone has any ideas, I'd be interested.
For now, this works for me, but it doesn't seem ideal.
Got this in a repo using LFS, got rid of it with git lfs update --force
If someone, like me run into a similar problem with accessing git repositories through apache, you should set the PATH in Apache config, like:
SetEnv PATH "c:/Program Files (x86)/Git/bin;"
Using tortoisegit and LFS, for me just had to remove the files inside of the .git/hooks folder.
If you are using Android studio, you can remove this error by un-check the checkbox "Run Git hooks":
For me, removing a comment line on front of the shebang line fixed the error. Oddly, the script ran fine from the shell, just errored out when run as a hook.
I've got a Mac that I can run either the Leopard (10.5) or Snow Leopard (10.6) version of OS X on. I'm using it to do web development/testing before publishing files to my production host.
On the production host my site's doc root is under the home directory (e.g. /home/stimulatingpixels/public_html) and I'd like to duplicate that location on the Mac. Unfortunately, their is a hidden and lock placeholder on the Mac that looks like a mounted drive with nothing in it sitting in the /home location.
I know from experience that it's unwise to move this and drop in your own /home directory because upgrades can cause it to be erased (and it doesn't get stored in the TimeMachine backup, by the way).
So, the question, is there anyway to safely use /home on a Mac either Leopard or Snow Leopard?
(Note: I realize this is very Mac specific and will be asking it in an Apple forum as well. Just wanted to ask here in addition to cover all the bases.)
Update: To help describe why I want to do this, in addition to the front end web site, I've got a series of scripts that I'd like to run as well. One of the main goals with being able to use the /home directory (and more specifically the same path from the servers root) is so that can use the same output paths on the development mac as well be used on the production server. I know there are ways to work around this, but I'd rather not have to deal with it. The real goal is to have all the files on the development Mac have the same filepath from the / root of the directory tree as the production server.
Another Update: The other reason that I forgot to mention earlier for this is setting up .htaccess paths when using basic authentication. Since those paths are from the file system root instead of the website docroot, they end up going through "/home" when that's part of the tree.
NOTE: As of 2015, I no longer use or recommend this method. Instead I use Vagrant to setup virtual machines for dev and testing. It's free, relatively easy, and allows better matching of the production environment. It completely separates the development environment and you can make as many as you need. Highly recommended. I'm leaving the original answer below for posterity's sake.
I found an answer here on the Apple forums.
In order to reclaim the /home directory, edit the /etc/auto_master file and comment out (or remove) the line with /home in it. You'll need to reboot after this for the change to take effect (or, per nilbus' comment, try running sudo automount -vc). This works with Mac OS X 10.5 (Leopard). Your millage may vary for different versions, but it should be similar.
As noted on that forum post, you should also be aware that Time Machine automatically excludes the /home directory and does not back it up.
One note of warning, make sure to back up your /home directory manually before doing a system update. I believe one of the updates I did (from 10.6 to 10.7 for example) wiped out what I has stored in /home without warning. I'm not 100% sure that's what happened, but it's something to be on the lookout for.
Putting it all together from the tips and hints above:
edit /etc/auto_master # comment out the line with /home in it.
remount:
sudo automount -vc
make a softlink to the mac-ified dir:
sudo ln -s $HOME /home/$USER
At that point, your paths should match-up to your production paths. env vars will still point to /Users/xxxx, but anything you hard-code in a path in your .bashrc --or say, in ~/.pip/pip.conf-- should be essentially equivalent. Worked for me.
re: "The real goal is to have all the files on the development Mac have the same filepath from the / root of the directory tree as the production server."
On production, my deploy work might happen in /opt/projects/projname, so I'll just make sure my account can write into /opt/projects and go from there. I'd start by doing something like this:
sudo mkdir /opt/projects
sudo chown $USER /opt/projects
mkdir /opt/projects/projname
cd /opt/projects/projname
With LVM, I'll set a separate partition for /opt/, and write app data there instead of $HOME. Then, I can grow the /opt file system in cases where I need more disk space for a project (LVM is your friend.)
I tried it on Yosemite (OS X 10.10.1) the sudo automount -vc didn't work, I had to use sudo umount /home.
Therefore my workflow would be:
# comment out line starting with /home
sudo vi "+g/^\/home/s/\//#\//" "+x" /etc/auto_master
sudo umount /home
# link actual home directory (/Users/<user>) to new 'home' (/home/<user>)
ln -s $HOME /home/$USER
I adapted the previous solutions to Big Sur (macOS 11.2), which is a bit more complicated due to the APFS file system changes. I managed to change /home by following these steps:
As recommended by Alan W. Smith, comment out the /home entry in /etc/auto_master.
As suggested by Marco Torchiano, run
sudo umount /home
Since /home is currently a read-only link to /System/Volumes/Data/home, you have to change the latter. I did it with the following commands:
cd /System/Volumes/Data/
sudo rmdir home
sudo ln -s <some other directory> home
Why don't you just run MAMP and use the Sites directory? You can develop off localhost and just have a bunch of aliases for your sites. I'm not sure why you specifically need to use the home directory.
EDIT:
Ok, I think you are going about solving your problem the wrong way.
If it's HTML paths you are worried about, the begin everything with a slash "/" which will default it to the home dierectory.
If it's the references in your PHP, then you need to create a global (or similar) and set it as the root of your site. Then you can reference everything from the global and when you move the site from dev to production all you need to change is the global.
Trying in a round-about way to develop from /home because it looks more like the production server is a bad idea.
Install MAMP, create the global somewhere high in the hierarchy and start re-referencing. It'll be less pain in the long run.