Why is there no /usr/bin in Windows?

I am a Linux user spending some time in Windows and I am trying to understand some of the Windows paradigms instead of fighting them. I notice that each program installed in the traditional manner adds the executables to

C:\Program Files

and then adds a shortcut to the Desktop / Start Menu containing the entire path. However, there is no common directory with links to the software, i.e. C:\bin\bar.exe which would link to

C:\Program Files\foo\bar.exe

Therefore, after installing an application the only way to use the application is via the menus or by navigating to the executable in the filesystem. One cannot simply Win-R to open the run dialogue and then type bar or bar.exe as is possible with notepad or mspaint. I realize that Windows 8 improves on this with the otherwise horrendous Start Screen which does support typing the name of the app, but again this depends on the app having registered itself for such.

Would I be doing any harm by adding C:\Program Files recursively to the Windows path? I do realize that there will be name collisions (i.e. uninstall.exe) but could there be other issues?

dotancohen

Posted 2013-11-13T09:30:55.347

Reputation: 9 798

What if there are two programs named bar? – Joel Coehoorn – 2016-11-29T05:40:52.800

There is a project named Chocolatey which defines one common directory for its installed programs, similar to /usr/bin. But it has not gained much traction. – ddbug – 2018-09-04T00:32:26.630

Windows does not pretend to be any sort of UNIX or Linux (even with WSL). Rather it tends to be like Apple's OS X. – ddbug – 2018-09-04T00:37:25.663

Note that the search box in the start menu (which allows you to find a program by typing its name) was introduced in Windows Vista, so this feature is not new in Windows 8. – sleske – 2013-11-13T10:09:30.440

1Having the app 'registered' by the installer into the start menu is the same as the application creating the link in /usr/bin/ - it relies on the application or installer doing it. – James Snell – 2013-11-13T11:43:49.550

@JamesSnell: Right, but the Linux paradigm end result is an executable that is available on the global path. The Windows paradigm end result is that one must know the full path. I'm not interested in a specific directory of links to all executables per se, but rather having all the user-run executables in the path, and additionally understanding why Windows doesn't have this paradigm. – dotancohen – 2013-11-13T11:48:37.160

1In the DOS days, typically programs would make a subdirectory off of C:\ and place all files, including temporary, configuration, data, and executable files in that subdirectory. Even today you'll find some software (typically programs that have been around a long time) that does this (e.g. UltraTax). This sort of continued with Windows 3.11, the 9x windows, and even through the NT line to maintain compatibility with the 9x line. It's getting a teensy more sensible IMHO with UAC and default permissions now starting to try to enforce more sensible things. – LawrenceC – 2013-11-13T12:07:50.543

Answers

Usually there should not be any issues. However, you need to watch out for two things:

Avoid name collisions. In particular, make sure the standard path components (like C:\windows etc.) come first, so no system utility is hidden in the path.
The PATH variable may not contain more than 8191 characters. So if you have many program folders that you want to add, you may have to pick and choose. If you assume an average path length of 50 characters per program, that gives you space for about 160 programs in the PATH.

The reason this is not done by default is probably simply that the command line is used relatively rarely on Windows, so there was never a pressing need to have everything in the path. Most programs that need to invoke other programs have adapted to this, and use the full path for invocations.

Finally, if you would like to work on the command line a lot, like on Linux, I recommend you install Cygwin. It provides a Linux-like environment on Windows, and lets you work on the command line. It also maintains its own PATH variable, which you can customize without impacting other Windows applications.

sleske

Posted 2013-11-13T09:30:55.347

Reputation: 19 887

@dotancohen You can use WSL instead if you're running Windows 10. Works virtually perfectly for python development.

– airstrike – 2016-11-29T01:31:29.193

Thank you, I actually am using Cygwin in mintty for most things now. However, Python is a beast and needs the original cmd, even with the -i flag. – dotancohen – 2013-11-13T10:21:50.717

The answer to this depends on the type of program you are talking about. If you are talking about programs that use shared libraries (DLLs):

C:\Program Files

is the correct place for them. You cannot put the files for these programs into the same folder because they are likely to have name collisions. If you are talking about programs that use static libraries (no DLLs):

C:\ProgramData\Bin

is the correct place for them. This is akin to:

/usr/local/bin

on Linux. This directory is available via a folder variable:

ProgramData=C:\ProgramData

If you need to get programs with shared libraries onto your Path, you can symlink them:

mklink C:\ProgramData\Bin\alfa.exe "C:\Program Files\Alfa\alfa.exe"

Steven Penny

Posted 2013-11-13T09:30:55.347

Reputation: 7 294