I am running a Windows Powershell provided through the git for windows installation. This shell provides many unix style commands (i.e. "ls", "mv", etc.).
My question is: How do I access Unix style paths from the powershell cmd line on Windows?
Consider this example: the "ls" program is installed and works in the powershell. The path is shown as "/usr/bin/ls" if I type "which ls" as the cmd prompt. But if I try to change my current directory using "cd /usr/bin/", the shell complains that the path is not found.
I can't see any mounted volumes or anything like that using "mount" (perhaps in PowerShell it is a different command?).
I'm asking this question because I have other files that I need to get to which are listed under unix-style paths, and right now I can't get to anything. I figure if I can get to /usr/bin, then I can figure out how to get where I really need to go.
Powershell is not Unix. It may have a few familiar commands like "ls" and "ps", but that's where the similarity ends.
When you installed Git For Windows, you likely installed the Git Bash shell as well. Run that instead to get a more Unix like atmosphere. (Re-install Git For Windows if you didn't select this option on install).
But even with Git Bash, there's still no such folder as /usr/bin. That folder doesn't exist on Windows. If you want a Unix emulation on Windows that includes the traditional folder structure, use Cygwin. And you can run Git on that environment too and access an emulated /usr/bin folder.
So, I'm trying to install gitlab on a subdirectory. A lot of articles online suggest it is now possible to do so.
I installed omnibus-gitlab but it didn't seem to contain the files required to make gitlab run in a subdirectory like application.rb and stuff. Did a little research and discovered it is not yet supported on omnibus.
So why the differences? I actually thought they were all different ways of getting the same thing. My question again: difference between cookbook, omnibus and normal manual installation. Thanks!
Cookbook : the installation is done by Chef recipes
Manual : you install all the components one by one, manually, with a lot of pain and suffering
Omnibus : The installation in simplified with a .RPM (red hat) or a .deb (Debian), much more simple.
The results are differents: with a manual install, the home dir of gitlab will be somehting like /home/git/... while it will be /opt/gitlab/... in omnibus. Also, the commands to manage your GitLab instance are a little differents. By example, in manual install to seed an external DB you have to type sudo -u git -H bundle exec rake gitlab:setup while gitlab omnibus will need a sudo gitlab-rake gitlab:setup.
From what I tested, they all leed to the same GitLab features, but with a different way to manage it.
Now for the subdirectory (it doesn't works for me, but that's what the documentation say) : after an omnibus install, modifiy the non_root_url in the following files :
/opt/gitlab/embedded/service/gitlab-rails/conf/gitlab.yml
/opt/gitlab/embedded/service/gitlab-rails/conf/application.rb (read the comments at the bottom of the file)
/opt/gitlab/embedded/service/gitlab-rails/conf/unicorn.rb
/opt/gitlab/embedded/service/gitlab-shell/config.yml
And then restart GitLab. I repeat: that's what the gitlab's doc say, but it doesn't works for me. In my case it just create a redirection. Look:
#gitlab is configured to run in subdirectory "/gitlab" :
curl -v http:127.0.0.1:3000/gitlab
----> Error 404
curl -v http://127.0.0.1:3000
----> <html><body>You are being redirected.</body></html>
"Failed to find 'git' on your PATH. Please ensure 'git' is executable by the Go Server and on the Go Agents where this material will be used."
I'm getting this when attempting to use GIT when creating a new build pipeline.
I'm not that experienced with Linux to know how to debug this and I can't find anything in the docs or via a google search.
GO was installed as root, so was GIT, the server has been rebooted since and I can run git in bash. "which git" shows that it is in /usr/bin. "export $path" shows that /usr/bin is in the PATH variable.
Can anyone recommend anything else to try?
Thanks.
The Go server and agent runs under user 'go' and therefore you will need to ensure git is in path for this user.
Change the user to go. If you get a prompt for password, put the password of the current logged in user.
$ sudo su - go
Then check if git is in path or simply check for the version
$ which git
$ git --version
If you don't get expected output for the above commands you might have to provide git executables to the user 'go', that is, you will need to add git in this user's PATH. Alternatively, you can provide the path in /etc/default/go-server
export PATH=$PATH:/path/to/git
I recall having this problem too, for me it was related to a local git repository that I did not share with the git daemon. Running the repository with the git daemon solved this problem for me.
URL for me starts with git://localhost, not sure if http will work too
I am trying to make a new branch in Gitlab by using Gitolite. I complete the installation steps. when i come across "setting up gitolite" section i have a trouble. I followed this link.
When i run
gitolite setup -pk alice.pub
command i got "bash: gitolite: command not found" error message. I don't know what is the problem.. Any one please help me.
This step comes after the Gitolite installation, which supposes you have chosen one of three possibilities:
Keep the sources anywhere and use the full path to run the gitolite command.
Keep the sources anywhere and symlink just the gitolite program to some directory on your $PATH.
Copy the sources somewhere and use that path to run the gitolite command.
So make sure gitolite is in your PATH, and that command will work.
I prefer a local installation of gitolite (in a local directory, as opposed to /usr/local, which requires root privileges.).
See, for illustration, "install_or_update_gitolite.sh"
"${github}/install" -to "${gtl}/bin" # Note: "${gtl}/bin" is in my $PATH
GITOLITE_HTTP_HOME= gitolite setup -pk "${H}/.ssh/gitoliteadm.pub"
Note that for gitolite setup to properly work, you might want to set GITOLITE_HTTP_HOME to an empty string first.
As I also faced the same problem, I found the solution(s) as below.
First way is ...,
Open your terminal and key in below code
$ PATH=$PATH:~/bin
It is because the value of $PATH variable is point to incorrected path.
So I just modify this variable.
To be more detail click here.
Second way is ...,
Edit .bashrc file going to the end and insert below line.
PATH=/home/git/bin:$PATH
To be more detail click here.
On debian, there is no /usr/bin/gitolite
Linux debian-srv 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux ls: cannot access /home/gitolite/bin: No such file or directory
ls: cannot access /usr/bin/gito*: No such file or directory
Here installing gitolite3 helped:
apt-get install gitolite3
root#debian-srv:# which gitolite
/usr/bin/gitolite
I commonly work on multiple computers. I have various configuration files, eg, .bashrc, .gitconfig, .irbrc, .vimrc and configuration folders, eg, .vim/ that contain valuable customizations.
Sometimes I want small variations in configuration between the different computers.
I want to use version control to manage these different files.
do others use version control to manage their configuration files?
what are some hints that might make this easier?
what's the most elegant way of dealing with variations between the computers?
I'm comfortable with git; any other suggestions?
I keep a folder at ~/config/ which is a bzr repository. I push/pull the repository between my various computers to sync it up. I have an install script which I use to make symlinks to my home directory:
#! /bin/sh
# link all files to the home directory, asking about overwrites
cd `dirname $0`
SCRIPT_DIR=`pwd`
SCRIPT_NAME=`basename $0`
FILES=`bzr ls --versioned --non-recursive`
cd $HOME
for FILE in $FILES; do
ln --symbolic --interactive $SCRIPT_DIR/$FILE
done
rm $TARGET_DIR/$SCRIPT_NAME
If you want to use git instead of bzr, you can instead use:
FILES=`git ls-tree --name-only HEAD`
(I had to ask SO to figure that out)
EDIT: I don't actually do this anymore, now I have a dotfiles repo on github, with a nice rake install script that someone else wrote.
At the moment, I use a cloned git repo. To keep things simple, the only file that needs to vary between the different machines is .bashrc. It's nice if there can be just one version of this file that responds differently on different machines. Thus, in my .bashrc:
if [ $(hostname) == 'host1' ]; then
# things to do differently on host1.
elif [ $(hostname) == 'host2' ]; then
# things to do differently on host2.
fi
This obviously has some limitations (such as that a different technique would be required for .vimrc or other config files needing customization), but it works fairly well.
If you use git, you could define an "origin" repo to be the master; and then do a clone on each computer you work. you could use a branch for every computer to have your set of config files.
With CfEngine you can manage config files across machines and do also many more things!
The learning curve is maybe a bit high but worth it if you have to manage/update/maintain a pool of computers running linux regularly.
Easy. Use DropBox for that:
http://www.nixtutor.com/linux/sync-config-files-across-multiple-computers-with-dropbox/
I use slack for a similar situation. slack allows definition of roles/subroles so you can manage files with small variation either through a cloned file or patch. The slack directory is then managed by git in my deployment.
Here are some dotfile managers:
homesick: Based on Ruby
homeshick: Same as first one, but without ruby dependency
dfm: Written in Perl
git with branches for custom computers, with automated sync at login seems like a good solutions to me.
I've used etckeeper for versioning configurations, but I've never actually expanded to user configurations.
This kind of question comes up occasionally, and I've never seen a tool to handle this common use case, so I wrote a script that uses git and symlinks to manage these files.
See http://github.com/bstpierre/dotfiles
It is not perfect. There is currently a bug related to handling directories, and there is no support yet for variations across computers.
Before using any tool of this nature, make sure you have good backups!
I think what you want could be similar to what I've been doing...
Make a directory in home called .host_configs/ . This is version controlled. Or in my case it lives in a special folder on a central computer, I scp it down on any new machine. Inside it make a folder for every host that you want different configurations for. The folder for each host should be named after the short hostname for that machine. So in your git repo you have:
.host_configs/
homecomp1/
girlfriendcomp1/
workcomp1/
workcomp2/
In each host specific folder, put the .vimrc, .irbrc, etc., configuration files for that specific box.
And also, in each host folder make a file called .[SHORT_HOST]_rc. For instance, if your machine is name "sane" have a file named .sane_rc ... This file will contain the lines that would normally be in .bashrc that are unique to that host. For instance, if it's a mac and it needs alias ls='ls -GF' instead of alias ls='ls --color=auto' which works for most nix machines for ls with colors, put that line in the .[SHORT_HOST]_rc for that machine, along with whatever special functions, declarations, etc, that would normally go into the .bashrc or .profile etc. (or .zshrc, .tschrc, as the case may be). So the version controlled ~/.host_configs/ folder looks like:
.host_configs/
homecomp1/
.homecomp1_rc #special shell configs for this hostname
.vimrc #you know the rest
.irbrc
.Xresources
girlfriendcomp1/
.girlfriendcomp1_rc
.vimrc
.bubblebathrc
workcomp1/
.workcomp1_rc
.bashrc
.vimrc
workcomp2/
.workcomp2_rc
.bashrc
.vimrc
I use all the same barebones $HOME/.bashrc (or ~/.tshrc etc) on all of my machines. I just take the basic one that comes with the distro in question and move all of the host-specific configuration into the .host-configs/[SHORT_HOST]/.[SHORT_HOST]_rc file.
Put this at the bottom (of $HOME/.bashrc):
export SHORT_HOST="sane"
for file in `find ~/.host_configs/$SHORT_HOST -name ".*"`
do
ln -s $file `basename $file`
done
source ~/`.$SHORT_HOST`_rc
(Finds all of the dot-files for the host and makes a symlink in home to the~/.host_configs/foo_host folder).
Your dot files are in their normal location but they are symlinked to version control. The above also sources all of the lines in your [$SHORT_HOST]_rc file into .bashrc
You can commit back to git from the ~/.host_configs/ folder whenever you have changes.
That's what it looks like in shell, which is probably all you need, but if you need other features, I would write something that uses the same principles (sourcing an external .rc file into .bashrc and symlinking all the config files to the structured version control folder) in something more versatile/less ugly than shell. So instead of the above in your .bashrc, there could be:
export SHORT_HOST="sane"
ruby ~/import_conf.rb $SHORT_HOST
...and write your import_conf.rb to do more complex conf management, like placing a specific configuration file in some directory besides home, or handling a config folder like .ssh/, .subversion/ etc. That's what I do, it's pretty elegant for me, but there may be better solutions. Dropbox with some creative symlinks is also an excellent idea, though you're relying on a third party, and you need to be in a graphical environment. Also note there are inconsistencies between what you can do with symlinks + dropbox in Linux and shortcuts + dropbox in Windows if you implement something that wants to play with Windows.
Now there is also vcsh
From the README:
vcsh - manage config files in $HOME via fake bare git repositories
[...]
vcsh allows you to have several git repositories, all maintaining their working trees in $HOME without clobbering each other. That, in turn, means you can have one repository per config set (zsh, vim, ssh, etc), picking and choosing which configs you want to use on which machine.
Works perfectly, but may be a bit daunting if you are not an experienced git user.
Most of these answer address sync, but not how to tailor the files for the specific device. filetailor is an open-source Python program for this exact issue. Based on a YAML configuration file, it can make small changes to the files using device-specific variables or using device-specific comments in the files. Then, use another program such as Syncthing or Git to transfer the files.
For example, the following line would be commented out on every device except the one with hostname device1.
alias MYHOME='/home/dev1home/' #{filetailor device1}
Disclaimer: I had this same issue and made filetailor to solve it.