#!/usr/bin/xbasicProgramDirWalkOnTheWildSide' Can match all symbolic links with "s *" etc.' TODO Convert this nasty NFA to an optimized DFA at run timePatterns$()=["*temp","*tmp","*sql*-v*","*.mgr"]Patterns$()=["*.wav","*.mp3","*.ogg","*.amr","*.fla","*.flac"]Patterns$()=["*.bas","*.b","*.cgi"]PMFlags%=16!CaseinsensitiveGLOB()matchingAllDirs$()=["d /"]!LookingforadventureMatches$()=["B0rk"]!InwhatevercomesourwayDirCount%=1MatCount%=0CurDir%=0WhileCurDir%<DirCount%ClrP$,F$,S%P$=AllDirs$(CurDir%)PrintCurDir%,"'";P$;"'"S%=InStr(P$," ")' Print "FindFirst '"; Mid$(P$, S% + 1, Len(P$) - S%); ; "'"' Pause 0.1ClrF$' Compiled code apparently doesn't like error handlers?' On Error ContOnErrorGoSubMulligan!WegetoneMulliganperdirectoryF$=FSFirst$(Mid$(P$,S%+1,Len(P$)-S%),"*","dfa")' If Len(F$) Then' ' Use up our Mulligan if it's still unused' Print 0xDEADBEEF / 0; Chr$(13);' EndIfIfLen(F$)=0Then!No-opElseIfLeft$(P$,2)="d "Then!No-opElseIfLeft$(P$,2)="s "Then!No-opElsePrint"Weird dir '";P$;"' contains files like '";F$;"'"Pause5EndIf' Discard the path's "d " or "s " prefixP$=Mid$(P$,S%+1,Len(P$)-S%)WhileLen(F$)S%=InStr(F$," ")F$=Left$(F$,S%)+P$+Mid$(F$,S%+1,Len(F$)-S%)' Print "'"; F$; "'"' Pause 0.1ClrWeHaveAContendah%,i%Fori%=0To(UBound(Patterns$())-1)IfGlob(F$,Patterns$(i%),PMFlags%)ThenWeHaveAContendah%=True' Is early exit just GOTO in drag?' Would Dijkstra not like this?' Break' Exit ForEndIf' Exit If WeHaveAContendah%Nexti%IfWeHaveAContendah%ThenDimMatches$(MatCount%+1)Matches$(MatCount%)=F$IncMatCount%Print"Match ";MatCount%;" found '";F$;"'"' Pause 0.2EndIfIf(Left$(F$,2)="d ")!Or(Left$(F$,2)="s ")Then!DONOTFOLLOWSYMLINKS' Directory, or symbolic link to maybe a directory?' Could following symlinks cause an infinite loop? How to detect?IfDirCount%=UBound(AllDirs$())Then' Hundreds of thousands of subdirectories!!!1!Print"REDIM PRESERVE AllDirs$(";DirCount%+(DirCount%Div8)+4;")"DimAllDirs$(DirCount%+(DirCount%Div8)+4)EndIfAllDirs$(DirCount%)=F$+"/"IncDirCount%ElseIf(Left$(F$,2)="- ")Then' Ordinary file!No-opElseIf(Left$(F$,2)="s ")Then' Symbolic link, can we find out what it points to?!No-opElse' We found something new!DimMatches$(MatCount%+1)Matches$(MatCount%)=F$IncMatCount%Print"Weird ";MatCount%;'" found "; F$; "'"Pause5EndIfClrF$' Is FSNEXT also prone to throwing exceptions? YES IT IS!Print"Calling FSNEXT ";F$="! UNKNOWN"OnErrorCont!GoSubMulliganF$=FSNext$()PrintF$WendIncCurDir%WendPrintUBound(AllDirs$()),DirCount%,MatCount%Fori%=0To(MatCount%-1)!Needsparensorit's a syntax errorPrinti%,"'";Matches$(i%);"'"Nexti%PrintMatCount%;" match(es) found."Print"OK"EndDefFnSubStr$(S$,First%,Last%)=Mid$(S$,First%,Last%-First%+1)ProcedureMulligan()Print"Oopsie ";E%=ErrPrintE%;" ";Err$(E%)SelectE%Case0!Dividebyzero,not"all is well"!No-opCase-13!Permissiondenied!No-opCase-33!Filenotfound(symlinktomissingfile/dir?)!No-opCase-20!Notadirectory(symlinktoordinaryfile?)!No-opDefaultStopEndSelect' Pause 0.5' Resume NextReturn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also see it in Windows 8.1 64-bit 6.3.9600 with the July Important patches installed but not the optional 2019-07 Preview of Monthly Quality Rollup for Windows 8.1 for x64-based Systems (KB4507463)
It could be the bug is in my code somehow, or FSFIRST/FSNEXT don't like "/" or "\" in Windows, or perhaps they need "C://" in order to indicate directories properly in the returned string instead of just "C:/"
Last edit: Yet Another Troll 2019-07-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think, on WINDOWS, the root path "/" does not exist. So "d /" will cause that error.
However it probably defaults to something (like "C:/" or the current directory).
Have you tried to use "d C:/" on windows?
IF WIN32?
AllDirs$() = [ "d C:/" ] ! Looking for adventure
else
AllDirs$() = [ "d /" ] ! Looking for adventure
endif
Last edit: Markus Hoffmann 2019-07-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The first call to FSFIRST sort of succeeds, and the names of the files and directories in the root of the current drive, in this case C:, are found. It's just whatever is checking for -, d, or s that fails. I'll keep playing with it and/or finally dig into the sources. Thanks for looking at it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In a cmd window, DIR \ will list the root directory of the current drive. VB/VBA's Dir$ works similarly, so I expected FSFIRST/FSNEXT to also work like that,
Microsoft Windows [Version 10.0.18362.239]
(c) 2019 Microsoft Corporation. All rights reserved.
C:\Users\trollollio>dir \
Volume in drive C has no label.
Volume Serial Number is F696-BB0C
Directory of C:\
10/29/2015 10:47 PM 24 autoexec.bat
10/29/2015 10:47 PM 10 config.sys
04/25/2016 01:33 PM <DIR> Intel
02/13/2016 05:19 AM <DIR> Logs
03/18/2019 07:46 PM <DIR> PerfLogs
07/18/2019 10:29 AM <DIR> Program Files
06/13/2016 01:08 AM <DIR> TEST_TOOL
07/18/2019 10:02 AM <DIR> Users
07/26/2019 06:40 AM <DIR> Windows
01/17/2018 03:55 PM <DIR> Windows10Upgrade
2 File(s) 34 bytes
8 Dir(s) 12,868,653,056 bytes free
C:\Users\trollollio>
Still, I may be better off inspecting environment variables like SystemRoot, ProgramData, ProgramFiles, and UserProfile to derive a list of drives to search, in case of a customized Windows installation spread amongst multiple drives or partitions. Such things were possible in the NT days and maybe still are.
Last edit: Yet Another Troll 2019-07-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
They also appear to throw error -33 on every call but still return something if the error is caught or ignored.
The code,
...but the stepdir.bas sample does sometimes recognize subdirectories if root$ = "C:\"
I'll do more testing.
I also see it in Windows 8.1 64-bit 6.3.9600 with the July Important patches installed but not the optional 2019-07 Preview of Monthly Quality Rollup for Windows 8.1 for x64-based Systems (KB4507463)
It could be the bug is in my code somehow, or FSFIRST/FSNEXT don't like "/" or "\" in Windows, or perhaps they need "C://" in order to indicate directories properly in the returned string instead of just "C:/"
Last edit: Yet Another Troll 2019-07-23
I think, on WINDOWS, the root path "/" does not exist. So "d /" will cause that error.
However it probably defaults to something (like "C:/" or the current directory).
Have you tried to use "d C:/" on windows?
Last edit: Markus Hoffmann 2019-07-25
The first call to FSFIRST sort of succeeds, and the names of the files and directories in the root of the current drive, in this case C:, are found. It's just whatever is checking for -, d, or s that fails. I'll keep playing with it and/or finally dig into the sources. Thanks for looking at it.
In a cmd window, DIR \ will list the root directory of the current drive. VB/VBA's Dir$ works similarly, so I expected FSFIRST/FSNEXT to also work like that,
Still, I may be better off inspecting environment variables like SystemRoot, ProgramData, ProgramFiles, and UserProfile to derive a list of drives to search, in case of a customized Windows installation spread amongst multiple drives or partitions. Such things were possible in the NT days and maybe still are.
Last edit: Yet Another Troll 2019-07-26