[PATCH] shell: Add rtems_shell_dup_current_env to get a default env.

[Gedare Bloom]

On Wed, Jun 4, 2014 at 7:07 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 2014-06-04 12:55, Chris Johns wrote:
>>
>> On 4/06/2014 4:28 pm, Sebastian Huber wrote:
>>>
>>> On 2014-05-29 07:10, Chris Johns wrote:
>>>>
>>>> Remove rtems_current_shell_env as this is dangerous because
>>>> the env can be NULL if used outside of a valid shell with the
>>>> POSIX key to an env set up.
>>>>
>>>> Clean up the usage of rtems_current_shell_env.
>>>
>>>
>>> The cleanup looks good, but we should keep the rtems_global_shell_env.
>>> I underestimated its widespread use, so it was an error that we removed
>>> it.  Now it is a constant, so you can use it only for the initialization
>>> with default values.
>>>
>>
>> I would rather this API cleaned up and only a single way for applications
>> to do
>> this. It is a simple and clean change.
>>
>> The change I have uses the environment of a caller if the caller has a
>> specific
>> environment in the key else the base it used, ie inherits the environment
>> if
>> present.
>
>
> This is definitely better and we should add this
> rtems_shell_dup_current_env(), but I would nonetheless keep the
> rtems_global_shell_env for backward compatibility.
>
Is it feasible to provide a macro for rtems_global_shell_env that
provides the compatibility?

We should definitely put it on the list to eliminate at least after
4.11 (*prod*)

-Gedare

>
> --
> 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.
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel