[RTEMS Project] #3877: No output from joel scripts in telnet (cloned)
trac at rtems.org
Tue Feb 18 02:54:45 UTC 2020
#3877: No output from joel scripts in telnet (cloned)
Reporter: Chris Johns | Owner: (none)
Type: defect | Status: new
Priority: normal | Milestone: 4.11.4
Component: shell | Version: 4.11
Severity: normal | Keywords:
Blocked By: 3870 | Blocking:
Cloned from #3859:
Running a `joel` script in a telnet session results in the output being
sent to the global `stdout`. For example:
$ telnet 18.104.22.168
Connected to 22.214.171.124.
Escape character is '^]'.
RTEMS Shell on /dev/pty0. Use 'help' to list commands.
[/] # cat j
ls -las /
[/] # ./j
The bug is a new shell main loop task will default to the global `stdout`,
`stdin` etc and has no information about the parent's `std` handles. A
`joel` script runs in it's own work task and does not know the telnet's
There are a related set of issues in the handling of the `shell_env`
variable, POSIX key handling and the use of the external call
The telnet example in `libbsd` has:
telnet_shell(char *name, void *arg)
memset(&env, 0, sizeof(env));
env.devname = name;
env.taskname = "TLNT";
env.login_check = NULL;
env.forever = false;
This is problematic as control of the `env` has been lost and this make
backwards comptatable changes difficult. Control of this `struct` needs to
be brought back under the shell code.
Currently the posix key is set in the parent task only when the run entry
point is used. The run's created `shell_env` is then passed to the shell's
main loop task as an argument from which it is cloned. This means an `env`
is `malloc`ed in each run call and again in the main loop of the shell.
The current code leaks memory as repeated calls to a `joel` script in a
shell will set the key over and over. The destructor is only called when
the task is deleted. We have to assume the cleanup of any `shell_env`
allocated externally to the shell code has to be handled externally.
Setting the key in the main loop task is problematic because telnet code
such as the example in `libbsd` uses a local stack `shell_env` and the key
has a destructor that blindly `free`'s the key's memory when a task is
1. Add `parent_stdout`, `parent_stdin`, and `parent_stderr` to the
`shell_env` and set to the parent's `std` handles.
2. Add a `managed` flag to `shell_env` and only set when allocated by
`rtems_shell_init_env`. Change `rtems_shell_env_free` to only `free` the
`shell_env` if `managed`.
3. Remove all key sets and have only one in the shell's main loop code.
4. Change `rtems_shell_init_env` to get the current tasks key and clone
that before cloning the global env.
5. Update `rtems_shell_dup_current_env` to set the parent `std` handles.
6. Have the main loop use the parent `std` handles rather than the global
7. Check the `magic` field has been set in the shell's main loop and raise
an error if not set. The only code to set this field should reside in
`shell.c`. Code such as `libbsd` will need to call
Ticket URL: <http://devel.rtems.org/ticket/3877>
RTEMS Project <http://www.rtems.org/>
More information about the bugs