Chris, we are using 4.10, and this redirector does not appear in that.
Isaac, our system is a bit more complicated than just a shell, as we
have a menu driven maintenance system on top of the shell.
Basically we create a task with the device name (such as "/dev/com1" or
/dev/usb" or "/dev/pty
On 5/10/2015 2:28 pm, Joel Sherrill wrote:
>
> I think there is a support method to close stdio and reopen them. Cc'ing
> Chris as I think he wrote this.
>
Have a look in cpukit/libmisc/redirector.
Chris
___
devel mailing list
devel@rtems.org
http://
Hi Ian,
That's exciting! I clearly should have looked a bit harder before posting. Is there any special
config? Or is it sufficient to instantiate another shell with a different file descriptor for IO?
Isaac
On 10/04/2015 09:22 PM, Ian Caddy wrote:
Hi Isaac,
On 3/10/2015 4:24 AM, Isaac Gute
On October 4, 2015 8:22:44 PM CDT, Ian Caddy wrote:
>Hi Isaac,
>
>On 3/10/2015 4:24 AM, Isaac Gutekunst wrote:
>> Hey,
>>
>>
>> The hack would be that file descriptors 0,1 and 2 are not part of a
>> global namespace of file descriptors, and potentially refer to
>different
>> actual IO devices on
Hi Isaac,
On 3/10/2015 4:24 AM, Isaac Gutekunst wrote:
Hey,
The hack would be that file descriptors 0,1 and 2 are not part of a
global namespace of file descriptors, and potentially refer to different
actual IO devices on a per task basis.
The motivation here would be creating a more function
Hey,
I've been trying to figure out whether RTEMS would support a real shell with IO redirection,
signals (at least Ctrl-C), and launching of "processes".
Processes can simply be functions added to a table, like the current shell, or loaded using the
run-time linker.
What seems to be lackin
