CODE FARM
Galaxy background

"In the depth of winter, I finally learned that within me there lay an invincible summer."

- Albert Camus

A Guide to Shells on Windows: Git Bash, Cygwin, and WSL

26 Aug 2025

1. Git Bash Integration with Windows Terminal

To enhance the command-line experience on Windows, Git Bash can be integrated directly into Windows Terminal. This process involves creating a dedicated profile that correctly launches the Bash shell and ensures full support for Unicode characters.

1.1. Creating the Windows Terminal Profile

A new profile for Git Bash can be added within the Windows Terminal settings, which are accessible via the Ctrl + , shortcut. Navigate to the "Add a new profile" section and select "New empty profile".

The following settings should be configured for the new profile:

  • Name: Git Bash

  • Command Line: C:\Program Files\Git\bin\bash.exe -i -l

  • Starting Directory: %USERPROFILE%

  • Icon: C:\Program Files\Git\git-bash.exe

The -i -l (or --interactive --login) flags in the command line are essential. They instruct the shell to start as an interactive login shell, which properly loads configuration files and enables features like correct handling of non-ASCII text.

For example, without these flags, Unicode filenames may appear garbled:

$ ls -l /tmp/hello/
total 0
-rw-r--r-- 1 ousia 197121 0 Aug 29 16:46 '''□□'''$'''\226''''''□'''$'''\225\214'''

With the flags, the same command correctly displays the filename:

$ ls -l /tmp/hello/
total 0
-rw-r--r-- 1 ousia 197121 0 Aug 29 16:46 世界

Once these options are set, the new profile can be saved.

1.2. Displaying Unicode Filenames in Git

By default, Git may escape non-ASCII characters in filenames when using commands like git status. This can make it difficult to read the output.

Consider a file named Hello 世界.txt. The default output would be:

$ git status
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        "Hello \344\270\226\347\225\214.txt"

To disable this behavior and display filenames literally, the core.quotePath configuration option should be set to false.

git config core.quotePath false

After applying this setting, git status will produce a much more readable output:

$ git status
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        Hello 世界.txt

To apply this configuration to all repositories for the current user, the --global flag should be used:

git config --global core.quotePath false

1.3. Disabling the Terminal Bell

The Bash shell may produce an audible or visual "bell" for certain events, such as when a tab-completion search finds no results. This behavior is controlled by the Readline library.

The bell effect can be disabled by creating or editing the .inputrc file located in the user’s home directory (%USERPROFILE% or ~). The following line should be added:

# ~/.inputrc

# Disable bell
set bell-style none

This change will take effect in any new Git Bash session.

1.4. Advanced SSH Configuration for Git

Managing SSH keys and configurations is a common task when working with Git repositories on multiple platforms or with multiple accounts.

1.4.1. Generating a New SSH Key

Before configuring the client, a new SSH key pair may be needed. The ssh-keygen command is used for this purpose. It is best practice to use the modern and secure Ed25519 algorithm.

# The -t flag specifies the key type, and -f specifies the output filename
ssh-keygen -t ed25519 -f ~/.ssh/<your-private-key-filename>

This command creates two files: <your-private-key-filename> (the private key that stays on the local machine) and <your-private-key-filename>.pub (the public key to be uploaded to services like GitHub).

1.4.2. Client Configuration

To ensure Git uses the correct SSH key for the right repository, the SSH client can be configured to present a specific key based on the host. This is managed in the SSH configuration file, located at ~/.ssh/config.

An example configuration block is as follows:

# ~/.ssh/config

# Use a specific key for github.com
Match host github.com
  # Only use the identity specified below
  IdentitiesOnly yes
  # Path to the specific private key
  IdentityFile ~/.ssh/<your-private-key-filename>

  • Match host github.com: Applies the following settings only when connecting to github.com.

  • IdentitiesOnly yes: A security measure that prevents the SSH client from trying every available key. It will only use the key specified by IdentityFile.

  • IdentityFile: Specifies the exact path to the private key to be used for this host.

1.4.3. Multiple Users for the Same Host

When managing multiple accounts for the same host (e.g., a personal and a work account on GitHub), it is necessary to use host aliases in the SSH configuration. This allows for differentiating between connections to the same real host.

The setup for multiple users involves creating distinct Host blocks in the ~/.ssh/config file, each with a unique alias.

1. Configure ~/.ssh/config

Two Host blocks are created, one for each alias:

# Example for a personal GitHub account
Host github.com-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_personal
  IdentitiesOnly yes

# Example for a work GitHub account
Host github.com-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work
  IdentitiesOnly yes

  • Host github.com-personal: This is a custom alias. The alias can be named arbitrarily.

  • HostName github.com: This specifies the real server address that SSH will connect to.

  • IdentityFile: This points to the specific key for that user.

2. Clone Repositories Using the Alias

