Clean Up Your Shortcut Names

The default naming scheme for Windows shortcuts can be irritating at times. Depending on which version of Windows you're using and the system options you've chosen, the shortcut name might include the word "shortcut" to show that it's a shortcut and a file extension. However, this additional text doesn't add meaning and can possibly cause problems. To avoid lengthy and potentially problematic shortcut names, you can make a registry change so that Windows starts creating clean shortcut names and use a short script, CleanShortcutName.vbs, to clean up existing shortcut names.

How Windows Names Shortcuts
By default, when you create a new shortcut to a file or folder, Windows uses the following process to create a shortcut name. First, Windows starts with the filename as displayed. I emphasize that it's as displayed because if you have Windows customized to show extensions for known file types—which is common for administrators and power users—the file extension is included in the root name. For example, if Windows isn't showing extensions for known file types (the default setting), the name for a shortcut to cmd.exe starts out as simply "cmd". If Windows is configured to show extensions, the name starts out as "cmd.exe". Next, Windows adds "Shortcut to " (note the trailing space) at the beginning of the root name on Windows Server 2003 and earlier and adds the suffix " - Shortcut" (note the leading space) on Windows Vista and Windows Server 2008. Finally, although it's never displayed in Windows Explorer, Windows adds the shortcut extension, .lnk, to the end of the name. (The .lnk extension is never displayed in any name, no matter what the settings are for displaying Windows extensions). On an English-language Windows version, this process gives you one of the following display names for a shortcut to cmd.exe, depending on the version of Windows and what customizations you've made:

The main reason why Windows names shortcuts this way by default is that, in theory, the "Shortcut to " prefix or the " - Shortcut" suffix makes it clear to users that they're using a shortcut. However, in reality, the prefix or suffix isn't really necessary. Consider the program listings in the Windows Start menu. Most all of the program listings are shortcuts to files, but they don't include the "Shortcut to " prefix or the " - Shortcut" suffix. When users are searching through this list of programs, I doubt whether they get confused because the shortcut names don't include the word "shortcut".

Also consider that if the Start menu did include the word "shortcut" in the shortcut names, it would introduce a lot more text. The additional text would force the cascading menus to be much wider and take up more desktop space when displayed. The same holds true for shortcuts that you create: the prefix or suffix doesn't add meaning. It just adds additional text that might cause shortcut names to be truncated in Windows Explorer or other Windows views.

Similarly, including the target file's extension (e.g., .exe, .doc) in the shortcut name isn't really necessary. When you're looking for a shortcut, you likely already know what kind of file the shortcut will open. So, an .exe or .doc extension in the shortcut name doesn't add meaning—it only adds additional text. Plus, the file extensions might not be consistently applied to the shortcuts you create. The names of the shortcuts you create while file extensions aren't displayed will differ from the names of the shortcuts you create while file extensions are displayed—and shortcut names don't automatically change if you change the file-extension setting.

For these reasons, a common shortcut preference among administrators and power users is to simply have the shortcut name be the root name of the target file, without the word "shortcut" or target file's extension. That way, shortcut names are easy to read and they're less like to get truncated in displays.

Changing How Windows Names Shortcuts
To clean up your shortcut names, you first need to change Windows' default shortcut-naming behavior by modifying the registry. On a per-user basis, you can eliminate the "Shortcut to " prefix or " - Shortcut" suffix on all Windows versions from Windows 95 through Server 2008 by modifying the registry entry named link located under HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorer. Link contains a 4-byte binary value. Simply change it to 00 00 00 00. Windows is immediately aware of this setting, and any new shortcuts you create use the display name for the shortcut target as the shortcut's default filename.

Modifying the registry is sufficient for creating clean names for new shortcuts as long as Windows is configure to not display file extensions. If file extensions are displayed when shortcuts are created, the shortcut name will still include target file's extension.

Cleaning Up Existing Shortcut Names
Changing the link registry entry doesn't do anything about cleaning up the shortcuts that already exist. To handle that situation, you can use the CleanShortcutName.vbs script. To get CleanShortcutName.vbs, click the Download the Code Here button at the top of the page. You can run the script simply by dragging and dropping shortcut files onto the script's icon. If you want to clean the names of an entire set of shortcuts at once, you can use the script from the command line either by supplying shortcut file paths as arguments or by piping them into the script as in this example:

dir /s /b "%AppData%MicrosoftInternet ExplorerQuick Launch*.lnk" |
  cscript CleanShortcutName.vbs

Although this command wraps here, it is a single line. Note the use of the CScript keyword and the script's extension. These elements are necessary because of a bug in cmd.exe. As another way of getting around this bug, I've provided a wrapper script named CleanShortcutName.cmd to simplify using the script from a command line. If you save the CleanShortcutName.cmd file in the same directory as CleanShortcutName.vbs, you can use

dir /s /b "%AppData%MicrosoftInternet ExplorerQuick Launch*.lnk" |
  CleanShortcutName

to run the script from the command line. Again, this command should be on one line.

CleanShortcutName.vbs strips off the generic shortcut prefix or suffix on all versions of Windows. The script also attempts to eliminate file extensions from the shortcut name. Thus, a shortcut file named "Shortcut to cmd.exe" will be renamed to "cmd".

There are limits to what the script does. If the script can't locate the shortcut target—for example, if it's on an unavailable network drive—the script leaves the file extension alone. CleanShortcutName.vbs also doesn't change shortcut names if doing so would overwrite an existing shortcut. For example, if you have a shortcut named "Shortcut to cmd.exe" and one named "Shortcut to cmd.vbs," the script renames the first shortcut to "cmd" and leaves the second shortcut alone. Similarly, if you have three shortcuts named "cmd", "Shortcut to cmd.exe", and "Shortcut to cmd.vbs", none would be changed; the script never overwrites existing shortcuts.

