qb64
qb64 copied to clipboard
QB64Team
Allow SHELL to capture stdout of command
The usual method is to redirect output to a file then read in said file, which is messy and annoying to do.
That would be absolutely awesome. I hate having to always output everything to a text file and read it back in. Creates so many text files that way.
Why not make SHELL a function? (like how you can use SCREEN as a command and function)
SHELL is already a function, used to return the ERRORLEVEL code of a shelled out program: SHELL (function)
Maybe this will be a new SHELL$() function; I don't know how @flukiluke envisioned it yet.
Well, why not make a separate function? You execute SHELL str$ and get _STDOUT$() and _STDERR() back. (uses output and error level from last executed command)
My initial thoughts were to add some optional parameters to the SHELL command: SHELL cmd$, stdin$, stdout$, stderr$ where the contents of stdin$ get sent to the program being executed.
An alternative is using file handles: SHELL _DONTWAIT cmd$, 1, 2, 3 so 1 can now be written to as if it had been opened FOR OUTPUT, and the other two FOR INPUT. This would allow running programs that require some level of interaction.
As a former distributed processing developer in CICS MRO/ISC, I too like this approach. I can envision being able to have the QB64 program communicate and control programs/systems written in Python, JAVA, and other languages where the data requested (file server) or even if you want more control to access/login than you get in Linux (or none with Windows and Macs) you can even create a terminal program.
I like this approach very much, as I do consulting work with clinicians and scientists who benefit greatly with a distributed processing approach.
I also like the _DONOTWAIT as this would tie up the initial program, and if you write, say a router in QB64, and it sends requests to many different processes, you do not want it sitting around waiting for the first reply to comeback before sending out the others.
When I code for distributed processing, like in CICS, the data comes back as string or message, which I would like to suggest adding another parm that tells the QB64 router program the originator of the request, so it knows where to send the results to. We used both a program name and a transaction ID, but for this purpose, another parm just for transaction ID would suffice. It could look like:
SHELL cmd$, transid$, stdin$, stdout$, stderr$
The cmd$ and transid$ will tell the process you are calling what to call and do with the request, and on the return back, the transid$ will tell the QB64 where to send the stdout$ to. This would make it almost a peerless process.
I am interpreting the cmd$ as the program, shell script, or process you wish to call to process the stdin$ data. If we can send multiple requests out at the same time, the QB64 router can then receive the responses, and the transid$ will direct the return to the proper FUNCTION or call another program and pass the data to it.
This is just a suggestion and an example of how I would use it to allow multi-tasking. Since SmartBASIC is defunct (hasn't been supported in 3 years) on the mobile platform, for most of my clients they are switching over to Linux where I can interface even with iPads using the HTTPD protocols using TechBASIC on the iPad, and a BASH script to initiate a FTP to a directory on a website where the iPad code can pull the data from and process it.
Not only do I work in the science community, I help out professors at colleges with their class labs that involve the students writing programs to analyze data.
Again, this would be a great addition, and save me the trouble and time to code my own, as I have enough work to do to swap willing clients off Windows and onto Linux for their server/main processing hub.
This code that I have written below has access to stdout and stderr. It also provides the exit code, similar to the _SHELL() function. Hope this helps you for the time being.
https://www.qb64.org/forum/index.php?topic=3656.0