Author Topic: Command$ parses wildcards in paths  (Read 1711 times)

0 Members and 1 Guest are viewing this topic.

Offline mdijkens

  • Newbie
  • Posts: 34
Command$ parses wildcards in paths
« on: February 27, 2022, 01:00:53 pm »
When I start a compiled program and specify a command parameter with wildcards like 'd:\dev\*.BAS' the parameter is immediately parsed and my _Commandcount is over a hundred containing all individual files instead of just the string 'd:\dev*.BAS'.
This problem does not occur with . or no wildcards.

If intended please update the documentation of COMMAND$ and provide other ways to get the exact parameter as typed by the user
~ 2 million lines of BASIC

Offline mdijkens

  • Newbie
  • Posts: 34
Re: Command$ parses wildcards in paths
« Reply #1 on: February 27, 2022, 01:23:59 pm »
You can easily test it creating a small program TEST.BAS with one line:
Print Command$

then run it with TEST C:\Windows\*.dll
~ 2 million lines of BASIC

Offline bplus

  • Global Moderator
  • Forum Resident
  • Posts: 8053
  • b = b + ...
Re: Command$ parses wildcards in paths
« Reply #2 on: February 27, 2022, 03:49:17 pm »
Enclosing the command line in single quotes prevents the multiple listing and get's it played back by Command$ literally.

Never knew Command$ would do that with Wildcard *
  [ You are not allowed to view this attachment ]  

  [ You are not allowed to view this attachment ]  

Yeah THEN you remove the single quotes.

Offline mdijkens

  • Newbie
  • Posts: 34
Re: Command$ parses wildcards in paths
« Reply #3 on: February 28, 2022, 07:03:20 am »
Yes, but that's a workaround :-)
I don't want my users to add single quotes around the path, I want command$ to work as it has always worked in QB4/4.5 BC7/7.1 PDS
I think in QB64 1.0 and 1.5 it worked as expected?
~ 2 million lines of BASIC

Offline bplus

  • Global Moderator
  • Forum Resident
  • Posts: 8053
  • b = b + ...
Re: Command$ parses wildcards in paths
« Reply #4 on: February 28, 2022, 09:38:40 am »
You don't have to make your users do it. You do it and then undo it in code and no one has to know :)

FellippeHeitor

  • Guest
Re: Command$ parses wildcards in paths
« Reply #5 on: February 28, 2022, 09:49:24 am »
Just to replicate my reply to the issue in the repository:

Quote
Both v1.5 and the latest do wildcard expansion under Windows XP, so they probably do so in all other versions. Tested just now. The behaviour seems consistent across platforms, and seems to have been that way forever - only unnoticed/undocumented till now, in which case I'm in favor of documenting the feature as is.

Another remark: wrapping a wildcard mask in quotation marks will disable expansion, and wrapping a path in quotation marks is pretty much standard, so it should suffice to "bypass" the expansion.

Offline mdijkens

  • Newbie
  • Posts: 34
Re: Command$ parses wildcards in paths
« Reply #6 on: February 28, 2022, 10:16:14 am »
You don't have to make your users do it. You do it and then undo it in code and no one has to know :)

How can I do it?
When entering my program it is already expanded without any possibility for me to stop that from happening?

I'd really want to preserve a way for developers to receive the exact text as passed by the user.
If I want users for example to specify myexe *.ico /s to also include subdirs, there's no way for me to find that out anymore in code :-(
with double quotes the problem persists and single quotes are really not a standard in windows environments

Programmers might have to revert to more complex winapi's to get to the untouched parameters (is that even possible) like it used to be in the old days

Until now, I've always been under the impression that qb64 wants to keep as close as possible to qb4/4.5 PDS7/7.1 and use _NewCommands for new or changed functionality
So especially in this case I can imagine having a Command$ (qb compatible) and _XCommand$ for expanding makes sense

Please reconsider or provide an easy option to retrieve the original parameterstring in code...
~ 2 million lines of BASIC

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • Steve’s QB64 Archive Forum
Re: Command$ parses wildcards in paths
« Reply #7 on: February 28, 2022, 11:18:26 am »
INPUT parh$ 'ask user for path
Path$ = "'" + path$ + "'"
Command$ path$


Similar to the above, I'd think.
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

FellippeHeitor

  • Guest
Re: Command$ parses wildcards in paths
« Reply #8 on: February 28, 2022, 11:33:33 am »
I take back my remark regarding wrapping a wildcard file name in quotation marks, it doesn't really work (must have been a fluke) - but single quotes do work, as indicated.

Tested as far back as v1.3, and the behaviour in all Windows versions is the same. I'd call it a feature, one @mdijkens will need to workaround for now, especially considering it's always been that way, as said.

COMMAND$ used to exist in QB4.5, but not as an array, as we have it now, so the implementation of the function in QB64 has always been one of its own, departing from the original usage.

I keep my vote for it to remain unchanged, and to extend the documentation to add info about it. We don't know if other people wrote code relying on the way it currently works.

Offline mdijkens

  • Newbie
  • Posts: 34
Re: Command$ parses wildcards in paths
« Reply #9 on: February 28, 2022, 11:49:28 am »
Allright then. I still regards it as inconsistency, but no crying over spilled milk ;-)
I propose, you decide; no problemo.