When cloning a repository, the real hostname (github.com) in the clone URL must be replaced with the appropriate alias.

  • For a personal repository: The github.com-personal alias is used in the URL. sh git clone git@github.com-personal:personal-username/personal-repo.git

  • For a work repository: The github.com-work alias is used. sh git clone git@github.com-work:work-username/work-repo.git

When these commands are executed, SSH interprets the alias (e.g., github.com-personal), consults the configuration file, and automatically uses the correct HostName (github.com) and IdentityFile. This ensures the appropriate key is presented to GitHub for each context.

1.4.4. Managing Host Keys

The first time a connection is made to a new host, its public key is stored in the ~/.ssh/known_hosts file to prevent man-in-the-middle attacks. If a server’s host key changes (e.g., because the server was rebuilt), connection attempts will fail with a security warning.

To remove the old host key from the known_hosts file, the ssh-keygen -R command is used.

# Remove all keys belonging to github.com from the known_hosts file
ssh-keygen -R github.com

After removing the old key, the new key will be automatically added on the next connection attempt.

1.5. Configuring Git Proxy

In environments behind a corporate firewall or when using a SOCKS proxy, Git operations (like clone, fetch, push) may require proxy configuration. Git can be configured to use HTTP/HTTPS or SOCKS5 proxies.

Git configurations can be set at three levels:

  • Local (per repository): Applies only to the current Git repository. Set by running git config without any scope flags.

  • Global (per user): Applies to all repositories for the current user. Set using git config --global.

  • System (all users): Applies to all repositories for all users on the system. Set using git config --system.

The examples below use the --global flag, configuring the proxy for the current user across all their repositories.

1.5.1. HTTP/HTTPS Proxy

To configure Git to use a standard HTTP or HTTPS proxy, the http.proxy and https.proxy configurations can be set:

# For HTTP traffic
git config --global http.proxy http://proxy.example.com:8080

# For HTTPS traffic
git config --global https://proxy.example.com:8080

Replace http://proxy.example.com:8080 and https://proxy.example.com:8080 with the actual proxy address and port.

1.5.2. SOCKS5 Proxy

For SOCKS5 proxies, the configuration uses the socks5:// protocol prefix:

# For HTTP traffic over SOCKS5
git config --global http.proxy socks5://127.0.0.1:1080

# For HTTPS traffic over SOCKS5
git config --global https.proxy socks5://127.0.0.1:1080

Replace 127.0.0.1:1080 with the SOCKS5 proxy address and port.

1.5.3. Using Netcat for Advanced Proxying

For more advanced scenarios, or when a SOCKS proxy needs to be used for SSH connections, netcat (or nc) can be configured as a proxy command. This is typically done in the ` ~/.ssh/config` file for SSH connections, but can also be used with http.proxy for HTTP/S traffic if netcat is set up to tunnel.

# Example for SSH over SOCKS5 using netcat (in ~/.ssh/config)
Host github.com
  ProxyCommand nc -X 5 -x 127.0.0.1:1080 %h %p

To disable proxy settings, the configurations can be unset:

git config --global --unset http.proxy
git config --global --unset https.proxy

2. Cygwin: A Linux-like Environment on Windows

Cygwin provides a large collection of GNU and Open Source tools which provide functionality similar to a Linux distribution on Windows. It offers a powerful command-line environment with access to many standard Unix utilities.

2.1. Installation and Package Management

The entire Cygwin environment is managed through a single executable, setup-x86_64.exe, which can be downloaded from the official Cygwin website. This setup tool handles the initial installation and is used subsequently for updating the core system or installing, updating, and removing individual packages.

By default, the setup program attempts to run with administrative privileges to perform a system-wide installation. For a portable or user-specific installation that does not require administrator rights, the --no-admin flag can be used:

./setup-x86_64.exe --no-admin

To manage packages after the initial setup, the same setup-x86_64.exe file is run again. After proceeding to the "Select Packages" screen, the interface provides several options. Packages are grouped by category, and a search bar is available to find specific tools. To change a package’s status, click on the "New" column next to its name, which cycles through the following states:

  • To install a package: Select a specific version number (instead of "Skip").

  • To update a package: Select the latest version number. The setup tool will often highlight upgradable packages automatically.

  • To remove a package: Cycle through the options until "Uninstall" is displayed.

Once all desired changes have been made, proceeding with the installation will apply the selected actions.

2.2. Integrating with other Shells like Git Bash

A key advantage of installing Cygwin is the ability to use its powerful command-line utilities from other shells. To make tools like grep, sed, and awk available within Git Bash, PowerShell, or the standard Command Prompt, the bin subdirectory of the Cygwin installation must be added to the Windows PATH environment variable.

For a standard installation, this directory is typically located at:

C:\cygwin64\bin

Once the PATH is configured, Cygwin commands can be executed seamlessly from any terminal on the system. This effectively augments the capabilities of shells like Git Bash with the rich toolset of a Linux-like environment.

