|
|
Joined: Mar 2004
Posts: 2
Bowl of petunias
|
OP
Bowl of petunias
Joined: Mar 2004
Posts: 2 |
$shortfn($mircdirsystem) - mIRC version: $version C:\Program Files\mIRC\system - mIRC version: 6.14
see its not working in 6.14
|
|
|
|
Joined: Jan 2003
Posts: 2,523
Hoopy frood
|
Hoopy frood
Joined: Jan 2003
Posts: 2,523 |
$shortfn(input) returns the input itself if that input is not an existing file/directory. It has always been like that so I don't think it's a bug, but I might be wrong.
/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
I'm not sure if it's a bug as such, but I do think it should return $null if the folder doesn't exist.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
Joined: Mar 2004
Posts: 2
Bowl of petunias
|
OP
Bowl of petunias
Joined: Mar 2004
Posts: 2 |
in mirc 6.12 it replyed c:\progr~1\mirc\ for shortfn()
|
|
|
|
Joined: Oct 2003
Posts: 101
Vogon poet
|
Vogon poet
Joined: Oct 2003
Posts: 101 |
$shortfn shortens a filename by a certain standard. As far as I know, it was never intended to verify if a file or folder exists. Thats why there is $exists.
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
Hoopy frood
Joined: Sep 2003
Posts: 4,230 |
thats inpracticale to say, the only way you can get the shortfilename of a file is by requesting it form the OS, you cant just say, if it was this then it well be that since thats not how there made.
under your logic $shortfn(blah1234567890a.txt) => blah12~1.txt $shortfn(blah1234567890b.txt) => blah12~1.txt
well heck they both cant be the same file!
ps i have seen some completely whacked short filenames, that dont seem to match the long one at all, also i wont ever store a short filename as i dont think NT at least actually stores a shortfilename (i might well be wrong about that, but why risk it)
|
|
|
|
Joined: Feb 2003
Posts: 2,812
Hoopy frood
|
Hoopy frood
Joined: Feb 2003
Posts: 2,812 |
NT does store both "short" (ISO 9660) and "long" (Joliet) filenames, as do all Win32 OS's. It should be noted that both filenames may be completely different from eachother, though, they normally follow the ABCDEF~1.EXT convention.
- Raccoon
Well. At least I won lunch. Good philosophy, see good in bad, I like!
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
Hoopy frood
Joined: Sep 2003
Posts: 4,230 |
I didnt word that at all well, I ment to say the short filename isnt handled with any care by the OS, take this for example
3 files are created in this order. Blah1234567890b.txt then Blah1234567890a.txt then Blah1234567890c.txt
using dir/x you get 07/03/2004 02:44p 0 BLAH12~2.TXT blah1234567890a.txt 07/03/2004 02:43p 0 BLAH12~1.TXT blah1234567890b.txt 07/03/2004 02:44p 0 BLAH12~3.TXT blah1234567890c.txt
now move the files to another folder by dos or windows and dir/x gets 07/03/2004 02:44p 0 BLAH12~1.TXT blah1234567890a.txt 07/03/2004 02:43p 0 BLAH12~2.TXT blah1234567890b.txt 07/03/2004 02:44p 0 BLAH12~3.TXT blah1234567890c.txt
I have seen the same effect within one folder, but I cant reproduce it myself, but as i say, why take the risk.
Use $shortfn() but never rely on that filename being maintained from one script event to the next (possably one moement to the next, depending if something else is playing with the file as well)
|
|
|
|
Joined: Feb 2003
Posts: 2,812
Hoopy frood
|
Hoopy frood
Joined: Feb 2003
Posts: 2,812 |
ah, yes.. you are correct in that point. one should never assume the shortfn will remain the same, especially if it has been moved to another directory. Windows generates a new shortfn on every rename move and copy. This is another reason why mIRC slows a bit if your log directory gets too large... as Windows attempts to find a shortfn to give to a new log, it looks for the next available number, also filling in gaps.
#MIR~830.LOG
Well. At least I won lunch. Good philosophy, see good in bad, I like!
|
|
|
|
|
|