[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RAWish terminal settings in shell



On 9/03/11 7:05 PM, Peter Dufault wrote:
> (Giving this topic it's own thread, from "Help in setting up a RAM Disk".  I started this diversion)
>
>> 2. The main function is called with echo off and a record separator of newline, and no known way of entering a ^D/EOF to terminate the program. Here's the results of entering 'print("where is my echo")<LF>' at the console to Lua, followed by ^D<LF>:
>>
>> SMC91111 : driver has been attached
>> Device: /dev/pty0../dev/pty7 (8)pseudo-terminals registered.
>> telnetd started with stacksize = 8192 and priority = 100
>> RTEMS-RPCIOD $Release$, Till Straumann, Stanford/SLAC/SSRL 2002, See LICENSE file for licensing info.
>> RTEMS-NFS $Release$, Till Straumann, Stanford/SLAC/SSRL 2002, See LICENSE file for licensing info.
>> RTEMS SHELL (Ver.1.0-FRC):/dev/console. Mar  6 2011. 'help' to list commands.
>> [/] # help main
>> main         - Run the "main program".
>> [/] # main
>> Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
>>> where is my echo
>>> stdin:1: unexpected symbol near 'char(4)'
>>>
>>
>> The same issue exists with telnet, though at least then you can shutdown the shell and Lua gets the EOF.
>>
>
> Chris wrote:
>
> "Why not capture the terminal settings and then restore them when you
> return ?
>
> "I am not sure what happens if we change the settings for commands. Some
> commands may access stdin and may be written for the current term settings."
>
> The shell already saves the terminal settings before explicitly putting the terminal in a RAWish mode.  I could change my function that calls main() to change back to normal TTY settings, but I think that it makes more sense to call functions from the shell in a normal, cooked mode and not one of the RAW modes.  I haven't worked with any other script-caller that puts the TTY in a weird mode before calling user-written C code.
>

Yes. I am not opposed to setting the terminal to the original setting 
before calling the command. As stated the concern is breaking existing 
tested commands that happen to work because of the current settings.

> I tried disabling setting RAW in the shell and there is at least one odd side effect: Something echoes the command you type a second time prior to calling the user-supplied C function - see the repeated "help" message that follows.  I added the "-" and "+", and<^D>  is the<^D>  I typed. The "+" shows the extra line.

What happens if you save the raw settings, restore the original settings 
make the call then put back the raw settings ?

>
> Echo and EOF work properly.  The only thing I noticed is the odd extra echo.
>
> - [/] # help
> + help
> - help: ('r' repeat last cmd - 'e' edit last cmd)
> -   TOPIC? The topics are
> -    web, misc, flash, help, mem, files, rtems, network, monitor
> - [/] # main
> + main
> - Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> ->   <^D>
> - [/] #
>
> I will see if I can get the shell working the way I think it should with all the shell commands that come with RTEMS.
>

If you can do this then I would be happy to accept a patch.

Chris