QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: doppler on October 03, 2020, 07:38:57 am
-
after much looking over things. I would like to pull back this post.
edit: What brought this up.
The shell function does not just bring up another command.com instance. I was trying to use the "findstr" program within a shell. Nothing happened. I thought maybe the path was not pointing right. I used explicit path to "findstr" in syswow64. Still nothing. I directed my shell passing stuff into a .cmd file. Executed it from a plain dos prompt. Worked. I executed my created .cmd from a shell. Worked. The help content on shell function mentions using "cmd /c" because somethings don't work right with just shelling. Did that and it worked.
The nasty part about this the shell should work without invoking another command.com from my shell out. Beware shell is NOT A EXECUTION OF COMMAND.COM with parameters. There are strange limits.
I still wish for a un-post button for a post by the "poster".
edit: Title change a bit for a warning about shell.
-
Rather than using findstr, use this. It's far more powerful.
http://fart-it.sourceforge.net/ (http://fart-it.sourceforge.net/)
https://emtunc.org/blog/03/2011/farting-the-easy-way-find-and-replace-text/ (https://emtunc.org/blog/03/2011/farting-the-easy-way-find-and-replace-text/)
-
I've used a much older version called OLD Find And Replace Text
Pete
-
24/7, right @Pete ?
-
I still wish for a un-post button for a post by the "poster".
If you title your post with the proper wording, instead of a deleted post we'll end up with a cautionary tale about using SHELL. Your post could save someone else with a similar issue.
-
If you title your post with the proper wording
Yea, I had a great title, example and everything. But even more investigations uncovered the nuance of shell invocation. Rendering everything moot. I would love to know why things happened as they did. Since my understanding of "shell" as being a command.com invoke. A mystery to me that may never be found.
-
http://fart-it.sourceforge.net/ (http://fart-it.sourceforge.net/)
https://emtunc.org/blog/03/2011/farting-the-easy-way-find-and-replace-text/ (https://emtunc.org/blog/03/2011/farting-the-easy-way-find-and-replace-text/)
I will play a bit with "Farting". Sounds worst than when you say it that way. I am only using a string search. Findstr maybe as fast as farting it.
-
I would love to know why things happened as they did.
In Windows, SHELL is a call to system(), in case your program is in $CONSOLE mode. If not, then it's a call to ShellExecuteEx, in the Windows API. If that fails, then a new process is created with a call to command.com /c + your command line.
In Linux/macOS, SHELL is a call to system().
-
24/7, right @Pete ?
:D
Okay guys, here's a weird one...
shell _dontwait _hide "notepad"
For some reason, _HIDE prevents notepad from opening.
This can be circumvented by removing _HIDE, or by adding any of the following...
shell _dontwait _hide "start notepad"
or
shell _dontwait _hide "cmd/c notepad"
Also, although START is not needed in some SHELL calls anymore, START is still the only way I know of to add switches, like /max, /min, or /p (for print) Example: shell _dontwait _hide "start /max notepad"
Pete
-
@Pete I've always been able to add switches to notepad without using START.
-
Really? I know we both run Win-10 64-bit, so what's your method. For instance...
Using the maximixe switch /max..
shell _dontwait "start /max notepad"
That will open notepad maximized on my system.
shell _dontwait "/max notepad" and shell _dontwait "cmd/c /max notepad" Won't work. Notepad doesn't even open on my system.
Pete