From: NickCupery
| The plot thickens. I emailed my lousy shortcut to Rex (I thought),
| but that didn't work. What he really received was the .BTM file
| itself, not the shortcut to it. At first I figured this was just a
| case of my Mozilla Thunderbird being too smart for its own good.
| However, after running a few additional experiments this morning, I
| conclude that there is much more to it than that. Here's what I
| tried:
|
| I made a copy of another of my .BTM batch files (that expects a drive
| letter as the %1 argument), naming it aardvark.btm (I am allergic to
| scrolling).
|
| Then I right-dragged aardvark.btm onto my Desktop, and selected
| "Create Shortcuts Here" from the popup context menu.
|
| Then I looked at my Desktop folder with Windows Explorer and it
| showed aardvark.btm while a DIR of the same Desktop folder showed
| aardvark.btm.lnk
| (which I thought a strange discrepancy but not real serious).
|
| Then I tried creating a copy of the shortcut with a different
| file-type, so I could
| examine and email it. So I typed:
|
| COPY aardvark.btm.lnk aardvark.dat
|
| and the response I got was:
|
| TCC: (Sys) The system cannot copy the file specified
|
| So, I'm then thinking "the system sure is real proud and protective
| of these
| stupid shortcuts" so I ran a couple more renaming experiments:
|
| I used Windows Explorer to rename (what it claimed was) aardvark.btm
| to
| aardvark2.btm after which I again used DIR to verify that it saw
| aardvark2.btm.lnk WHICH IT DID NOT. Dir still saw aardvark.btm.lnk
| which I really didn't expect! However, I had rerun DIR from the same
| TCC console
| session as before (up-arrow, Enter), so I became suspicious of some
| sort of caching, so:
|
| I then closed the TCC console, and then opened another one, and then
| did another DIR and viola! Now DIR saw aardvark2.btm.lnk as expected.
| (Rex, is TCC really caching directory information? I don't think it
| should do that.)
|
| BOTTOM LINE: I'm still confused and maybe even slightly dizzy from
| all this.
|
| HOWEVER, I just now thought of something that may be relevant. I have
| been
| running with "CmdHere Powertoy for Windows XP" for so long that I had
| forgotten
| about it. Do any of you guys have any negative experiences with that?
| When I invoke it (right-click on a folder and select it), I get a CMD
| console window, not a TCC console. Hmmm, now I'm wondering why TCC
| doesn't offer such shell integration, because 4NT did. Maybe that
| option is burried in the trillion other capabilities of TCC?
|
| I badly need to get back to work for a while, but please be assured
| that I am
| very grateful to all of you who have shown some interest in this
| problem!
Undoubtedly you selected "hide known extensions" in how Windows Explorer displays filenames (BTW, so do I). That's why the filename of a desktop icon showed "XX.BTM" instead of "XX.BTM.LNK" - the actual filename. When you renamed using WE, the same continued.
Remember also, by default DIR will not display HIDDEN files. Conversely, you probably selected to display hidden and system files in WE (same here), thus DIR will not show your XX.BTM.LNK, but WE will.
You can force TCC.EXE to be your default command processor by changing the system variable ComSpec to point to it, instead of pointing to CMD.EXE, but beware! Some programs call CMD.EXE directly, without using the ComSpec variable - the only way to fool them is to replace CMD.EXE with TCC.EXE. Furthermore, some programs may need undocumented "features" of CMD.EXE which are not duplicated in TCC.EXE - they may not perform correctly.
--
HTH, Steve