Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Redirecting stdout problems

603 views
Skip to first unread message

Bill Harmon

unread,
Jun 6, 2001, 10:28:28 PM6/6/01
to
I am having problems redirecting stdout. I am trying to provide
the ability for our the CLI in our application to call certain
VxWorks functions such as i(), ifShow(), and ti() so that they
may be executed via our CLI through telnet (not the Tornado
shell). For some of these functions, the source code is provided
so I can easily direct the output to our routines, however some
functions are not provided in source form. As a result, I am
trying to come up with a general scheme to redirect the output
of stdout so that I can capture the output of these routines,
and send it to our routines for output to the user via telnet.
First, is redirecting stdout the best (only?) way to accomlish
this? Assuming this is the best way to proceed, I wrote some code
which redirects the stdout to a pipe using ioGlobalStdSet().
While this works in most cases, it does not seem to work reliably,
and sometimes crashes the system. Further, in order to capture the
output of these routines I found that I needed to create a pipe
such as

pipeDevCreate ("/pipe/cli", 1000, 200);

The effect is, I beleive, reserving a relatively huge amount of
memory for the queues for this function. This does not seem right to
have to allocate this amount of memory for this purpose. I have not
used pipes before so part of the problem may be my misundertanding
of how to use them correctly. If I use smaller amount of max_msgs or
max_msg_len, I find that I miss portions of the output generated by
i(), for example.

The code fragment that I am using to capture the output of stdout
and send it to my routine is as follows;

// Open the pipe for STDOUT redirection
fd = open ("/pipe/cli", O_RDWR, 0644);

if (fd != ERROR) {

// Setup the I/O streams for redirection
taskLock();
stdin_fd = ioGlobalStdGet(0);
stdout_fd = ioGlobalStdGet (1);
stderr_fd = ioGlobalStdGet (2);
ioGlobalStdSet(0,fd);
ioGlobalStdSet(1,fd);
ioGlobalStdSet(2,fd);
taskUnlock();

// Clear out and residual data in the CLI pipe
ioctl (fd, FIOFLUSH, 0);

// Call the actual function which does the work
i(); // <--- I want to capture the output of this function

// Replace the original I/O streams for this task
taskLock();
ioGlobalStdSet(0,stdin_fd);
ioGlobalStdSet(1,stdout_fd);
ioGlobalStdSet(2,stderr_fd);
taskUnlock();

// Initialize the output buffer to NULL
strcpy(pipeBuf,"");

// Get the number of messages queued up for us...
ioctl (fd, FIONMSGS, (int) &nMessages);

// Get the output from the pipe
while (nMessages--) {
len = read (fd, dummyBuf, 200);
strncat(pipeBuf, dummyBuf, len);
if (strlen(pipeBuf) >= 80) {
// Send pipeBuf to the output routines here...
strcpy(pipeBuf,"");
}
}

// Flush any residual data
if (strlen(pipeBuf)) {
// Send pipeBuf to the output routines here...
}

// Close the pipe for STDOUT redirection
close (fd);
}

Is it correct that I pipeDevCreate needs to allocate a queue this
large to capture this output? Is there a better was to accomplish
what I am trying to do?

Thanks in advance,

Bill Harmon

Vijay Kumar Peshkar

unread,
Jun 7, 2001, 5:42:39 AM6/7/01
to
Bill,

You can try by sending commands to the target shell using simple ASCII (sprintf())
and get responses. You can parse the responses with sscanf().

Hope this helps,
Vijay

vijay.peshkar.vcf

Kumar

unread,
Jun 7, 2001, 6:09:09 PM6/7/01
to
Bill,

Set the ioGlobalStdSet(1,fd); to an local file. Issue the necessary
command. And then
proper reading and interperting the file. This would be an better
alternative than pumping to an message queue.
If you cannot do on a file open a mempory file.

Kumar

Vijay Kumar Peshkar <vijay....@wipro.com> wrote in message news:<3B1F4C8F...@wipro.com>...

> --

Dave Korn

unread,
Jun 8, 2001, 6:10:16 AM6/8/01
to
>> Bill Harmon wrote:
>>
>> > I am having problems redirecting stdout.

Kumar wrote in message ...


>If you cannot do on a file open a mempory file.

Actually I think it would be a better idea to use a memory file in any
case; it's faster and less wear and tear on the hardware. Bill, see the
memDrv documentation in "VxWorks Reference Manual : Libraries" for more
info.

DaveK
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.


0 new messages