You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Ville Juven <vi...@gmail.com> on 2023/03/09 10:14:23 UTC

Shell alias support for NSH

Hi all,

I'm in the process of writing support for shell aliases into NSH, but since
the shell is the front end for NuttX I decided to make a post here for
opinions on this matter and to open discussion for requirements, mostly to
prevent unexpected regression issues that might arise from this.

1. Are shell aliases seen as something useful in the community ? I need
them for a project of mine which is the reason I started implementing
support but I'd like to know if they are seen as useful whatsoever by
others.

2. To properly support aliases, the shell parser needs to support single
quotes and double quotes. This support will generate a bit of extra code
into the parser, is this seen as OK ?

alias foo='bar baz'
alias foo="bar $baz"

In both cases, the parser stops on the first delimiter (whitespace) even
though it is quoted.

3. I will implement support for *single quotes* as this is a simple case
but not for double quotes as the rules are more complex (need to perform
variable expansions etc). Is this seen as a blocker / fatal issue?

4. I added a Kconfig option to turn alias support on/off, what should the
default state of this option be ? Currently it is defined as follows:

config NSH_ALIAS
    bool "Enable alias support"
    default !DEFAULT_SMALL

I noticed that many of the shell features are flagged behind DEFAULT_SMALL.

Also the alias amount is configurable.

5. Currently aliases are implemented globally i.e. every shell shares the
same aliases, is this seen as a problem or should I make the aliases stick
to a shell session only ?

This is my first time posting on this board, so apologies if I did
something improper.

Br, Ville Juven

Re: Shell alias support for NSH

Posted by Ville Juven <vi...@gmail.com>.
Thanks for the responses

This feature already exist
> https://github.com/apache/nuttx-apps/blob/master/nshlib/Kconfig#L126-L146
>

As far as I can understand, that is for backquotes `foo` which is a type of
variable expansion. What I need is support for single quotes 'foo' which
means that whatever is inside '' is just a string litral. Or do you mean
that the variable expansion support is already there ?

Does posix say something about shells?
>

Yes POSIX demands that the aliases are stored per session only.

BR, Ville Juven

>
On Thu, Mar 9, 2023 at 12:35 PM Xiang Xiao <xi...@gmail.com>
wrote:

> On Thu, Mar 9, 2023 at 6:14 PM Ville Juven <vi...@gmail.com> wrote:
>
> > Hi all,
> >
> > I'm in the process of writing support for shell aliases into NSH, but
> since
> > the shell is the front end for NuttX I decided to make a post here for
> > opinions on this matter and to open discussion for requirements, mostly
> to
> > prevent unexpected regression issues that might arise from this.
> >
> > 1. Are shell aliases seen as something useful in the community ? I need
> > them for a project of mine which is the reason I started implementing
> > support but I'd like to know if they are seen as useful whatsoever by
> > others.
> >
> > 2. To properly support aliases, the shell parser needs to support single
> > quotes and double quotes. This support will generate a bit of extra code
> > into the parser, is this seen as OK ?
> >
> > alias foo='bar baz'
> > alias foo="bar $baz"
> >
> > In both cases, the parser stops on the first delimiter (whitespace) even
> > though it is quoted.
> >
> > 3. I will implement support for *single quotes* as this is a simple case
> > but not for double quotes as the rules are more complex (need to perform
> > variable expansions etc). Is this seen as a blocker / fatal issue?
> >
> >
> This feature already exist
> https://github.com/apache/nuttx-apps/blob/master/nshlib/Kconfig#L126-L146
>
>
> > 4. I added a Kconfig option to turn alias support on/off, what should the
> > default state of this option be ? Currently it is defined as follows:
> >
> > config NSH_ALIAS
> >     bool "Enable alias support"
> >     default !DEFAULT_SMALL
> >
> > I noticed that many of the shell features are flagged behind
> DEFAULT_SMALL.
> >
> > Also the alias amount is configurable.
> >
> > 5. Currently aliases are implemented globally i.e. every shell shares the
> > same aliases, is this seen as a problem or should I make the aliases
> stick
> > to a shell session only ?
> >
> >
>  It's better to follow the POSIX spec.
>
> This is my first time posting on this board, so apologies if I did
> > something improper.
> >
> > Br, Ville Juven
> >
>

Re: Shell alias support for NSH

Posted by Sebastien Lorquet <se...@lorquet.fr>.
Hi,

If I am not mistaken, the existing NSH_CMDPARMS feature will just 
execute the command once and copy the stdout into the var?

Aliases are more like virtual commands, that execute their contents when 
run.

This is distinct from built-in commands and user implemented programs.

Sebastien


Le 09/03/2023 à 11:34, Xiang Xiao a écrit :
> This feature already exist
> https://github.com/apache/nuttx-apps/blob/master/nshlib/Kconfig#L126-L146

