12-25-2022, 12:33 AM
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:
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 .....
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:"; commandsLooping 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 .....