[Implemented] read STDIN, STDERR from PB

naw · Post by **naw** » Tue Jul 29, 2003 5:36 pm

Hi Fred,

Please, Please, Please can we have a PB standard way of reading STDIN & STDOUT output from an external command.... in PB3.7 (so that when you get around to updating the Linux version we get it there too!!)

I've seen that there are vaious Windows API methods, but no obvious way of doing the same on Linux.

This is quite a core function, so would be best implemented as *part* of PB.

Thanks ... Nigel

(Implemented with ReadProgramString(), ReadProgramError() and WriteProgramStrin())

Kale · Post by **Kale** » Tue Jul 29, 2003 10:47 pm

I would really love to see this too

Dunno how it would be implemented though, for example once the 'pipe' is open (to StdOut say...) you need some way of continuously being able to read the data from the program/script because not all output comes at once, especially if the program is performing long calculations before it sends stuff to StdOut.

Tricky! C'mon Fred do us proud

RJP Computing · Post by **RJP Computing** » Wed Jul 30, 2003 12:02 am

This would be a VERY awsome feature!

PLEASE

naw · Post by **naw** » Wed Jul 30, 2003 2:55 pm

Hi, why not just implement it as:

PB_STDIN$ and PB_STDERR$ for short inputs

and like this for big data:

openFile(#PB_STDIN,"") -or-
openFile(#PB_STDERR,"")

and just normal PB commands for reading the data:

openFile(#PB_STDIN, "")
xyz=ReadByte() -or-
xyz$=ReadString() -or-
xyz.f=ReadFloat() -etc-
closeFile(#PB_STDIN, "")

Kale · Post by **Kale** » Wed Jul 30, 2003 5:50 pm

and just normal PB commands for reading the data:

openFile(#PB_STDIN, "")
xyz=ReadByte() -or-
xyz$=ReadString() -or-
xyz.f=ReadFloat() -etc-
closeFile(#PB_STDIN, "")

Yeah but these would have to be looped continuously in order to catch data at a later stage!

naw · Post by **naw** » Thu Jul 31, 2003 1:14 pm

ok - how about:

openFile(#PB_STDIN, "")
Repeat:
_stdin$=_stdin$+chr(13)+ReadString()
Until Eof(#PB_STDIN)
closeFile(#PB_STDIN, "")

or:

openFile(#PB_STDERR, "")
Repeat:
_stderr$=_stderr$+chr(13)+ReadString()
Until Eof(#PB_STDERR)
closeFile(#PB_STDERR, "")

- not forgetting:

openFile(#PB_STDOUT, "")
writeStringN("Error 1234 - This function does not exist yet...")
closeFile(#PB_STDOUT, "")

horst · Post by **horst** » Sat Aug 02, 2003 3:57 pm

> ... why not just implement it as:
> PB_STDIN$ and PB_STDERR$ for short inputs

and what about PB_STDOUT$ for output that can be redirected by the user (command line, batch) ??

Thade · Post by **Thade** » Sun Aug 03, 2003 5:16 pm

Hmm - In 25 years of programming I didn't have any ravenous hunger for those - Is that the future of Windows? Commandline Input Output Errorchecking?

Honest - make a deaf, dumb and blind guy happy - what is it good for?

Kale · Post by **Kale** » Sun Aug 03, 2003 5:44 pm

Honest - make a deaf, dumb and blind guy happy - what is it good for?

In my case writing nice GUI's for new/old command line utils/programs

P.S. Better to have and not need, than to need and not have!

RJP Computing · Post by **RJP Computing** » Sun Aug 03, 2003 6:01 pm

Kale wrote: P.S. Better to have and not need, than to need and not have!

Exactly. I would love this. Man they have these features in java and they are very slick to use.

naw · Post by **naw** » Mon Aug 04, 2003 12:27 pm

Guys, this was a request for Linux - not for Windows (there >1 OS in the world y'know

In the Unix world, utils usually consist of a command line processor and an optional / seperate Graphical Front End. This makes STDIN/OUT/ERR a simple but also very powerful and flexible means of passing complex / large amounts of data for further processing.

There's also no issue of "How do I pass *this* message to *that* application " and changing API specs - it just works transparently...