3. Windows Subsystem for Linux (WSL)

The Windows Subsystem for Linux (WSL) allows for running native Linux distributions directly on Windows, providing a tightly integrated and high-performance environment for development and system administration.

3.1. Installation and Management Commands

WSL is managed primarily through the wsl.exe command-line tool in PowerShell or Command Prompt.

3.1.1. Installation

To install WSL along with its default distribution (Ubuntu), the following command is used:

wsl --install

To install only the required WSL components without installing a Linux distribution, the --no-distribution flag can be used. This is useful for preparing a system where distributions will be imported manually later.

wsl --install --no-distribution

A list of available Linux distributions can be viewed with wsl --list --online. A specific distribution can then be installed using the -d flag:

wsl --install -d Debian

3.1.2. Common Commands

Here are some of the most common commands for managing distributions:

  • List installed distributions: Shows the state and WSL version of all installed distributions.

    wsl --list --verbose

  • Shutdown all running distributions: Immediately terminates all running distributions and the WSL 2 virtual machine. This is often required after making configuration changes.

    wsl --shutdown

  • Export a distribution: Creates a .tar archive of a distribution, which is useful for backups or for sharing a configured environment.

    wsl --export <DistroName> <FileName.tar>

  • Import a distribution: Imports a .tar archive as a new distribution. This allows for creating multiple copies of an environment and specifying a custom installation location.

    wsl --import <NewDistroName> <InstallLocation> <FileName.tar>

  • Unregister a distribution: Deletes a distribution, including its entire file system. This is a destructive operation and cannot be undone without a backup.

    wsl --unregister <DistroName>

3.2. WSL Networking

WSL’s networking architecture dictates how distributions connect to the internet, to the Windows host, and to the local area network (LAN). There are two primary modes available, which are controlled via the .wslconfig file discussed in the next section.

3.2.1. NAT Mode (Default)

By default, WSL uses a Network Address Translation (NAT) based architecture. In this mode, the Linux environment receives an IP address on a separate, private virtual network.

  • Accessing Linux from Windows: Windows can communicate with Linux applications via localhost. For example, a web server running in Linux on port 8000 is accessible from a Windows browser at http://localhost:8000.

  • Finding the WSL IP Address: For more advanced scenarios, the specific IP address of a Linux VM can be found by running the following command from PowerShell or Command Prompt. This is useful when localhost does not work as expected.

    wsl hostname -i

    To target a specific distribution when multiple are installed, use the -d flag:

    wsl -d <DistroName> hostname -i

  • Accessing Windows from Linux: To communicate with a service running on the Windows host, the Linux environment must use the host’s IP address. The localhost address inside Linux refers only to the Linux environment itself.

  • Limitations: This virtualized networking can create challenges for some VPN configurations and does not provide direct access to WSL services from other devices on the LAN.

3.2.2. Mirrored Mode

Available on Windows 11 (22H2 and newer), Mirrored mode is a newer architecture designed to simplify networking. It works by mirroring the existing network interfaces from the Windows host directly into Linux. This mode is enabled by setting networkingMode=mirrored in .wslconfig.

  • Simplified Connectivity: The Linux environment shares the same IP address as the Windows host. This means localhost can be used to communicate between Windows and Linux in both directions. Furthermore, any other device on the local network can access services running in WSL by using the Windows host’s IP address.

  • Improved Compatibility: This mode significantly improves compatibility with VPNs and complex corporate network setups.

  • Full IPv6 Support: Unlike NAT mode, Mirrored mode provides full, first-class IPv6 support.

3.3. Global Configuration (.wslconfig)

Global settings that apply to the WSL 2 virtual machine for all distributions are configured in the .wslconfig file. This file must be created in the Windows user profile directory (%USERPROFILE%). It is primarily used to control hardware resource allocation and networking.

An example configuration could be:

# Settings apply across all WSL 2 distros
[wsl2]

# Limit VM memory to 10GB
memory=10GB

# Disable the swap file for the WSL VM
swap=0

# Use the mirrored networking mode for simpler network access
networkingMode=mirrored

# Automatically configure proxy settings from Windows
autoProxy=true

Changes to .wslconfig only take effect after running wsl --shutdown.

3.4. Per-Distribution Configuration (wsl.conf)

Settings specific to an individual Linux distribution are configured in the /etc/wsl.conf file, which must be created inside that distribution’s filesystem. This file is used to control boot behavior, networking, and user settings for that specific environment.

For example, to enable systemd, set a custom hostname, and define the. default user:

# /etc/wsl.conf

[boot]
# Enable systemd to run services like Docker
systemd=true

[network]
# Set the hostname for this distribution
hostname=<your-hostname>

[user]
# Set the default user to log in with
default=<your-username>

After modifying /etc/wsl.conf, the specific distribution must be terminated (e.g., wsl --terminate <DistroName>) and restarted for the changes to apply.