Is Git Bash classified as a virtual machine?
No, Git-Bash is not an emulator nor a virtual machine (WSL is, AFAIK). It's a port — software, written for Linux (and Unix in general) and compiled to run natively on w32.
In short, no this is not a virtual machine, this is an emulator.
based on this
In Windows, we tend to run commands in CMD but they are actually
executable files that exist in the C:\Windows\System32 folder. The
same case is for bash, it requires the utilities to make the commands
work. In Unix systems, these utilities will be under /usr/bin
directory. So, by installing the Git Bash these utilities will be
installed in C:\Program Files\Git\usr\bin folder.
This program actually installs commands that are created for windows runtime and used as in linux.
Related
When I run the WSL bash shell, I can use the "ln -s" command to create a symlink. No matter if I am working on an NTFS file system or on the WSL file system, the symbolic link gets created as expected. Specifically, the link in the WSL file system works just like a Linux symlink and the symlink in the NTFS file system is a Windows symlink and I can use it both from WSL and Windows.
Contrast that to how symlinks work in the Linux version of git running in WSL. I clone a repo that contains symlinks to the NTFS file system. I am not sure what the links are, but they are most definitely not Windows symlinks.
Some might say that I should use the Git for Windows which creates the proper Windows symlink when I clone the repo. The only issue is that we have tools written as bash scripts that everyone uses and these tools call git. They work fine on Linux but from WSL they do not perform as expected because of the symlink issue. I have found that I need all the command-line developer tools to run in WSL so that they can call each other and pass file paths and env vars and such. So it is really not an option for me to run Git for Windows.
Is there any means to get this addressed? If the WSL bash shell can function properly then surely a small change in the Linux version of git could also fix this issue. This smells of some sort of philosophical fight between Windows and Linux. Or is there a legacy to this that pre-dates Git for Windows... In which case, surely there is a way to enable a new treatment of symlinks for those who want to use Windows symlinks.
This is likely an issue in Windows and the Windows Subsystem for Linux.
The emulated Linux environment creates symlinks using the symlink(2) system call, much like the ln -s command does.
The reason this is tricky to support is because Windows symlinks are less capable than Unix symlinks. Unix symlinks can point to any location, regardless of the object at that location, and the destination need not exist. Windows symlinks, on the other hand, point to either a file or a directory, but are pinned to one type.
The standard Git, as shipped by upstream, checks to see if symlinks can be created pointing to a file that does not exist. That this works is important because Git need not check out the destination file before the symlink. If this fails, Git sets core.symlinks to false, and what's written instead are files with the contents of the symlinks. WSL can't create a symlink of the right type when this test occurs (because there's no destination), and consequently, the operation fails.
Git for Windows likely has some functionality to work around this issue with symlinks in Windows. It also has a huge number of patches which are not included in the version shipped by upstream, and hence not the version used by most Linux distros.
I should point out that there's a Linux distro that also shipped a patch that permitted symlinks to be created only if they pointed to a file the user (and not anyone else) owned, and it broke things in the same way.
You can try to run git config core.symlinks true in a fresh repository and see if that works as you expect; it may, or it may not. If it doesn't, you can see if the Git for Windows maintainer will send the patch they're using upstream, and it may eventually be included in a newer version of Git, and hence in a newer version of Linux distros. However, because Linux distros typically provide stable versions, this will take time, usually on the order of years, unless you pull down a newer package.
In general, though, you can't expect Unix code to work adequately on an NTFS file system because it's fundamentally different, and Microsoft even documents this behavior. Microsoft knew (or should have known) when they added symlinks how Unix symlinks functioned, and for some reason they chose to do it differently. I personally think that was a mistake, and here we are now.
I am using Bash on Ubuntu on Windows, and I installed git. How do I add git to my PATH?
The General command is (using setx):
setx PATH=%PATH%;C:\path\to\Git\bin
On WSL (Windows Subsytem for Linux), you would type, after installation:
which git
It should be already in your PATH (/usr/bin or /usr/local/bin)
If it is not, you can try and find it: find / -name "git", and add it to your ~/.profile with:
export PATH=$PATH:/path/to/git
But be aware the WSL will install an old version of Git.
Fir the most recent one, use:
sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get install git-core
Where is /usr/local/bin on Windows?
As mentioned in BashOnWindows issue 402:
Under C:\Users\**user**\AppData\Local\lxss, You will find:
root folder
home folder
and a hidden rootfs folder (\bin, \boot, \dev, \etc...)
DON'T CHANGE ANYTHINK INSIDE! SERIOUSLY! 🚨
Access Windows files via /mnt/**letter**/
And:
Maybe I don't fully understand what Bash on Ubuntu on Windows is.
See Wikipedia WSL entry:
Windows Subsystem for Linux (WSL) is a compatibility layer for running Linux binary executables (in ELF format) natively on Windows 10.
Windows Subsystem for Linux is only available on 64-bit editions of Windows 105 and can be activated on Windows 10 Anniversary Update and later.
WSL uses fewer resources than a full virtualized machine, the most direct way to run Linux software on a Windows computer, while also allowing users to use Windows apps and Linux tools on the same set of files.5
The OP adds:
So if I install git and it's in /usr/bin/git, does that correspond to a particular folder such as C:\Program Files\etc...?
Yes, under C:\Users\**user**\AppData\Local\lxss\rootfs\usr\..., but you are not supposed to access it directly. You only use it through the WSL bash.
Is setting my PATH different by putting it in my ~/.profile vs. going into Control Panel --> System Properties --> Environment Variables
Yes, completely. If you want to set your Windows Environment Variables PATH, you need to use Git for Windows, as described in here.
The solution assumes u want to access git inside WSL in your Windows Environment
Check this Out
https://github.com/ardevd/gitwrap/releases
This wrapper pipes output from WSL to windows and also works on android studio claimed by the developer
This Wrapper was not developed by me
for any issues plz post on the github page
I've two Windows machines and both have bash installed. However, they differ in the way bash starts up:
Machine 1:
Typing "bash" starts the bash. Then I can type commands like ls.
Machine 2:
It seems like it starts bash and directly runs ls in it, by only typing "ls". After that it switches back to CMD automatically, like this:
Does anyone know which setting enables the behavior of machine 2? Everything looks the same for me. It's a nice feature and I want to enable it on machine 1 as well.
Bash on Ubuntu on Windows executables (binaries) cannot run from Windows applications such as cmd.exe or PowerShell.exe - Windows doesn't even see them as executable.
The likeliest explanation is that you've installed a separate Unix emulation environment such as GnuWin, which comes with native Windows binaries.
To see the location of your - by definition Windows-native - ls executable, run where ls, which will probably tell you what product it came with, such as
C:\Program Files (x86)\GnuWin32\bin\ls.EXE.
Note that the Ubuntu on Windows binaries are stored in a user-specific manner in
%LOCALAPPDATA%\lxss\rootfs\bin, but that is a moot point, given that you cannot invoke them from Windows.
In Windows 10, there is a built-in Linux subsystem (one of the greatest features of Windows 10). It gives you almost a complete Linux shell for various distributions, and you can almost do anything with it (user mode).
I bet it is installed on your first computer, and you are using that subsystem. In the latest version of this subsystem, you can run both Linux executables and Windows exe files.
I was just curious if there are any tools out there that would allow me to practice shell scripting without dual booting my computer to half windows and half UNIX. I've heard of Cygwin but is that truly UNIX ?
Install Cygwin or install a Linux system under a virtual machine with emulators like VirtualBox.
Cygwin is not completely UNIX but it would be enough with not-too-system related scripting. There are differences though compared to a true UNIX system e.g. process managing wouldn't really work well. /proc too I think doesn't work as expected.
Cygwin is okay, but keep in mind that if you want to learn about UNIX, Cygwin won't help with learning about the Linux filesystem, which is important.
You could also have a look at How to develop in Linux-Like Shell (bash) on Windows?, maybe there are some helpful answers.
Personally, I think a Linux VM is your best option. Cygwin is a UNIX-like environment on top of Windows, it's not a UNIX emulator.
I generally install git with Windows installer. Not only it comes with bash (look for "git bash" in Start menu), it also comes with git (duh) and ssh.
Obviously that's not "truly unix", for that install Virtualbox and in it FreeBSD or some other *BSD (they are officially "unix", unlike Linux which is "just" unix-like).
I cannot access my virtual machines from the cygwin console. (Windows 7, UAC is disabled)
Matthias#laptop0x4d53 /cygdrive/c/Program Files/Oracle/VirtualBox
$ ./VBoxManage list vms
The Windows console, however, has access to my virtual machines.
C:\Program Files\Oracle\VirtualBox>VBoxManage.exe list vms
"GlassFish" {68874e4d-817a-4315-9ea2-38726964ac32}
"Tomcat" {2e22a7c0-9950-4593-8eda-778d404476c7}
"LAMP" {36aa6968-df52-49b5-be52-1f59c50f1527}
Maybe it's a problem with the user's rights. How can I access my VMs from cygwin also?
Did you try the official forums? There are some solutions exporting some variables on ~/.bashrc and starting VB in headless mode (this is a recent post, from 2011). There's even an ugly hack about exporting a bunch of environment variables using bat files instead.
#export VBOX_USER_HOME='/cygdrive/c/Documents\ and\ Settings/SomeNameHere/.VirtualBox/'
export VBOX_USER_HOME='C:\Documents and Settings\SomeNameHere\.VirtualBox\'
...or HOWTO - virtualbox as a service on Windows (cygrunsrv.exe). This is reported to be working on Cygwin 1.7b.
$ cygrunsrv --list
vboxd-myvm
This answer is in the spirit of 'consider this possibility' ;-)
How 'married' are you to cygwin as your unix tool on windows? My experience with cygwin is that is very slow but it's strength is that it comes with a wide range of linux-like tools AND probably has the largest user-support community.
There are at least 2 alternatives to cygwin that I use and can recommend AND with a quick test DID return the list of my active vms_s. They are UWIN and MinGW.
Read my writeup about ksh and UWIN here
Regarding 'for' loop in KornShell (2 nd msg)
ALSO check out the MinGW environment. I have installed MinGW primarily to have access to gcc (outside of cygwin) and it has a fair number of linux-like tools.
I hope this helps.
Easy to fix - you need to use Windows path syntax in your .bashrc
This -
VBOX_USER_HOME='C:\Documents and Settings\user.VirtualBox'
Instead of this -
VBOX_USER_HOME=/cygdrive/c/users/user/.VirtualBox