#139786 - 2005-05-1709:48 PMRe: Unexpected behavior in DIR() in v4.22
NTDOCNTDOC Administrator
Registered: 2000-07-28
Posts: 11634
Loc: Space
Well Jim,
On a side note. This appears to have been the behavior now for at least 5 or 6 years now according to some of the articles found. I know it has been this way for XP (which is now many years old) not sure how true it is/was for the older Windows OS though.
#139787 - 2005-05-1709:55 PMRe: Unexpected behavior in DIR() in v4.22
jtokachjtokach
Seasoned Scripter
Registered: 2001-11-15
Posts: 513
Loc: PA, USA
You agree with it?
Surprizing it took this long to surface. Regardless, I have to go back through all my scripts to see where is use this. I can't change this key on all of our existing workstations and servers not to mention insure that it'll be set on new one coming in. IMHO, Dir() without support for this is useless.
_________________________
-Jim
...the sort of general malaise that only the genius possess and the insane lament.
Jim I totally agree. During all this, I just kept saying to myself, "No one noticed this?" and "Microsoft thinks this is acceptable?"
I don't guess I've noticed it because when I rename files I usually do it like this: file.txt.old, and for some reason the dir and del works properly with it formatted that way. Regardless, it is a frying pan full of grease... way to easy to make mistakes with it the way it is right now.
Registered: 1999-05-06
Posts: 391
Loc: Amsterdam, The Netherlands
I'm afraid this is not something I can change in KiXtart itself. The various file-related functions in KiXtart al rely on the relevant Win32 API's (most importantly, FindFirstFile and FindNextFile). It's the behaviour of these API's that was changed (long ago now).
Note that this functionality (and if/how to change it) has been discussed at length, and the people responsible decided that changing it again would be too complicated (note that as a result of long filenames there really isn't a good allround solution) as well as too risky as far as compatibility is concerned.
I guess in theory, I could add some sort of filter on top of the API's to perform additional checks, but this would just shift the hideously complicated task of somehow solving the issue while still maintaining compatibility to me. I'm always up for a challenge, but this one is really outside the boundaries of KiXtart.
Although the registry setting maybe isn't perfect, I'm really think it's the best way to address this issue.
#139790 - 2005-05-2506:14 PMRe: Unexpected behavior in DIR() in v4.22
jtokachjtokach
Seasoned Scripter
Registered: 2001-11-15
Posts: 513
Loc: PA, USA
Ruud, I don't see this as being outside of the boundaries of KiXtart. I see this as another oppurtunity for KiXtart to define itself as the best solution administrative scripting.
I firmly stand by the belief that accuracy is paramount. When it comes to automating these tasks, I need to be assured that the results I expect of an explicitly defined command are exaclty what I get. One could argue that given the new API's, I am getting what I ask for, but we all know that is not the case (historically). For most of us, this has seemed to have gone un-noticed for several years, but I don't think that adds weight to the counter argument. This was recently brought to my attention in the application I was writing where Dir(*.xml) delivered disasterous results.
Of course we can resort to UDF's, but then what's sense in even having any base language commands if that's always going to be the solution?
In summary, I think that this would be a worthy addition to Kixtart for all the above reasons.
(Brought to you by: Jim for President 2008 - Rock the Vote Man!)
_________________________
-Jim
...the sort of general malaise that only the genius possess and the insane lament.
