Changes to rtems_shell_script() working directory?

[Gedare Bloom]

On Mon, Jun 29, 2015 at 2:53 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
>
>
> On 28/06/15 16:38, Peter Dufault wrote:
>>>
>>> On Jun 28, 2015, at 07:20 , Peter Dufault <dufault at hda.com> wrote:
>>>
>>> Does anyone know of changes in how the shell starts up that would affect
>>> the current working directory?  My
>>> "rc_file()" function no longer works, I see the output "shell: open input
>>> init.rc failed: No such file or directory” on the console.
>>>
>>> Note that the rc_file() function verified the file existed with stat()
>>> before calling rtems_shell_script().
>>>
>>> This is RTEMS 4.11 on the Phytec MPC5554 updated this AM and previously
>>> updated last September.  I can’t attach the debugger at the moment because
>>> this is at a remote site.
>>>
>>> void rc_file(const char *name)
>>> {
>>>   struct stat st;
>>>   if (stat(name, &st) == 0) {
>>>     if (rtems_shell_script(
>>>       "RUN_RC",
>>>       rc_file.stacksize,
>>>       rc_file.priority,
>>>       name,
>>>       "/dev/console",
>>>       1,  /* Output append. */
>>>       1,  /* Wait. */
>>>       0   /* Echo. */
>>>     )) {
>>>       fprintf(stderr, "Error running \"%s\".\n", name);
>>>     }
>>>   }
>>> }
>>>
>>>
>> Now I’m confused.  When an RTEMS classic task is started does it inherit
>> the current working directory of the creating task?
>
>
>
> It has nothing to do with the task type.  In rtems_shell_run() we have
>
>   getcwd(shell_env->cwd, sizeof(shell_env->cwd));
>
> So the new environment will inherit the current working directory at some
> point.
>
>> It fails at line 772 of shell.c at the following test, which would only
>> work if the new task was still in the current working directory of the task
>> that created it:
>>
>>    if (shell_env->input && strcmp(shell_env_arg->input, "stdin") != 0) {
>>      FILE *input = fopen(shell_env_arg->input, "r");
>>      if (!input) {                                          // XXX Line
>> 772, fails here.
>>        fprintf(stderr, "shell: open input %s failed: %s\n",
>>                shell_env_arg->input, strerror(errno));
>>        return false;
>>      }
>>      stdin = input;
>>      stdinToClose = input;
>>      shell_env->forever = false;
>>      input_file =true;
>>    }
>>
>> However, further down in the file at line 861 it checks to see if an
>> input_file is open and if so changes to the current working directory of the
>> creating task, which is only needed if the new task isn’t in the current
>> working directory of the task that created it:
>>
>>          if (input_file)
>>            chdir(shell_env->cwd);                               // XXX
>> Line 861, why the chdir()?
>>          else
>>            chdir("/"); /* XXX: chdir to getpwent homedir */
>>
>> This appears to be the same as from last September, so it shouldn’t have
>> been working before if it doesn’t work now.
>>
>> I’m going to change it to do the chdir() before the fopen() and see if
>> that then works.
>
>
> If you search for rtems_shell_run in the testsuite, then you will get no
> hits. The shell code is largely untested, it doen't check the return status
> of several functions and I guess there are some resource leaks.
>
This would be a good module for targeting with coverage, and a good
motivator for the SOCIS work to get coverage reports working
"per-module".

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users