Taking in file in stdin and stdout

General
1

Is there a example of getting stream into Console application in Xojo ?

And returning stream…

So basically I will be getting a stream, not a file path.

Thanks

2

Just to be clear, you want to write a console app that takes in data in a stream and outputs in a stream? Or do you want to use such a CLI in your app?

3

Yes I want to take in stream and return other stream stream.

so StdIn and StdOut functionality… But I dont know how to do that in Xojo

Thanks

4

Use StdIn.ReadAll and StdOut.Write.

5

https://documentation.xojo.com/api/files/standardinputstream.html

https://documentation.xojo.com/api/files/standardoutputstream.html

6

The Run event would look something like this:

do
  dim s as string = StdIn.ReadAll
  StdOut.Write Process( s )
  App.DoEvents
loop until whateverYourExitFlagIs
7

Doing that is writing to the console window though but I guess if calling process has set up the stdout to a file then maybe it ends right ?

8

On Mac I would call something like

consoleApp < InputFile > outFile
9

Or take a switch that specifies an output file. Have you looked at @Jeremy Cowgar 's OptionParser?

https://github.com/jcowgar/xojo-option-parser

10

that’s a perfect example why <https://xojo.com/issue/2332> (“Add signal handling to Console apps”) would be a great addition! Handling SIGPIPE for example…

11

I cannot get it to work at all on Windows (32 bit or 64 bit)

Generator.exe < Test.xml > Test.gen

stdin will always read zero string

Anyone know if this is bugged on Xojo for Windows ?

12

[quote=418687:@Björn Eiríksson]I cannot get it to work at all on Windows (32 bit or 64 bit)

Generator.exe < Test.xml > Test.gen

stdin will always read zero string

Anyone know if this is bugged on Xojo for Windows ?[/quote]

Of you do that you must use the args() parameter in the open event

Then if the console keeps running using a loop and doevents, you poll stdin.readall

13

The Stdout is correctly re-directed to the file Test.gen

but the StdIn is not…

So your saying I cannot re-direct the StdIn and must take in the file name ??

14

Well this ended in Bug report, its all severely broken on Windows, StdIn does not work, and StdOut will write 80-90 kb at most out of 200kb file even if you flush and chunk it down.

54494 - StdIn and StdOut do not work correctly when redirected on Windows

OS: Windows 10

Xojo: Xojo 2018r4

Steps: StdIn and StdOut do not work correctly when redirected on Windows

If using syntax like this:

consoleApp < InputFile > outFile

Then StdIn will never get the InputFile as the StdIn

StdOut gets the Output file. But there is another bug there

If streaming say 200 kb file to the Stdout (to the outFile) then you will get 80-90 kb at most in the file even if your flushing and chunking it down in small pieces. If not chunking it then 40-50 kb is written at most.

Expected Result:
StdIn and StdOut to work when redirected On Windows

Actual Result:
Redirecting does not work at all on Windows and StdOut redirected wont write everything you send at it

Workarounds:
None

15

[quote=418690:@Björn Eiríksson]The Stdout is correctly re-directed to the file Test.gen

but the StdIn is not…

So your saying I cannot re-direct the StdIn and must take in the file name ??[/quote]

When calling a Console Application you have parameters those you get as Args() As String in App.Open.

When you first open the console application in cmd or whatever; you do “Generator.exe <test.xml> test.gen”

App.Open, Args() As String:
Path to your exe is args(0)
<test.xml> = the first args(1)
test.gen = args(2)

and so on…

Then you must keep a main loop and use Stdin.ReadAll to read new (interactive) input
And use StdOut.Write to write back new output but the executable must keep running (using a loop and doevents)

App.Open(Args() As String):


// get the arguments/ note bad example but shows what it does.... 
// when MyExecutable.exe <test.xml> test.gen is called first.
Dim path As String = Args(0)
Dim xmlfilename As String = Args(1)
// and so on...

do
// Keep running to read stdin from an interactive or async console/shell
  dim s as string = StdIn.ReadAll
  StdOut.Write Process( s )
  App.DoEvents(10)
loop until whateverYourExitFlags

// Return code here:
Return 0

This should not be a bug, the max length for stdin/stdout is a windows thing that should be settable somewhere.

16

I don’t see how that makes sense

Since if called from other process then we wont have any file name

And in VisualStudio for example we can make utility that takes the syntax encode < fileA > fileB

And further more if the StdIn is empty then how would I read the file ? And how would I know when its done ? Utility like this normally after all ends when StdIn reaches EOF, not some random whateverYourExitFlag.

But StdIn is totally empty.

The test case is console:

encode < fileA > fileB

Real world case would be other application creating process and wiring up StdIn and Stdout with streams that are likely not filestreams.

(Like you can do with any other Console applications but apparently not Xojo)

17

A complete stream may be possible on some platforms but don’t expect all to work with long strings as stdout/stdin streams.

You may wanna keep the “console” application running and use it interactive, in a self-created loop calling App.DoEvents (since console apps in xojo have none) read the stdin.ReadAll untill StdIn.EOF (see above answers from Kem)

It should be possible to read files using the standartinpustream (stdin) since it’s in xojo’s docs here:
http://documentation.xojo.com/api/os/stdin.html

You may wanna try this using pipes.
Buffering of the “terminal” should be settable from the host (for example xojo’s shell class)

18

There is no limit on StdOut in the Example above then Xojo is just chocking on NULL characters. Making streaming out not work for any binary files. If testing same with just “x” for every letter then it writes out 200 kb no problem.

19

Well xojo and NULL values don’t work well together.