The Problem
If you use a lot of different command line tools you end up having to type a lot of paths. Every tool installs in a different directory so, to access each, you need to type a full path for every one of them.
The standard solution is to add the path to the tool to the PATH environment variable. You end up with a PATH variable like this:
PATH=C:\WINDOWS;C:...;C:\PROGRAM Files\Company\Program\Bin;You can see the existing PATH setting by typing SET at the command prompt. That shows you all of the current environment variables that have been set. PATH is one of them.
The usual command to add something to PATH is:
PATH=%PATH%;extra_directoryThat adds extra_directory to the end of the existing PATH.
The problem with the usual solution is that as you add tools the PATH environment variable gets longer and longer, and longer. Okay it looks messy but so what?
-
There is a limit to how long it can get and after that you can’t add any more tools to your bag of tricks for the command line.
-
The other issue is each addition slows down your computer. It doesn’t slow things down by much but every time you enter a command at the prompt, Windows has to find which program you want to run. It looks in the first directory in the PATH for a program and, if not found, the next directory and so on. Four directories equals (potentially) four searches for each command. As you add directories it gets slower. It isn’t all that easy for Windows during the searches either.
-
The PATH variable came from Unix and that OS runs programs with the same name as the command you enter. If you type "foo arg1 arg2" unix looks for a program called "foo". It can tell it’s found a program instead of a document because it has an "executable" attribute for each file. If it’s set it is a program. If it isn’t, it isn’t. Windows copied the PATH idea but not the executable attribute. For Windows, an item in a directory was a program if it ended in ".com". That was a long time ago and, for backward compatability reasons, it might still check for that; but soon afterwards, Windows got its own program extension – ".exe". And there were executable batch files ".bat" and they added ".vbs" visual basic script files and ".ps" powershell ones and others. The point here is every search of every directory in the PATH has to look for (".com"?,) ".exe", ".bat", ".vbs", ".ps", etc. That’s multiple searches of multiple directories for every command.
Computers are fast so the inefficiency isn’t really all that significant. A bigger issue is name-space pollution and wondering "what happened?" when you typed something.
If you have 10 directories in your PATH and Windows found and ran a program based on what you typed, where did it find the program? What if there are two, or three, programs with the same name?
If programs have the same name, Windows will run the first one it finds. In practice, that means the leftmost directory in the PATH that contains any given program.
What if you want to run one of the others? That’s where we go back to typing long full path names in commands again.
It’s a bit messy in many ways.
A Solution
A while back, I wrote a program called GuiCmd. It kept one list of programs and it searched through those (once) to find the program you wanted. The programs could be installed anywhere and you could set shortcuts to call any program any name that you thought better described it or to avoid name conflicts. It had a bunch of useful features like being able to choose directory and file program parameters by clicking instead of typing. It was a pretty good solution.
Its drawback was it only ran a single command at a time. You didn’t get to sit at a command prompt and type commands as they came to you. Each command ran its own command prompt. Clearly there’s an idea there for a future enhancement. However, there’s an easier way forward in the meantime …
The Solution
This one is really simple. It also combines some of the benefits from GuiCmd with the simplicity.
The trick here is to add only one directory to the PATH environment variable and to make it a directory that you control (not a locked down one in "Program Files"). I used "C:\USERS\(me)\Documents\Shortcuts". A unix purist might prefer "C:\USERS\(me)\bin" (or HOME\bin, a programs directory in the user’s "home" directory).
The point is to create a directory of your own and put links to all of your favorite command line programs in the directory.
Whilst I called mine "Shortcuts" and I do have shortcuts in it, these aren’t a very useful way of creating links to programs. Shortcuts have their program arguments built into them. You can’t add options on a command line to a shortcut. Surprisingly, the way forward is to step back. What does work well is ancient batch files. Create a shortcut_name.bat file and put your favorite program (and the full path to it) in the file. Add %* after the program name to include any command line parameters. Then you can do:
C:\> shortcut_name arg1 arg2 ...to run your favorite program from anywhere.
Name conflicts are solved by giving your shortcut_name.bat files different names. They’ll run programs of the same actual name but from different directories. Easy.
You even get another of the advanced features of GuiCmd – you can include standard args you commonly use inside the batch file and have different "commands" ("shortcut_name.bat" s) for variations of the same command.
Permanently Setting the PATH variable
To add your directory to the PATH and have Windows remember it:
- Open Windows Explorer
- Find the "My Computer" or "This PC" icon
- Right-click it
- Choose Properties
- Click "Advanced system settings"
- Click "Environment Variables…"
- Click on PATH then "Edit…"
- Add your directory to the end (use ";" as a separator if there’s already directories present)
- Click Ok as required and you’re done.
I hope this helps. I’m find it a practical alternative to adding yet another directory to the PATH every time I add another tool to my collection. It’s one place to find where the tools are. One place to update if a tool changes. Easy.
