Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I come from Linux where I'm used to the fact that most applications install to /usr/bin and my tools I put in ~/bin. This means I rarely need to modify the PATH variable.

Since I work as a developer, I need to use the command line. I plan to use powershell, but I hate to need to add paths to PATH each time I install a new utility (e.g., 'java').

So what are my options to have the same experience as in Linux where I install an application (usually under 'c:\program files\some app') and have it available in my shell? Something that scans all of 'c:\program files' maybe (usually applications are either under 'c:\program files\some app' or 'c:\program files\some app\bin')?

share|improve this question
not really an answer since i don't know powershell, but... doesn't powershell have some kind of alias-like feature? – quack quixote Jan 4 '10 at 23:10
up vote 0 down vote accepted

An interesting question, and I am afraid I don't have a great answer... but I did come up with this idea:

Create a directory in your %USERPROFILE% directory, maybe even call it bin and add that your path. Then have a script you can run that "builds" a bunch of hard links to the executables in your program files directory....

gci -r -include *.exe 'C:\Program Files' | % { fsutil hardlink create "C:\Users\Ittay\bin\$_.Name" "$_.FullName" }

There are a few problems with this, like a complete lack of collision handling, 64 bit systems you would need both the 'Program Files' and 'Program Files (x86)' directories, hardlinks are also only available on NTFS volumes... and of course, if something were to change the contents of your bin directory it could mirror those changes to your programs (though simple deletions would be safe). And probably many, many more. Maybe someone else can use this as a starting point to something great?

share|improve this answer
Just tried the dir part on my own system. Collisions are indeed the biggest problem. Java is one particular culprint. Apart from both the 32-bit and 64-bit runtime (I'm a developer as well) there are the runtimes that come with MATLAB and Mathematica. I don't see how this could be automated. – SealedSun Jan 5 '10 at 3:34
I thought of another huge gotcha - some applications in the Program Files directory might expect to be started in their application folder - e.g. the working directory set to the location of the executable. This method would horribly break that. – Goyuix Jan 5 '10 at 16:01

I lump my windows installables into three categories -- lightweight utility (most of the commands you're used to from linux), heavyweight (those that install with a small number of DLLs and auxiliary files, like Flac), and applications.

You're unlikely to invoke the big applications (like Firefox, Open Office, etc.) from you're command-line, so install them in the default area.

I then install the lightweight utils in a few well-known places -- mostly ~/bin and c:/bin, and put those two directories in the front of the path.

Finally, I put the middleweight entries in their own directory under c:/apps -- if you're invoking these programs from the command-line, the fewer special characters you have to escape the better.

I use msys as well. Both cygwin and msys are both more hostile to the windows file system than I wish, but msys is less obtrusive, but also less complete.

Your path will still probably be larger on Windows than on Unix. I have a "path2.bat" command that runs the path through tr so I can see each entry on its own line, and it fills a screen.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .