Pipe Console Output to QB64 program!

[SpriggsySpriggs]

That was the trick! "./" worked. I also tried "/home/name/QB64/source/program/" and that didn't take either. The wiki was not exactly clear either, but I tried.

@Jesterdev Sorry! I'm so used to keeping my source and everything in the same folder as the executable so I just naturally assume others will as well! Hope it helps you do what you need! Please tag me if you end up posting some code that uses the library so I can see what you come up with!

[SpriggsySpriggs]

Updated pipecom library with new code specifically for Windows using the WinAPI that makes the output the same as what you would get on Linux and Mac with no console window.

[badger]

Hello

Does not look like you can use /P in there I have been trying that but it just goes to the end of the data and ends. Is that what it is supposed to do

Badger

[SpriggsySpriggs]

@badger Can you be more specific? What is it you are trying to do? Can you post some code?

[mpgcan]

You use the /P switch to have the Command Prompt pause results after it displays each screen. You have to press a key to continue viewing the next page of results. The command prompt window is hidden because of this it cannot receive input hence you cannot use /P.

[SpriggsySpriggs]

You use the /P switch to have the Command Prompt pause results after it displays each screen. You have to press a key to continue viewing the next page of results. The command prompt window is hidden because of this it cannot receive input hence you cannot use /P.

@mpgcan @badger Yes, you cannot do a command that will require user input. The same is true for a regular SHELL. This is meant to run a command and grab immediate output. You cannot interact with the program you are calling.

[badger]

Hello

Sorry just saw your post. there is what i mean. It does not give me the paging option it just goes to the end of the task and exits.

Badger

Code: QB64: [Select]

1. DECLARE LIBRARY "pipecom"
2.     FUNCTION pipecom$ (cmd AS STRING)
3. END DECLARE
4.  
5. DIM F AS STRING
6.  
7. 'F = pipecom("dir *.BAS")
8. F = pipecom("dir /b /s /p*.BAS") 'if you need just the filenames and not the rest of the output
9.  
10. PRINT F
11.  
12.  
13.  

[SpriggsySpriggs]

@badger Yes, you won't be able to interact with the console. This behaves just like SHELL except that it returns the text from the screen. You cannot provide input after the command is ran. This is expected. If you want the entire directory then you would have to ask for the whole list whether you used pipecom or if you used SHELL.

[SpriggsySpriggs]

Updated 04:14 PM on 11/03/2020

Fixed bug in pipecom where the buffer wasn't cleared between calls which could lead to duplication of data.

[mpgcan]

Hi Spriggsy
What an excellent solution using pipes. I have tried using these in the pass but always failed, never understood what bits to twiddle.

I downloaded the latest (05/11/2020 08:05) version of your pipecom library and it failed to compile on Windows 8.1.

No big deal, change file pipecom.bas to:

Code: QB64: [Select]

1. OPTION _EXPLICIT
2.  
3. DECLARE LIBRARY "pipecom"
4.     FUNCTION pipecom$ (cmd AS STRING)
5. END DECLARE
6.  
7. DIM comm AS STRING
8.  
9. comm = pipecom$("dir /b *.BAS")
10.  
11. PRINT comm
12.  

Compiled and run with no issues.

Looking at pipecom.h
Lines "int first;" and "int last;" are leftover code? delete these not required.

The small buffer size does not look right, proposal:

Replace this code:

Code: QB64: [Select]

1.     char buf[2] = { }; //I know, the buffer is small but I had to in order to work with things like PING
2.     DWORD dwRead = 0;
3.     while (ReadFile(hStdOutPipeRead, &buf, 2, &dwRead, NULL) && dwRead)
4.     {
5.         buf[dwRead] = '\0';
6.                 pipecom_buffer.append(buf);
7.     }
8.  

With the following code:

Code: QB64: [Select]

1. //Note: ReadFile will return when buffer is full, or pipe is closed
2. #define BUFFSZ 4096       //Seems to work here. Better to place at top of code
3.     char buf[BUFFSZ + 1]; //+1 Space for null terminator
4.     DWORD dwRead = 0;     //Number of bytes read. Automatically reset to 0 on each call to ReadFile
5.     while (ReadFile(hStdOutPipeRead, buf, BUFFSZ, &dwRead, NULL))
6.     {
7.         buf[dwRead] = '\0';
8.         pipecom_buffer.append(buf);
9.     }
10.  

Not sure what the issue you had with PING (buf[2]) however with the above changes I tried this code:
comm = pipecom$("ping google.com")
 it works.

All the best.

[SpriggsySpriggs]

Yes, you are correct about int first and int last. Those were pieces I didn't see when I uploaded it last. As for the buffer. I know when I had large buffer sizes that a ping would only return part of the console output. I had not tested it again after making the last changes to see if making a larger buffer would still work. Yes, it works. I had the buffer at 4096 at the beginning and it never worked correctly with ping unless I changed it to 2. So really all I'm going to do is undo some changes. I don't know why you would have had compilation errors. Did you look at the compilation log?

[mpgcan]

Hi Spriggsy
   The term I used was incorrect instead of "failed to compile" I should have said failed to run!
The code you currently have for pipecom.bas is:

Code: QB64: [Select]

1. OPTION _EXPLICIT
2.  
3. DECLARE LIBRARY "pipecom"
4.     FUNCTION pipecom (cmd AS STRING)
5. END DECLARE
6.  
7. DIM comm AS STRING
8.  
9. comm = "dir /b *.BAS"
10.  
11. PRINT comm
12.  

It should be changed to:

Code: QB64: [Select]

1. OPTION _EXPLICIT
2.  
3. DECLARE LIBRARY "pipecom"
4.     FUNCTION pipecom$ (cmd AS STRING)
5. END DECLARE
6.  
7. DIM comm AS STRING
8.  
9. comm = pipecom$("dir /b *.BAS")
10.  
11. PRINT comm
12.  

All the best,
Again thanks for the working code.

[SpriggsySpriggs]

@mpgcan Yes, you are correct. The file in my upload was wrong. I think I actually accidentally uploaded that one specifically. Even so, the very first post in this thread is valid code. Did you give it a look? It shows the proper usage so that there is no guesswork.