shell question was Re: Current snapshot fails to build if networking is disabled

OUTWATER ~ KEITH J /5G3110 vac4050 at tueng.rsc.raytheon.com
Mon Jun 4 21:26:23 UTC 2001


Fernando - 
Thanks for the info.  
I'm currently registering lots of additional commands with the RTEMS monitor 
using the RTEMS monotor's command entry type.

Are you saying that once I've registered the additional commands with the RTEMS 
monitor that they are automatically availble in the shell?

Also, It would be nice to have command completion (may be the ability to type in 
partial commands or some typ ef auto-completion)

Keith

> >
> > OUTWATER ~ KEITH J /5G3110 wrote:
> > >
> > > Greetings -
> > >
> > > When building the current snapshot, the build fails in
> > ./libmisc/shell/telnetd.c
> > > if networkig (--disable-networking) is disabled.
> >
> > Thanks for reporting this.  I noticed it after cutting the
> > snapshot myself
> > and Fernando has fixed it.  My understanding is that the
> > telnetd portion
> > will be moved to be part of the rtems_servers under libnetworking.
> >
> Sorry. I have moved (and submitted) the telnetd.c and pty.c
> at libnetworking/rtems_telnetd directory.
> The include files are <rtems/telnetd.h> and <rtems/pty.h>.
> This is the reason to don't include it in rtems_servers with ftpd.c.
> 
> the ftpd server has its include like #include <ftpd.h>. :-(
> 
> > > This happens with the gen68360 BSP (as well as the new one
> > I'm trying to write
> > > :) )
> > >
> > > BTW, does/will the telnet server allow new commands to be
> > registered in EXACTLY
> > > the same was as th current monitor code does?
> 
> YES!!!! But
> The current TELNETD doesn't support the monitor commands.
> 
> It's shell.c who supports the new commands and ALL the commands in the
> monitor commands table.
> 
> If you add the old monitor commands before to call at
> shell_init() you have it AUTOMATICALY added in the shell.
> 
> You can execute 'help monitor' to see like ALL the monitor
> commands  have been added at the shell.c command list.
> 
> You can test all of this without TCP/IP enabled.
> 
> Only a /dev/console (Termios of course) device
> to call at shell_init().
> Before or after you can add the diferent custom commands that you want.
> shell_cmd_add() register the new commands.
> 
> But you need call this AFTER that you have add your monitor commands.
> The first time that shell_init() is called the register_cmds() is called.
> 
> At this moment the current monitor_command_list is readed and added the
> commands to
> shell command list.
> 
> The reason to change the monitor command header is very simple.
> The monitor doesn't return an errorlevel value.
> The next improvement in the shell.c is add script posibilities and
> environment variables expansion.
> Can you think in a script loop without errorlevel posibilities?
> 
> This is the reason to make this.
> 
> >
> > I will leave this to Fernando.  The stuff that the shell does
> > support is
> > nice since it growsa the capabilities of the old monitor considerably.
> > For instance, the networking statistics can now be displayed.
> 
> Sorry. Only the test appliccation add this feature.
> (A question of tcp-ip enabled..) Very easy to implement it.
> 
> Eric help me to place it in the correct place.
> 
> >
> > I would like to see the capability to hook any "shell" to the telnetd
> > portion since that would make it possible to use the same
> > infrastructure
> > to put a product specific shell in.
> >
> > > Keith
> The pseudo-terminals are termios terminals in tcp/ip environment.
> Can you build a specific shell with a termios device?
> If you answer is affirmative you can touch the telnetd (Very simple)
> and to adapt the code source at your needs.
> (Sorry but OOB is not implemented at this moment)
> 
> Do you want any example? Ask me.
> 
> But it is important to make a main difference.
> 
> shell.c is the improved monitor (Multiuser,...)
> 
> telnetd.c and pty.c are the support to run shell.c in tcp/ip environment.
> 
> Do you want a new shell or a new telnet service?
> 
> >
> > --
> > Joel Sherrill, Ph.D.             Director of Research & Development
> > joel at OARcorp.com                 On-Line Applications Research
> > Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> > Support Available                (256) 722-9985
> >
> 
> Joel. Please.
> See the imfs_eval.c because the Jeniffer patch perhaps isn't applied. CDUP.
> Have you researched around taskvardelete (tasks.c) pointer?. I need change
> it because
> my test program fails.
> 
> Fernando RUIZ CASAS
> home: correo at fernando-ruiz.com
> work: fernando.ruiz at ctv.es
> 
> 
> 


More information about the users mailing list