Re: [edk2-devel] Shell feature?

["Carsey, Jaben" <jaben.carsey@intel.com>]

That makes sense. So really what we are missing is a method to associate a file with a command (required to support dynamic commands).

We could do that in lots of ways, but the first I think of is to add a new API in the ShellProtocol to perform this association.

Do we also need a shell command for a user to view/edit the file associations?

Do associations need to maintain over a reboot?

-Jaben





> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Andrew
> Fish via Groups.Io
> Sent: Tuesday, February 11, 2020 6:08 PM
> To: Carsey, Jaben <jaben.carsey@intel.com>
> Cc: devel@edk2.groups.io; jim.dailey@dell.com; tim.lewis@insyde.com
> Subject: Re: [edk2-devel] Shell feature?
> 
> Jaben,
> 
> My example was confusing, but my use case was to put this code in a library
> that adds a command. So after I register the command I’d like to register the
> file type to be processed by it.
> 
> Making an alias for an external command could be a different feature?
> > On Feb 11, 2020, at 5:30 PM, Carsey, Jaben <jaben.carsey@intel.com>
> wrote:
> >
> > Andrew
> >
> > You can already add a command via a driver (including a driver's library).
> Check into the Dynamic Commands in the shell spec.
> >
> > Associating a file type with a command, basically if the first thing on the
> command line is a file of that type, then prepend the command and re-
> process the line, is very doable. It's almost like the alias feature that already
> exists.
> >
> > I do agree with Tim that we should do a spec update, but concurrent
> development of code and spec seems required to prevent re-doing the spec.
> >
> > -Jaben
> >
> >> -----Original Message-----
> >> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Jim
> >> Dailey
> >> Sent: Tuesday, February 11, 2020 1:31 PM
> >> To: devel@edk2.groups.io
> >> Cc: tim.lewis@insyde.com; afish@apple.com
> >> Subject: Re: [edk2-devel] Shell feature?
> >>
> >> Andrew,
> >>
> >> Granted such a feature would be nice, but it seems like it might be a
> >> fair amount of trouble just to avoid typing "python3", which could be
> >> aliased to something as short a "p".
> >>
> >> Jim
> >>
> >> -----Original Message-----
> >> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Tim
> >> Lewis
> >> Sent: Tuesday, February 11, 2020 2:28 PM
> >> To: devel@edk2.groups.io; afish@apple.com
> >> Subject: Re: [edk2-devel] Shell feature?
> >>
> >>
> >> [EXTERNAL EMAIL]
> >>
> >> Andrew --
> >>
> >> I think this is a good idea, but I think this is probably a shell
> >> spec issue because I don't want competing, incompatible
> implementations.
> >>
> >> A few other issues: I think there is a persistence issue (similar to
> >> shell
> >> variables) so that the change could be installed and survive a
> >> reboot. I also think there can be a simple shell command that manages
> >> extensions (so that they can be installed by a script)
> >>
> >> Tim
> >>
> >> -----Original Message-----
> >> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> Andrew
> >> Fish via Groups.Io
> >> Sent: Monday, February 10, 2020 12:12 PM
> >> To: devel@edk2.groups.io
> >> Subject: [edk2-devel] Shell feature?
> >>
> >> I wanted to start a conversation on the mailing list prior to writing
> >> up a BZ, to make sure I'm not missing anything, or in case there is a
> >> better way to implement this.
> >>
> >> I was thinking it would be good to have a Shell API that lets you
> >> associate a file type with an internal or external shell command. The
> >> Idea would be to pre-pend the internal/external shell command to the
> >> file name and also pass the arguments.
> >>
> >> So this:
> >> fs0:>dump.py 1  2 3
> >>
> >> Becomes:
> >> fs0:>python3.efi dump.py 1  2 3
> >>
> >> Basically you just need an API like:
> >>
> >> ShellAddScriptingLanguage (L".py", L"python3.efi");
> >>
> >> Seems like this could just plug into the Shell via a ShellExecute().
> >> So for example you could make Python a UEFI Shell command via a
> >> library and that library constructor could also teach the shell that
> >> a .py file could be an executable?
> >>
> >> Thanks,
> >>
> >> Andrew Fish
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> 
>