> Why in the design of Windows aren't programs installed or symlinked in the PATH by default? I guess that was a design choice somewhere along the history of Windows/DOS. Is there a reason?

Windows' way of program executable placement is using the holy Registry. It's called 'Application Registration'[1] and was introduced to reduce the needs to modify the system-wide PATH variable. (They thought it was a bad idea to modify a system variable so frequently, and I partially agree.)

You can find registered applications in `HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths`. Very few programs use that feature, which is unfortunate, but popular applications like Chrome and Firefox register themselves in it. That's why you can invoke `chrome` in the 'Run' dialog.

Edit: Another context to add: at the time App Paths was added, to modify PATH you had to edit AUTOEXEC.BAT manually which was painful. Not only that, but also PATH had a length limitation of 128 characters. You can find more details in the Raymond Chen's blog, as useful as always.[2]

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ee8...

[2] https://blogs.msdn.microsoft.com/oldnewthing/20110725-00/?p=...

> Not only that, but also PATH had a length limitation of 128 characters. You can find more details in the Raymond Chen's blog, as useful as always.[2]

I should note there are still length limits - in practice you'll run into issues with as few as 2047 characters:

https://support.microsoft.com/en-us/help/830473/command-prom...

Debugging this is really annoying, as one of my coworkers found out when one too many applications decided to add multiple paths to PATH (for example, nVidia CodeWorks has added no less than 8 subdirectories of C:\NVPACK\ to PATH to support Android development - for gradle, ant, jdk, ndk, and the android SDK's support, build-tools, platform-tools, and regular tools.)

Said coworker ended up spending some time using directory junctions to shorten the paths in PATH to the point where his dev environment was useful again.

Hm, interesting. I suppose this is what http://scoop.sh should be using? (The per-user setting, "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths").

Oddly it appears the python2.7 installer uses this (global setting), but not the python3.x one (It would seem that python2 could register python.exe (as it currently does), and python3 could register python3.exe (as it currently does not)).

It certainly doesn't seem to make much sense for python3 to have an option to add itself to the path environment variable, and an option to change the path length limit - but apparently not an option to use this "modern" way of registering itself? (Unless, python2 and python3 installers, when fighting it out, default to only registering python2... which makes sense, but is painful).

But based on a windows hyper-v vm with only python3 installed, it looks like python3 does not use this setting.

It is not only ugly but also slow. One of the pain points while using PowerShell. It seems that Microsoft didn't care much about the emulator until recently. Thankfully things are changing, it was improved a bit in the Windows 10 anniversary update and Microsoft promised to improve it further. I'm optimistic about it.

Fair criticism, but PowerShell is just under the hood, most devs on Windows use cmder or similar.

Adding to that: I use ConEmu.

+1 for conemu, though I wish the ux was closer to iterm2's

I stick with cygwin and tmux. I still find it easier to write scripts in bash than powershell.

> Also, if someone here has an answer: Why in the design of Windows aren't programs installed or symlinked in the PATH by default? I guess that was a design choice somewhere along the history of Windows/DOS. Is there a reason?

This get's to the real issue of what makes powershell so horrible. It's not that anyone loves bash scripts, it's that there are a tonne of great utilities that bash script tie together. Windows doesn't have this.