COMMAND$ and wildcards on files
#1
Hi,

I'm writing some small tool handling files or folders.  It should be able to accept wildcards.  
And I programmed a -R argument to recurse.

The thing I'm struggling on is that f.e. an argument as "test*.*" is returned in COMMAND$ als separate files that are matching.

Is it possible to get this argument just as test*.* instead of many arguments?  Especiallly when combing this with recursing, this behaviour makes it difficult to handle it so for a user it feels logically.
Reply
#2
If it's inside quotes, it should pass as a single argument.  Are you using another program to make the call?  If so, encase it in CHR$(34) quote symbols.    SHELL "myprog.exe " + chr$(34) + "test*.*" + chr$(34)   <-- something similar to this.
Reply
#3
Yes that's what I expected.  But it appears different:

c:\TEMP>datestamp 12-34-2022 TestDir\*.*
"12-34-2022 TestDir\a.jpg TestDir\DS1.txt TestDir\file1.jpg TestDir\file2.jpg TestDir\file3.jpg TestDir\gpsinfo.txt TestDir\hey.jpg TestDir\kladje.txt TestDir\New folder TestDir\TestFile2.jpg"
Arguments: 11


c:\TEMP>datestamp 12-34-2022 "TestDir\*.*"
"12-34-2022 TestDir\a.jpg TestDir\DS1.txt TestDir\file1.jpg TestDir\file2.jpg TestDir\file3.jpg TestDir\gpsinfo.txt TestDir\hey.jpg TestDir\kladje.txt TestDir\New folder TestDir\TestFile2.jpg"
Arguments: 11


Using full path doesn't matter:
c:\TEMP>datestamp 12-34-2022 "C:\TEMP\TestDir\*.*"
"12-34-2022 C:\TEMP\TestDir\a.jpg C:\TEMP\TestDir\DS1.txt C:\TEMP\TestDir\file1.jpg C:\TEMP\TestDir\file2.jpg C:\TEMP\TestDir\file3.jpg C:\TEMP\TestDir\gpsinfo.txt C:\TEMP\TestDir\hey.jpg C:\TEMP\TestDir\kladje.txt C:\TEMP\TestDir\New folder C:\TEMP\TestDir\TestFile2.jpg"
Arguments: 11


As you can see the argument is typed in the shell, by an user.
I also thought of escape chars and other tricks, but from a user point of view to this command line util, it should be natural, "like DOS". So better no quotes unless spaces are involved.
Actually, I was quite surprised by the parsing of the wildcard and passing many arguments.

Note that I'm switching between good old 2.0.1 and PE 3.4.1. There's no difference in behaviour, only the compile on the latter is way slower.

The code for this was straightforward:
Code: (Select All)
commands = _COMMANDCOUNT
PRINT quote$; COMMAND$; quote$
PRINT "Arguments:"; commands

Looping out all commands() obviously nicely give all generated arguments. Parsing the wildcard may be the win10 shell in action.

For some uses this is nice, just processing the separate files and done. But when subfolders and recursion are desired, things get illogical and awkward. Then I do not see I the original argument (the 'root' folder) and I cannot see if wildcards are typed by the used (by detecting *).

It wouldn't be so bad if the recurse command -R (or different) was picked up as well by the mysterious parsed whichs poops out all separate files .....
Reply
#4
Tell the user to enclose it in single quotes.

datestamp 12-34-2022 'TestDir\*.*' 

I would think that should fix it.
Reply
#5
I had exactly the same issue some time ago and solved it like this:
Code: (Select All)
i% = 0
p$ = getCommand$(i%)
Do While p$ <> ""
  Print i%; p$
  i% = i% + 1
  p$ = getCommand$(i%)
Loop
End

Function getCommand$ (n%)
  $If WIN Then
    Static cmd$(100), ccount As Integer
    If cmd$(0) = "" Then
      Declare Library
        Function getCommandLine%& Alias GetCommandLineA ()
      End Declare
      Dim m As _MEM, ms As String * 1000
      a%& = getCommandLine: m = _Mem(a%&, Len(ms)): ms = _MemGet(m, m.OFFSET, String * 1000)
      ms = _Trim$(Left$(ms, InStr(ms, Chr$(0)) - 1))
      ccount = 0: sp0% = 1: sp1% = InStr(ms, " ")
      Do While sp1% > 0
        cmd$(ccount) = _Trim$(Mid$(ms, sp0%, sp1% - sp0%))
        If cmd$(ccount) <> "" Then ccount = ccount + 1
        sp0% = sp1% + 1: sp1% = InStr(sp1% + 1, ms, " ")
      Loop
      cmd$(ccount) = _Trim$(Mid$(ms, sp0%)): If Left$(cmd$(ccount), 1) = Chr$(0) Then ccount = ccount - 1
      _MemFree m
    End If
    If n% < 0 Then
      getCommand$ = _Trim$(Str$(ccount))
    ElseIf n% <= ccount Then
      getCommand$ = cmd$(n%)
    Else
      getCommand$ = ""
    End If
  $Else
      getCommand$ = Command$(n%)
  $End If
End Function
45y and 2M lines of MBASIC>BASICA>QBASIC>QBX>QB64 experience
Reply
#6
(12-25-2022, 08:10 AM)mdijkens Wrote: I had exactly the same issue some time ago and solved it like this:

Thanks @mdijkens,  I'll look into this to see if it works for me too Smile
Reply
#7
(12-25-2022, 04:23 PM)zaadstra Wrote:
(12-25-2022, 08:10 AM)mdijkens Wrote: I had exactly the same issue some time ago and solved it like this:

Thanks @mdijkens,  I'll look into this to see if it works for me too Smile

Yep it's working (of course!).  Now I can move on.

I just noticed a delay between start and display of the program.  Has this to do with the complexity of the call?  I've never used _MEM and do not understand the getCommandLine function yet. These are a bit magic parts.
Reply
#8
(12-29-2022, 05:58 PM)zaadstra Wrote: I just noticed a delay between start and display of the program.  Has this to do with the complexity of the call?  I've never used _MEM and do not understand the getCommandLine function yet. These are a bit magic parts.

No, I don't recognize this. This call is far from complex and most of the time _Mem is as fast as it gets  Smile
45y and 2M lines of MBASIC>BASICA>QBASIC>QBX>QB64 experience
Reply
#9
I'm confused. Why aren't you using COMMAND$(n)? You can iterate through arguments with that. No need for a separate call to the WinAPI.
Ask me about Windows API and maybe some Linux stuff
Reply
#10
(12-30-2022, 04:21 PM)Spriggsy Wrote: I'm confused. Why aren't you using COMMAND$(n)? You can iterate through arguments with that. No need for a separate call to the WinAPI.

In the first post it seems to be that the original poster doesn't want that behavior, would rather have the asterisks:

Quote:Is it possible to get this argument just as test*.* instead of many arguments? Especiallly when combing this with recursing, this behaviour makes it difficult to handle it so for a user it feels logically.

Yes it could be confusing.
Reply




Users browsing this thread: 1 Guest(s)