[ale] how to redirect fds through telnet session in QNX?

[Step]

Guys,

Many thanks!  It'll take me a little while to absorb and understand
everything before I figure out what works best for us, and I'll let you know
what the final solution ends up looking like.

Although I used pseudo-terminal, that doesn't mean I really know what it
means.  ;)  I don't think our processes require a terminal at all, but I
really don't know.  This is the first I've really started digging into them
(and QNX) anywhere near this deep.  I'll take a look at netcat as a start
and see if that will work, but I'll also look through your code to
understand it.

Ok, off to do more research.  You gave me a ton of stuff to learn about!

Thanks again, I really appreciate it.  You guys have some amazing
knowledge.  :)

Peace,
Step

On 3/24/07, Christopher Fowler <cfowler at outpostsentinel.com> wrote:
>
> On Sat, 2007-03-24 at 15:48 -0400, Step wrote:
> > Since the instrument is often mounted on lifts, walls, or otherwise
> > relatively inaccessible locations, I was hoping to just push over a
> > script or some code with our next embedded software update, that I can
> > then run through telnet to duplicate or somehow send debug information
> > to file.  Barring that, I want to understand why that won't work
>
> If the output is sent to a tty then you just can't grab that output.
> There were products on the market that I used years ago that would do
> this.  One product was named Double Vision.  It ran on SCO,AIX, and
> other UNIX systems.  It included a kernel driver.  It would allow you to
> run a program and attach to the TTY of what you wanted to control.  We
> used it to connect to IBM3151, Wyse50, and Tiny Term terminals.  We
> could then run programs and detach or must likely we would be training
> people over the phone.  We took control of their serial terminal and
> walked them through the software.  That would be a good solution but I
> can think of any way that the Linux kernel is going to just allow you to
> take join a TTY like that.  I did at one time see a similar program
> which included no driver but on inspection it used the same concept of
> what I just done in PERL.  It would run programs on pseudos and then you
> would use a client to connect to the main daemon.  You could then decide
> which session you would like to attach to.  Not a bad solution but not
> the way that DV did things.  It was a user space solution.  Who wrote it
> decided to solve the problem in user space using the tools provided.
>
> In my example I use a pseudo and that may be over kill.  If your program
> requires a tty, isatty(3), then you would need a pseudo.  If you wanted
> to interface via a curses like GUI then you would need a pseudo.
> Otherwise pipe(2) would work great.  The only reason I used a pseudo it
> because you mentioned a pseudo and I'm not sure what your app does or
> needs in the way of input and output.  Pseudos do their best to emulate
> a tty with minor limitations.  They are just fancy pipes.
>
> If you want to use the pipe then look at Jame's response in regard to
> netcat.  You'll have to compile to run on QNX though.
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
>
-------------- next part --------------
An HTML attachment was scrubbed...