I've worked around it now like this:
Code: QB64: [Select]
  1. Function getCommand$ (n%)
  2.   Static cmd$(100), ccount As Integer
  3.   If cmd$(0) = "" Then
  4.       Function GetCommandLineA%& ()
  5.     End Declare
  6.     Dim m As _MEM, ms As String * 1000
  7.     a%& = GetCommandLineA: m = _Mem(a%&, Len(ms)): ms = _MemGet(m, m.OFFSET, String * 1000)
  8.     ccount = 0: sp0% = 1: sp1% = InStr(ms, " ")
  9.     Do While sp1% > 0
  10.       cmd$(ccount) = _Trim$(Mid$(ms, sp0%, sp1% - sp0%))
  11.       If cmd$(ccount) <> "" Then ccount = ccount + 1
  12.       sp0% = sp1% + 1: sp1% = InStr(sp1% + 1, ms, " ")
  13.     Loop
  14.     cmd$(ccount) = _Trim$(Mid$(ms, sp0%)): If Left$(cmd$(ccount), 1) = Chr$(0) Then ccount = ccount - 1
  15.     _MemFree m
  16.   End If
  17.   If n% < 0 Then
  18.     getCommand$ = _Trim$(Str$(ccount))
  19.   ElseIf n% <= ccount Then
  20.     getCommand$ = cmd$(n%)
  21.   Else
  22.     getCommand$ = ""
  23.   End If
  24.  
~ 2 million lines of BASIC

Offline bplus

  • Global Moderator
  • Forum Resident
  • Posts: 8053
  • b = b + ...
Re: Command$ parses wildcards in paths
« Reply #10 on: February 28, 2022, 01:41:57 pm »
Are you sure QB64 is the one returning multiple files for wildcard command and not Windows?
Being passed through Windows on command line, Windows may be the interfering source of the problem.

(I am pissed at Windows today, very! freak'n 150 background processes own my computer and ties it up for fractions of hour!) I do diagnostics, everything working fine blah!


Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • Steve’s QB64 Archive Forum
Re: Command$ parses wildcards in paths
« Reply #11 on: February 28, 2022, 02:02:30 pm »
freak'n 150 background processes own my computer and ties it up for fractions of hour!) I do diagnostics, everything working fine blah!

150 processes really don't seem that many any more -- especially with the way most browsers are set up! 

Start an instance of google chrome, or firefox, and look at your processes.  It seems as if each and every "add-on" or "extension" has to be running in its own thread.  With just this single browser tab opened for me to write a post in, Edge has 12 processes going on at the moment!

  [ You are not allowed to view this attachment ]  

Lots of other things tend to group up in bunches like that!  Windows Widgets (7).  Windows Input Experience (5).  YourPhone.exe (3).  Nvidia Container (7)....   

A lot of this junk seems completely worthless to me, such as the YourPhone.exe being in memory.  I've never made a phone call from my PC.  I've never taken a phone call from my PC.  My cellphone isn't connected to my PC in anyway whatsoever -- no dongle, no bluetooth, no nothing!  And yet, windows demands I have their "yourphone.exe" in memory!

Of course, I could go into the register, or group policy editor, or google whatever is needed and disable the service...  But that only lasts until the next update restores the setting and I have to repeat the process again!

Of all the reasons why people end up migrating over to Linux, it's all the desire to get away from the unwanted auto-load crap that I understand the most.  It's a shame Windows wants to make certain that everyone has everything installed, rather than allowing users the ability to pick and choose what's important and relevant for themselves.  I guess the problem comes from the vast majority of people not knowing anything about what they actually need their machine to do for them, so they just want it "able to do whatever!" 
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline mdijkens

  • Newbie
  • Posts: 34
Re: Command$ parses wildcards in paths
« Reply #12 on: February 28, 2022, 02:11:00 pm »
Are you sure QB64 is the one returning multiple files for wildcard command and not Windows?
Being passed through Windows on command line, Windows may be the interfering source of the problem.

(I am pissed at Windows today, very! freak'n 150 background processes own my computer and ties it up for fractions of hour!) I do diagnostics, everything working fine blah!

I'm  sure. Windows GetCommandLineA returns unmodified params.
And yes, we're all pissed at Windows every now and then :-)
(Remembering the good old days of MS-DOS and PDS 7.1)
~ 2 million lines of BASIC

Offline bplus

  • Global Moderator
  • Forum Resident
  • Posts: 8053
  • b = b + ...
Re: Command$ parses wildcards in paths
« Reply #13 on: February 28, 2022, 02:16:44 pm »
@mdijkens OK well I tried :) it is a curious thing that you've come across.

Hey @SMcNeill aka the Steve, I just turn on the computer, don't even have my WiFi connected (but who knows if it really isn't or Windows is just saying for me it isn't, hey, hey I'm not paranoid!) so and therefore the browser isn't even on yet!

BTW just had an update a couple days ago so it should not be that BS but who knows.

I don't care how many processes are going or ready, I'd like to know why I start up and let computer run for awhile while I breakfast come back in hour and 100% Disk is so tied up I can't even click the mouse to activate the browser, I get the wait circle when I just move the mouse.

Sorry all, I'm venting...
« Last Edit: February 28, 2022, 02:22:21 pm by bplus »

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • Steve’s QB64 Archive Forum
Re: Command$ parses wildcards in paths
« Reply #14 on: February 28, 2022, 03:01:17 pm »
@bplus What's using all the resources?  For me, it used to be the Indexing services and Search, so I ended up disabling both of those completely.  Since then, it's only when Windows Update starts downloading or installing, that I've seen any issues. 

From the "go to breakfast and come back" bit of your post, I'd guess the issue is probably with indexing.  Stop it.  Set it to not index anything, and purge the old index.  Then rebuild the index and see if the problem won't go away TOMORROW.  (It'll take time to rebuild, so usage will be high until it's done.)

I'm honestly guessing that's probably where the issue lies.  https://www.thewindowsclub.com/how-to-rebuild-search-index-in-windows-10
https://websiteforstudents.com/how-to-rebuild-windows-search-index-in-windows-11/
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!