How CleanShortcutName Works
Listing 1 shows the CleanShortcutName.vbs script. Each significant task in the script has callout markers. To begin, the code in callout A declares the ShortcutMarkers array, which contains the shortcut prefix or suffix used on all English language Windows systems. If you're using the script on non-English systems, you might need to modify the array declaration by adding the appropriate regional values.

In callout B, I set up the COM objects I'll use throughout the script: Scripting.FileSystemObject, WScript.Shell, and VBScript's internal RegExp. There's nothing amazing about this step, but I want to draw attention to it because I willfully violate one of my standard scripting best practices by declaring them here. Typically when I write a VBScript function, I make it as self-contained as possible, declaring any objects it depends on within the function itself. By declaring the objects at the beginning of the script instead of in the functions, I make it much more difficult to reuse the functions elsewhere.

There's a reason I do it this way in CleanShortcutName.vbs. I designed this script for batch processing many shortcuts rapidly. If I set up these objects within the functions where they're used, VBScript would need to set up and tear down each object for each shortcut, which can slow down processing. For an integrated, special-purpose script such as this, setting everything up once can provide significant improvements in speed.

In callout C, the script takes filenames given to it as command-line arguments and runs the PrettyShortcutName function (which I'll discuss shortly) on each filename. If you aren't familiar with how Windows drag and drop works, Windows gets the filename for each file you drop onto the script icon and assembles them into a command line. The process is essentially the same as running the script from a command prompt with multiple filenames supplied as parameters. Nevertheless, what if you didn't provide any command-line arguments? Or what if you want to process a large number of shortcuts at once?

When you don't provide shortcut paths by either dragging and dropping or entering them on the command line, the script uses the UseInputStreamNotArguments function in callout D. If you're using CScript as the host and you didn't supply shortcut file paths on the command line, the script assumes you're piping in the filenames (i.e., reading the standard input stream). The script then runs the PrettyShortcutName function for each filename. You can't use standard input with WScript. Thus, if you're using WScript as the host and you run the script without providing any shortcut filenames through dragging and dropping, the script pops up a message telling you to drop shortcut files onto the script.

If you want to process a large number of shortcuts at once, piping them into the script is the best approach. When using CScript, the names of shortcut files that aren't renamed are automatically sent to the console's standard error stream and are displayed in the console window, giving you a list of filenames you can manually inspect and change as needed. If you provide shortcut filenames by dragging and dropping, the script can't display an error stream because WScript doesn't use the console window. Plus, the WScript host isn't the best environment for batch processing because each filename echoed requires you to click a button to allow the script to continue.

The script does the rest of its work in the PrettyShortcutName function called for each filename. The function first checks the filenames as shown in callout E, making sure they're really filenames (using fso.FileExists) and that they're really shortcuts (by confirming that fso.GetExtensionName returns "lnk").

In callout F, we finally start cleaning up the shortcut names. We have a reference to the actual shortcut file in scFile. We get the root name of this file into the variable NewName. We then check the name for any shortcut marker text and remove it if found by replacing it with an empty string. If the script doesn't find any of the extra text typically added to a shortcut name, it leaves the name unchanged.

At this point, we have only one more task to complete to finish cleaning up the filename: We need to remove the file type suffix that might have been included in the shortcut name (such as the .exe if we had created a shortcut to cmd.exe while displaying extensions for known file types in Windows Explorer). To do this reliably, I like to compare the shortcut name to its target, but by doing so we could encounter several problems. I generally don't like to suppress errors in scripts, but in this case hiding errors gives us clean code with very few repercussions, so the code in callout G turns on error suppression.

Callout H is where we find the extension for the shortcut target, then—assuming we didn't have any errors in the attempt to find the target file—we remove the extension (such as .exe) from the end of the shortcut name. The shortcut target might not be available or might be a folder instead of a file, which causes the script to skip the inner loop. Finally, the file might not have an extension, in which case we still skip the replacement. By the time we complete the callout H code, we have a clean new name for the shortcut.

By the way, you might have noticed that in callout H, I used WScript.Shell's CreateShortcut method to get access to existing shortcuts. Although its name is superficially confusing, CreateShortcut opens existing shortcuts as well as creates new shortcuts. Technically, CreateShortcut creates a shortcut object, not a shortcut file. Because you specify a filename when you use CreateShortcut, CreateShortcut populates the shortcut object data from the file if it already exists. If the file doesn't exist, CreateShortcut gives you an empty shortcut template. In either case, the physical shortcut file isn't created or modified unless you call the shortcut's Save method.

At the completion of the code in callout H, we have a cleaned-up string we can use for our name. The last step of the renaming process, shown in callout I, is to actually rename the shortcut—so far, all we've done is generate a new name. We could get an error here if the shortcut name already exists; if that's the case, the script can't rename the shortcut successfully, and the script continues to the next shortcut (if applicable).

Customize It or Use It As Is
CleanShortcutName.vbs is usable natively from PowerShell. You can also easily customize the script to suit your particular needs or preferences. For example, you can internationalize the script by modifying the ShortcutMarkers array in callout A with text used on non-English versions of Windows. Or you might want to retain file extensions in the shortcut names. To do this, just comment out all of the lines in callout H (i.e., insert a single quote at the beginning of each line). As is, however, CleanShortcutName.vbs creates names that look much more like the relatively clean shortcut names you see on the Start menu.