followlnks - Find Windows Shortcut Targets

[TheAsterisk!]

followlnks is a (relatively) simple Bash script I've written up which finds all the Windows shortcuts it can under a user-specified directory and finds each shortcut's original target, albeit in terms of the original Windows file system. It prints the list of shortcuts and their targets into two text files. (The specifics can be found in followlnks simple man page.)
The aim is to provide a little help if someone (like me ) was sloppy and ditched Windows but not its shortcuts, and now wants to clean up and switch them out for symlinks. Knowing the old targets helps.

The two text files' line numbers correspond to one another - line "n" in the file that lists the *.lnk files' locations correspond to the Windows path in line "n" of the targets text file.

followlnks (with an 's') will search recursively and handle multiple shortcut files at once. This is most useful for big messes and general sloppiness.
followlnk (without any 's') examines only one shortcut file at a time and you need to know its location already. This is more useful if you stumble across the odd, lone *.lnk file and get curious.

UPDATED - Current version of followlnks is 20110103.
Changed from searching /mnt and /root to prompting the user for a path. Fixed a spelling error in an echo, too.
followlnks-20110103.pet

UPDATE - I will keep followlnk available, but disciple's suggestion to use lnk-parse instead in the next post is a good idea. I'd recommend that instead.
followlnk-20101025.pet

md5sum.txt

If you need to know all of this again, I did include a simple man page for followlnks, but not for followlnk.

followlnks-20101113.pet is about 1.8 KB as a package, and about 40 KB installed.
followlnk-20101025.pet is roughly 0.5 KB as a package, and maybe 16 KB installed.

Read the man page before using followlnks. There are a few things you don't want to do. It won't hurt anything, but for instance checking Windows system directories or the program installation directories doesn't return reliable target information.
A simple HTML page should open in your default browser upon installation with some more information.

[disciple]

Interesting. For most of my .lnk files it returns the windows path of the folder the target is in. For a very few it returns the full windows path, and for some it returns nothing! I imagine it would ignore any command line arguments in the .lnk as well.

You might be interested in the script at http://jafat.sourceforge.net/files.html for parsing .lnk files. Its output looks like it might be complete, and the README file references a "specification" document for .lnk files.

You might also be interested to know there was a patch for the 2.4 kernel to actually use .lnk files for symlinks on FAT partitions

[disciple]

You might be interested in a script to open .url files as well http://www.murga-linux.com/puppy/viewto ... 5921#75921

[TheAsterisk!]

Cool. I'll check it out. Thanks disciple! Maybe that'll work better- my script is admittedly a bit hacky.

I've always been able to open *.url files as plain text and just view the target URL that way, so they're not as much trouble as *.lnk files, which can't be read as text.

EDIT: lnk-parse works quite nicely, but its advantage of additionally returning a relative path is negated by my unique circumstances.

Firstly, most of the *.lnk files I wanted to clean up weren't on NTFS partitions, and whether a bug or known limitation I couldn't get lnk-parse to return relative paths on anything but an NTFS partition. I kept Windows XP's "My Documents" folder on a second hard drive- "D:\" I suppose. To make matters worse, at one point I changed the second drive's letter to S, another time to W, though I can't remember whether or not I had a good reason. A month or two ago I upgraded my second hard drive from 80 GB to 400 GB (it was actually the cheapest larger drive I could order, believe it or not), formatted it as ext3, and transfered everything from the older to the newer. On this partition, either because I meddled with everything so much or because it's an ext3 partition, lnk-parse only returns absolute paths, more or less just like followlnk(s).

So to summarize: all the *.lnk files I'm after are disorganized, point to nonexistent partitions, are on a non-Windows partition, target drive letters C, D, F, S, W, and (in one isolated instance) T. Some point to personal document and directories, others to customized Start Menu entries, etc. I did say I'd made a big mess.

On another computer set to dual-boot XP Pro and Puppy 431, though, it handled everything on the NTFS partition admirably. In that case, its results were better than followlnk, by far. lnk-parse also returned lots of other information which could be useful to others, but not me in this case. I didn't try it on FAT at all, but it might be better there, too, on account of those being Windows-usable partition formats.

I still like followlnks (with an 's') since I can do it in one sitting, but lnk-parse is very nice for processing one *.lnk file at a time, even more so on an NTFS partition, so thanks for the tip. With all the searching I did, I never found that nifty little perl script until you tossed that link my way, so thanks!


I had an idea, though. I went and tested followlnks on a whole, intact Windows partition where XP was actually installed. It seems that as soon as followlnks looks into the various system folders, it becomes unreliable- targets and *.lnk file locations don't show up on corresponding lines, or sometimes the targets don't even get output.
Hmm...
I suppose a stopgap would be for me to make followlnks work from ./ rather than from /mnt and /root, and to just have the user navigate to their "My Documents' or "Desktop" folders or whatever before the script is run instead. That, or I could prompt them to enter a path, and warn not to check the whole partition.
In any case, running from /mnt and /root doesn't seem smart if anyone keeps/kept their files on the same partition they've installed Windows to (as many do), so I suppose I should revise the script. I'll edit my first post to reflect that once I've done it.