Extended KotD #10: _FILES$

[SMcNeill]

As we work our way backwards to cover our newest keywords in the language, we start to move back to version 3.11, where _FILES$ was added fro us.  At first, I thought this would just be a quick show-n-tell type entry in our list of KotD, but it seems like I was mistaken.  There's actually several points that need to be brought up and emphasized that everyone needs to be aware of with this newest way to get a file listing.

First, let's cover the fact that _FILE$ is a dual-usage command.  One has to use it for two very distinct uses inside their code, for it to be very functional at all.

First, _FILES$ must be called once, to set the type of files that one is looking for.  This isn't a hard step, but it's an essential one:

Code: (Select All)

x$ = _FILES$("*.bas") 

The above is all that's needed to set the Path and types that we're looking for.  For the above, it says that we basically want to get a listing of all the files that end with a ".bas" extension, and since we didn't specify the path, we want to use the Current Working Directory (_CWD$).

If we wanted to get a listing of all txt files from the "C:\My Documents\" folder, we'd want to call _FILE$ with those options to set the path and directory.   Basically:

Code: (Select All)

x$ = _FILES$("C:\My Documents\*.txt")

---

Now note that this first use of _FILES$ is to set the path and type of what we're looking for.   After this, we can now call _FILE$ -- with no parameters -- to get back the files that meet those options for us, one at a time, until we come back with a null string. 

The way this looks is basically:

Code: (Select All)

x$ = _FILES$("C:\My Documents\*.txt")
DO  UNTIL x$ = "" 'repeat until we get a null string response
    PRINT x$ 'display the file name we get back
    x$ = _FILES$ 'no param needed here
LOOP

It's honestly that simple, and I was thinking at first that the above would basically be all that one would need to be able to use the command properly....

HOWEVER....

There's one more important issue that I need to stress for folks, or else things may not end up performing as they'd expect them to!

---

---

Let's now take a moment to back up into the ancient past of coding.  Back all the ways to the days of DOS and GWBASIC and QB45...  Back, into the dim recesses of history, when the skies were still dark swirling masses of energy and the universe was just forming.  Back... GASP.... even before the internet existed!!   LONG... LONG... LONG AGO....

A lot of our user base problably remembers those days quite well.   

Back in those days, one would type something into the commnad line such as:

Code: (Select All)

DIR *.*

And, from that code, they'd get a listing of ALL their files and folders.  That star (the * symbol) represented a wildcard which meant <anything>, so "*.*" was a search for a file named <anything> with an extension of <anything>...  in otherwords, "*.*" represented EVERYTHING.

DIR *.* would give you a listing of ALL files and folders for the ciurrent directory.

---

And with that history out of the way, let's move forward in time a bit, to when those 8-character filenames became obsolete.  At some point in time, we started to be able to use 256 character long file names.   And then, as folks wanted even more characters, we even expanded beyond that to 65,535 character file names (in some cases/formats).

No longer were files limited to juse being <name> <dot> <extension>.   You could now write and create a file and call it "My.dot.filled.file.txt", if you wanted too, and the OS and your hard drive didn't care!!

---

And keeping those two points in mind, how do you think that's affected _FILES$ and how it behaves now??

Let me sidetrack for a second, before answering that, to ask, "What do you think you'd get if you did the following:"

Code: (Select All)

DIR *e*

With the modern limits on file names, wouldn't the above basically be <anything> <then an e> <anything>.... So it's basically a search for any file or folder that has an "e" in it.

Now, to back back up, let's ask, "What do you think you'd get if you do the following:"

Code: (Select All)

DIR *.*

And this one is a little trickier to answer.  Some legacy routines will do like it used to do ages ago and list ALL files and folders.  Some of the newer routines will filter it, just as they would with that "*e* -- it'd give you a list of files WHICH INCLUDE A DOT IN THEM!!

To highlight this difference, let's take a moment to look at a file list.  Pretend this is my drive:

Code: (Select All)

C:\
C:\Temp\
C:\Temp.Stuff\
C:\temp.txt

Now, according to legacy rules, DIR *.* would list:

Code: (Select All)

C:\
C:\Temp\
C:\Temp.Stuff\
C:\temp.txt

But accoring to modern tules, DIR *.* would list:

Code: (Select All)

C:\Temp.Stuff\
C:\temp.txt

Notice that C:\ and C:\Temp are missing from the modern way of processing *.*??  It's because they have no DOT in their filename.

---

"*.*" isn't what it used to be.  It no longer represents a file named <ANYTHING> and an extension named <ANYTHING>.

"*.*" now represents <a DOT with ANYTHING before it and ANYTHING after it>.

And that's an important distinction for folks to realize, when using _FILES$, as _FILES$ uses this more modern interpretation of the command syntax.

If you want a list of <EVERYTHING>, the easiest way to get this with the modern ruleset is to simply

Code: (Select All)

x$ = _FILE$("*")

Notice you're just looking for *  (<ANYTHING>), and not *.* (<ANYTHING before><DOT><ANYTHING after>).

This is a very important difference and something that everyone should note.  Don't use "*.*" just because you're on old foggie like Steve, who got used to that in the age of the dinosaurs of programming.  If you want a list of ALL files, just use "*" for your search limiter.

[bplus]

+1 this is useful when i get around to trying out this _files$ keyword