QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: mdijkens 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
-
You can easily test it creating a small program TEST.BAS with one line:
Print Command$
then run it with TEST C:\Windows\*.dll
-
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 *
[ This attachment cannot be displayed inline in 'Print Page' view ]
[ This attachment cannot be displayed inline in 'Print Page' view ]
Yeah THEN you remove the single quotes.
-
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?
-
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 :)
-
Just to replicate my reply to the issue in the repository:
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.
-
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...
-
INPUT parh$ 'ask user for path
Path$ = "'" + path$ + "'"
Command$ path$
Similar to the above, I'd think.
-
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.
-
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:
ccount
= 0: sp0%
= 1: sp1%
= InStr(ms
, " ") cmd$
(ccount
) = _Trim$(Mid$(ms
, sp0%
, sp1%
- sp0%
)) If cmd$
(ccount
) <> "" Then ccount
= ccount
+ 1 sp0%
= sp1%
+ 1: sp1%
= InStr(sp1%
+ 1, ms
, " ") getCommand$ = cmd$(n%)
getCommand$ = ""
-
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!
-
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!
[ This attachment cannot be displayed inline in 'Print Page' view ]
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!"
-
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)
-
@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...
-
@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/
-
Thanks Steve, I'll give it a try.
Update: so far so good took over 2 maybe 3 hours to run in background so I could do other things.