In this article I’ll document my process for setting up Git Bash / MINGW /
MSYS2 on Windows including some additional configuration (e.g. installing make and apply
some customizations via .bashrc).

Table of contents

• Introduction
• How to install and update Git Bash / MINGW / MSYS2 via Git for Windows
  • Update MINGW
  • How to install make
  • Configuration via .bashrc
• Common issues
  • The role of winpty: Fixing “The input device is not a TTY”
  • The path conversion issue
    • Fixing the path conversion issue for MINGW / MSYS2
    • Fixing the path conversion issue for winpty
• Miscellaneous
  • Change the bash custom prompt to a $

Introduction

When I was learning git I started with the fantastic
Git for Windows package, that is maintained in the
git-for-windows/git Github repository and comes with
Git Bash, a shell that offers a
Unix-terminal like experience. It uses
MINGW and MSYS2 under the hood
and does not only provide git but also a bunch of other common Linux utilities like

bash
sed
awk
ls
cp
rm
...

I believe the main “shell” is actually powered by MINGW64 as
that’s what will be shown by default:

Thus, I will refer to the tool as MINGW shell or Git Bash throughout this article.

I have been using MINGW for almost 10 years now, and it is still my go-to shell for Windows. I
could just never warm up to WSL, because the file sharing performance between WSL and native
Windows files was (is?) horrible – but that’s a different story.

How to install and update Git Bash / MINGW / MSYS2 via Git for Windows

You can find the latest Git for Windows installation package directly at the homepage of
https://gitforwindows.org/. Older releases can be found on
Github in the
Releases section of the git-for-windows/git repository

Follow the instructions in the
How to Install Git Bash on Windows article on git-tower.com
to get a guided tour through the setup process.

After the installation is finished, I usually create a desktop icon and assign the shortcut
CTRL + ALT + B (for “bash”) so that I can open a new shell session conveniently via keyboard.

Update MINGW

To update Git for Windows, you can simply run

git update-git-for-windows

See also the
Git for Windows FAQ under “How do I update Git for Windows upon new releases?”

Git for Windows comes with a tool to check for updates and offer to install them. Whether or not you enabled auto-updates during installation, you can manually run git update-git-for-windows.

Truncated by Planet PHP, read more at the original (another 19960 bytes)

Introducing new Alpine Linux PHP images from Zend. Get full details on how they work and how to get started, here.

It seems like every 7-8 years I’m switching operating systems. In 2006 I first
started using Apple, because it was just so damn cool to have a well working
Unix-like system. (I’ll never forget you Snow Leopard).

In 2015 I switched to Ubuntu. Apple’s Software seemed to hit rock bottom at
this point from a quality perspective, and hardware seemed to go obsolete at
a rate I hadn’t seen before. Fed up paying a premium price for a sub-par
product, it was time for a change.

Ubuntu’s fall

Ubuntu was the obvious choice. I want something that just works, and Dell’s
XPS 13 Developer Edition ships with Ubuntu which means hardware support
from Dell itself. Breath of fresh air and fast as hell. The experience was
similar to what people have been saying about the new M1 chips.
But it’s fast because of software, not hardware.

But something changed with Ubuntu in recent years. I think linux users have
a thicker than usual skin when it comes to software issues and are willing
to look past more things. But Ubuntu’s quality has been consistently falling.
I was being worn down, and it seems to be a common sentiment in my bubble.

The best example is Ubuntu’s package manager Snap. A pretty good idea, I like
the branding too but the execution hasn’t been there. Ubuntu users have been
effectively beta-testing this for years. Just to give you an idea I made a
giant list of bugs that I ran into when Ubuntu switched Firefox from apt
to Snap.

To be honest I feel a bit bad ragging on Ubuntu, because without knowing
anything about how the project and Canonical is run, my intuition is
that the steam is just kind of running out for them. Ubuntu feels ‘depressed’,
but maybe it’s all in my head.

Installation

Installation was super smooth. I always forget to make a separate /home
mount, so it took a while to move everything to an external disk and back.

The one thing I always forget to move is my MySQL databases, and today
was no exception.

Non-free stuff

Fedora does not ship with things that aren’t open source. Nothing against that
philosophy (awesome in fact), but personally I don’t mind adding some binaries
for a better experience.

I miss Ubuntu’s Additional Drivers tool, because it told me what to
install. I’m sure the drivers I need are available for Fedora, but I don’t
know what to look for which makes me slightly worried my computer is not
running optimally. Battery feels worse but that could also be my imagination.

Video in Firefox didn’t work at all in stock Fedora. I had to install
ffmpeg to get it to barely function, but then I discovered RPM Fusion, where
I got an even better ffmpeg, plus gstreamer and Intel drivers and I can now watch
beautiful smooth 4K video, and confirmed with intel_gpu_top that I’m using
hardware acceleration.

Gnome

Ubuntu used to have their own desktop environment called Unity. In
2018 they switched to Gnome, but they modified Gnome to keep their
Unity look.

This felt like a good move, because it let them kept their look while
taking advantage of all the Gnome plumbing.

One drawback is that Ubuntu was usually a bit behind with Gnome
features.

Fedora uses stock Gnome. As a result

Truncated by Planet PHP, read more at the original (another 2756 bytes)

In this blog, our expert discusses the new Puppet PHP modules created by Zend, with details on how they work, and how to deploy them to your benefit.

In this blog, our expert discusses how containers can be used to improve PHP application security — including details on container security best practices.

I maintain a few dozen Javascript libraries, and recently updated many of them
to support CommonJS and Ecmascript modules at the same time.

The first half of this article describes why and how I did it, and then all the
hoops I had to jump through to make things work.

Hopefully it’s a helpful document for the next challenger.

A quick refresher, CommonJS code typically looks like this:

const MyApp = require('./my-app');
module.exports = {foo: 5};

And ESM like this:

import MyApp from './my-app.js';
export default {foo: 5};

Except if you use Typescript! Most Typescript uses ESM syntax, but actually
builds to CommonJS. So if your Typescript code looks like the second and
think ‘I’m good’, make sure you also take a look at the built Javascript
code to see what you actually use.

Why support ESM

The general vibe is that ESM is going to be the future of Javascript code.
Even though I don’t think the developer experience is quite there yet, but
more people will start trying ESM.

If you decided to plunge in with ESM, I want my libraries to feel first-class.

For example, I’d want you to be able to default-import:

import Controller from '@curveball/controller';

At the same time most people are still on CommonJS, and I want to continue
to support this without breaking backwards compatibility for the forseeable
future.

The general approach

My goal is for my packages to ‘default’ to ESM. From the perspective of a
library maintainer you will be dealing with ESM.

During the build phase steps are being made to generate a secondary CommonJS
build. As a maintainer you might run into CommonJS-specific issues, but
I suspect people will only see those if the CI system reports an issue.

Our published NPM packages will have a directory structure roughly like this:

- package.json
- tsconfig.json - src/ # Typescript source
- cjs/ # CommonJS
- esm/ # ESM
- test/

We include the original typescript sources to make step-through debugging work
well, and have a seperate directory for the ESM and CommonJS builds.

If you just want to skip to the end and see an example of a package that has
all this work done, check out my @curveball/core package:

• Github source: https://github.com/curveball/core
• Published NPM package contents: https://www.npmjs.com/package/@curveball/core?activeTab=code

Typescript features we don’t use

esModuleInterop

We don’t use the esModuleInterop setting in tsconfig.json. This flag
lets you default-import non-ESM packages like this:

import path from 'node:path';

instead of the more awkward: