mIRC Home    About    Download    Register    News    Help

Print Thread
#73932 05/03/04 11:04 PM
Joined: Mar 2004
Posts: 2
D
dycero Offline OP
Bowl of petunias
OP Offline
Bowl of petunias
D
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

#73933 05/03/04 11:08 PM
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
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
#73934 05/03/04 11:15 PM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
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.
#73935 06/03/04 03:15 PM
Joined: Mar 2004
Posts: 2
D
dycero Offline OP
Bowl of petunias
OP Offline
Bowl of petunias
D
Joined: Mar 2004
Posts: 2
in mirc 6.12 it replyed c:\progr~1\mirc\ for shortfn()

#73936 07/03/04 12:29 AM
Joined: Oct 2003
Posts: 101
Vogon poet
Offline
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.

#73937 07/03/04 01:42 AM
Joined: Sep 2003
Posts: 4,230
D
Hoopy frood
Offline
Hoopy frood
D
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)

#73938 07/03/04 02:34 AM
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
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!
#73939 07/03/04 09:19 AM
Joined: Sep 2003
Posts: 4,230
D
Hoopy frood
Offline
Hoopy frood
D
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)

#73940 07/03/04 10:14 AM
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
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!

Link Copied to Clipboard