COMMAND$ and wildcards on files

[SpriggsySpriggs]

It still feels like it is easier to have all those files already provided to you by the logic of COMMAND$ rather than trying to build your own recursion. I think a user expects that if they supply *.* then it means all files. Unless there is something special you're trying to do with that.

[mdijkens]

Disagree
I'd rather have wildcards myself. Only I as the programmer knows what I want to do with it.
Maybe it's a parameter to specify what files are allowed to be supplied in the Ui. 
Maybe it needs to search for files on all disks all directories
Maybe we want to wait for new files to appear somewhere sometime
Maybe ...

[SpriggsySpriggs]

Well, there's also the option of defining your own switches and keywords for your program's arguments.

[mnrvovrfc]

The shell does what most users expect. Few people run "7z.exe" on Windows console, because it has other-wordly behavior with wildcards which is considered normal on Unix and descendants. For example, 7-Zip command-line program doesn't like "*.*", it prefers just "*" and warns about it in the manual.

Handling "*.*" especially should be to avoid system files. It should be also for reckless algorithms that expect a text file but is given a binary file instead and chokes on the multitude of ASCII0. But a program that employs such a scheme should be reserved for people who dedicate their time to breaking stuff instead of enjoying a game or a movie, accepting results of a computation, "safe and secure" for the administrator etc.

[zaadstra]

Sorry for appearing to have bailed out here  

The parsing of the wildcards was an unexpected surprise to me.  In fact, it should not be a problem, I did code a loop over the COMMAND$ arguments.  Thing is, if I run the command

stamp.exe *.*

it shows all files and folders, but I cannot see what files and folders are. Unless I start testing with _FILEEXISTS etc.
The folders I need to process separately (and recursive) which I was trying to avoid by a smart command.  Only if the -R flag is specified. I cannot smart pass the -r flag to the QB64 command$ input.
As I want to read seconds of the files's date stamp I finally resorted to an external ls.exe tool. The plan was to feed the ls tool with the proper arguments and have a proper list in one go, and then I needed the asterisk to be in place.
I did a lot of testing, but realize that I have to retest and rethink of the programming plan. Yeah I messed up   
The new tests will find the best way, either command$ or the smart code of mdijkens (dank!).

Thanks for all ideas and thinking, really appreciated.

[SpriggsySpriggs]

You can read a file's timestamp without the need for an external executable. You can just use the WinAPI to read the file properties.

[zaadstra]

Thanks for the tip, I will look into your API archive from Github.  I just can't get started on those Windows calls.
Back in the days I owned an Acorn RiscPC, and knew all about the OS and calls.  Syscalls were easy, both from (BBC) Basic and (ARM) Assembler. Those were the days.... But I had good documentation then, and I have to find the boat for a good start on Win syscalls.
Any links or docs on this would be appreciated!

For the stamp tool I want to create (for someone else): the behaviour of selecting files and using paths and wildcards has to feel 'natural'.

[mdijkens]

Maybe a bit to long to post source-code here, but I guess everything you need is already in here (including file timestamps):

mdDir

I created this to search through files for specific text.
To see how it works: mdDir /?

[zaadstra]

Maybe a bit to long to post source-code here, but I guess everything you need is already in here (including file timestamps):

mdDir

I created this to search through files for specific text.
To see how it works: mdDir /?

Thanks I'll dive into it!  There are two things I need to find out:
- the standard procedure for a call (or framwework)
- the list of available calls, with parameters in and out
Would be nice for a page on the wiki.

Interesting to see that I get different results:

D:\Bas\DateStamp\mdDir>mddir c:\temp\*.txt /t Excel
mdDir.exe v22.2.28.2
c:\temp\
COUNT!~1.TXT        13,447 A    12-04-2020 14:57:55 Count!Checker140.txt


..... some other tests ... like with /t "Open Excel" ...

D:\Bas\DateStamp\mdDir>mddir c:\temp\*.txt /t Excel
mdDir.exe v22.2.28.2
c:\temp\


(no result).

But it isn't at debugging mdDir but study the code  

Thanks!