Re: Shell alias support for NSH

Posted by Xiang Xiao <xi...@gmail.com>.
On Thu, Mar 9, 2023 at 6:14 PM Ville Juven <vi...@gmail.com> wrote:

> Hi all,
>
> I'm in the process of writing support for shell aliases into NSH, but since
> the shell is the front end for NuttX I decided to make a post here for
> opinions on this matter and to open discussion for requirements, mostly to
> prevent unexpected regression issues that might arise from this.
>
> 1. Are shell aliases seen as something useful in the community ? I need
> them for a project of mine which is the reason I started implementing
> support but I'd like to know if they are seen as useful whatsoever by
> others.
>
> 2. To properly support aliases, the shell parser needs to support single
> quotes and double quotes. This support will generate a bit of extra code
> into the parser, is this seen as OK ?
>
> alias foo='bar baz'
> alias foo="bar $baz"
>
> In both cases, the parser stops on the first delimiter (whitespace) even
> though it is quoted.
>
> 3. I will implement support for *single quotes* as this is a simple case
> but not for double quotes as the rules are more complex (need to perform
> variable expansions etc). Is this seen as a blocker / fatal issue?
>
>
This feature already exist
https://github.com/apache/nuttx-apps/blob/master/nshlib/Kconfig#L126-L146


> 4. I added a Kconfig option to turn alias support on/off, what should the
> default state of this option be ? Currently it is defined as follows:
>
> config NSH_ALIAS
>     bool "Enable alias support"
>     default !DEFAULT_SMALL
>
> I noticed that many of the shell features are flagged behind DEFAULT_SMALL.
>
> Also the alias amount is configurable.
>
> 5. Currently aliases are implemented globally i.e. every shell shares the
> same aliases, is this seen as a problem or should I make the aliases stick
> to a shell session only ?
>
>
 It's better to follow the POSIX spec.

This is my first time posting on this board, so apologies if I did
> something improper.
>
> Br, Ville Juven
>

Re: Shell alias support for NSH

Posted by Sebastien Lorquet <se...@lorquet.fr>.
Hello,

I think you did things very,very well, thank you for this.

Here is some feedback:

1 - aliases are not required for me, but It could still be a worthwile 
feature for others, and it's a requirement for you.

2 - this feels ok for me, since this is generally a better behaviour of 
the shell parser that would benefit other applications, I believe.

3 - partial implementation does not feel blocking for me. yes, double 
quotes are more complex. I think there is already a config variable for 
shell var extension? Can you plan your code to slightly facilitate 
future extensions if choices are to be made?

4 - for backwards compatibility, this feature should not be on by 
default, but it is a good general improvement of the shell, so with a 
notification in git logs, I could see this on by default. No strong 
opinion on this point.

5 - for this point, I would say aliases need to be per session, since 
global aliases with multiple shells could be security issues or just 
annoyance when you dont expect them to be there. Thats how it's made in 
linux shells, right? Does posix say something about shells?

I hope more people share their opinions soon.

Thank you again for the time you took to write this.

Sebastien


Le 09/03/2023 à 11:14, Ville Juven a écrit :
> Hi all,
>
> I'm in the process of writing support for shell aliases into NSH, but since
> the shell is the front end for NuttX I decided to make a post here for
> opinions on this matter and to open discussion for requirements, mostly to
> prevent unexpected regression issues that might arise from this.
>
> 1. Are shell aliases seen as something useful in the community ? I need
> them for a project of mine which is the reason I started implementing
> support but I'd like to know if they are seen as useful whatsoever by
> others.
>
> 2. To properly support aliases, the shell parser needs to support single
> quotes and double quotes. This support will generate a bit of extra code
> into the parser, is this seen as OK ?
>
> alias foo='bar baz'
> alias foo="bar $baz"
>
> In both cases, the parser stops on the first delimiter (whitespace) even
> though it is quoted.
>
> 3. I will implement support for *single quotes* as this is a simple case
> but not for double quotes as the rules are more complex (need to perform
> variable expansions etc). Is this seen as a blocker / fatal issue?
>
> 4. I added a Kconfig option to turn alias support on/off, what should the
> default state of this option be ? Currently it is defined as follows:
>
> config NSH_ALIAS
>      bool "Enable alias support"
>      default !DEFAULT_SMALL
>
> I noticed that many of the shell features are flagged behind DEFAULT_SMALL.
>
> Also the alias amount is configurable.
>
> 5. Currently aliases are implemented globally i.e. every shell shares the
> same aliases, is this seen as a problem or should I make the aliases stick
> to a shell session only ?
>
> This is my first time posting on this board, so apologies if I did
> something improper.
>
> Br, Ville Juven
>