Andrew =E2=80= =93

There is a standard call that provides this service, but I am portin= g over BSD utils to the shell and they just take a straight path and call o= pen. So I want open to behave the way I expect it to. IN fact, the low leve= l code separates out the =E2=80=9Cdrive=E2=80=9D=C2=A0 from the path alread= y, but the current library doesn=E2=80=99t add in the mappings into the lis= t that gets created (it is used for stdin: stdout: and stderr:) The thing i= s that the underlying Shell APIs do handle this case, but the mapping is st= ripped before it gets to that layer.

Tim

From: dev= el@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Andrew F= ish via Groups.Io
Sent: Wednesday, September 4, 2019 5:35 PM
<= b>To: devel@edk2.groups.io; tim.lewis@insyde.com
Subject: Re:= [edk2-devel] Mappings and StdLib

Tim,

I do= n't know about the plans with the StdLib, but I do remember a long time ago= with the old shell there was a protocol that let you translate volume name= s (mappings) into handles and device paths.

S= o you could write a simple library that has 2 styles of APIs:

1) Handle + FilePath in Shell mapping with= Volume Name out

2) Shell fil= e path with mapping Volume names in and Simple File System handle Out with = the file path

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 a) A device path out version of this is al= so useful

You can make the lib just error return if= the Shell protocol does not exist so you don't make it a requirement. The = caller handles that failure as the current working volume/directory case.&n= bsp;

Thanks,

Andrew Fish

On S= ep 4, 2019, at 5:14 PM, Tim Lewis <tim.lewis@insyde.com> wrote:

Following up on my= last e-mail, I guess I had the wrong assumption: there doesn=E2=80=99t app= ear to be a way to resolve mappings within StdLib.

= Are there any plans here?
&nb= sp;
Thanks,

Tim

------=_NextPart_000_03BF_01D563D4.31354950-- From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: insyde.com, ip: 210.71.195.43, mailfrom: tim.lewis@insyde.com) Received: from out03.hibox.biz (out03.hibox.biz [210.71.195.43]) by groups.io with SMTP; Thu, 05 Sep 2019 13:06:07 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2AMAAD3aXFd/w00GKxlGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUwYBAQELAYEVgW+BHBOEIYgciH+OfYQThgqBewkBAQEBAQEBAQE?= =?us-ascii?q?IIwwBAYQ/AoJZNAkOAgwBAQUBAQEBAQYEhVhDDIVKAQECAwgCGQohOAUJDQQ?= =?us-ascii?q?EAQEOGgMCGxgVCQgCBAESCwUNBIMCgR18qyCBMhoChBoBgRSFBYE0AYFig3+?= =?us-ascii?q?ILYQjPoRQKoJVglgEjFCIJ4EhlhgHiRmFDIhlG4MjilkDineMT4Erh32RCIF?= =?us-ascii?q?SghBwUIJsCTaIWYgPU49MAQE?= X-IronPort-AV: E=Sophos;i="5.64,471,1559491200"; d="scan'208,217";a="23109178" Received: from unknown (HELO hb3-BKT203.hibox.biz) ([172.24.52.13]) by out03.hibox.biz with ESMTP; 06 Sep 2019 04:06:04 +0800 Received: from unknown (HELO hb3-BKT103.hibox.biz) ([172.24.51.13]) by hb3-BKT203.hibox.biz with ESMTP; 06 Sep 2019 04:06:04 +0800 Received: from unknown (HELO hb3-IN04.hibox.biz) ([172.24.12.14]) by hb3-BKT103.hibox.biz with ESMTP; 06 Sep 2019 04:06:04 +0800 X-Remote-IP: 172.24.133.53 X-Remote-Host: No hostname X-SBRS: None X-MID: 29955033 X-Auth-ID: tim.lewis@insyde.com X-EnvelopeFrom: tim.lewis@insyde.com Received: from unknown (HELO DESKTOPHG9V3E8) ([172.24.133.53]) by hb3-IN04.hibox.biz with ESMTP/TLS/AES256-SHA; 06 Sep 2019 04:06:02 +0800 From: "Tim Lewis" To: , , In-Reply-To: <15C19AC418D00FDA.11246@groups.io> Subject: Re: [edk2-devel] Mappings and StdLib Date: Thu, 5 Sep 2019 13:06:00 -0700 Message-ID: <05a701d56425$590a9150$0b1fb3f0$@insyde.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG2Hv1Kk5ewBjI7DGySViFJd8T5zKdcDEtg Content-Type: multipart/alternative; boundary="----=_NextPart_000_05A8_01D563EA.ACAD8E10" Content-Language: en-us ------=_NextPart_000_05A8_01D563EA.ACAD8E10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ok, now I found my answer. DevShell library class must be included with Std= Lib in order to correctly process shell-style input parameters. Without it,= it falls back on DevConsole =20 Thanks, Tim =20 From: devel@edk2.groups.io On Behalf Of Tim Lewis Sent: Thursday, September 5, 2019 10:25 AM To: devel@edk2.groups.io; afish@apple.com Subject: Re: [edk2-devel] Mappings and StdLib =20 Andrew =E2=80=93 =20 There is a standard call that provides this service, but I am porting over= BSD utils to the shell and they just take a straight path and call open. S= o I want open to behave the way I expect it to. IN fact, the low level code= separates out the =E2=80=9Cdrive=E2=80=9D from the path already, but the = current library doesn=E2=80=99t add in the mappings into the list that gets= created (it is used for stdin: stdout: and stderr:) The thing is that the = underlying Shell APIs do handle this case, but the mapping is stripped befo= re it gets to that layer. =20 Tim =20 From: devel@edk2.groups.io > On Behalf Of Andrew Fish via Groups.I= o Sent: Wednesday, September 4, 2019 5:35 PM To: devel@edk2.groups.io ; tim.lewis@insyde.= com =20 Subject: Re: [edk2-devel] Mappings and StdLib =20 Tim, =20 I don't know about the plans with the StdLib, but I do remember a long tim= e ago with the old shell there was a protocol that let you translate volume= names (mappings) into handles and device paths.=20 =20 So you could write a simple library that has 2 styles of APIs: 1) Handle + FilePath in Shell mapping with Volume Name out 2) Shell file path with mapping Volume names in and Simple File System han= dle Out with the file path a) A device path out version of this is also useful =20 You can make the lib just error return if the Shell protocol does not exis= t so you don't make it a requirement. The caller handles that failure as th= e current working volume/directory case.=20 =20 Thanks, =20 Andrew Fish =20 On Sep 4, 2019, at 5:14 PM, Tim Lewis > wrote: =20 Following up on my last e-mail, I guess I had the wrong assumption: there = doesn=E2=80=99t appear to be a way to resolve mappings within StdLib. =20 Are there any plans here? =20 Thanks, =20 Tim =20 ------=_NextPart_000_05A8_01D563EA.ACAD8E10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Ok, now I found= my answer. DevShell library class must be included with StdLib in order to= correctly process shell-style input parameters. Without it, it falls back = on DevConsole

Thanks,

Tim

From: devel@edk2.groups.io <devel@edk2.groups.io> On Be= half Of Tim Lewis
Sent: Thursday, September 5, 2019 10:25 AM<= br>To: devel@edk2.groups.io; afish@apple.com
Subject: Re: = [edk2-devel] Mappings and StdLib

Andrew =E2=80=93<= /p>

There is = a standard call that provides this service, but I am porting over BSD utils= to the shell and they just take a straight path and call open. So I want o= pen to behave the way I expect it to. IN fact, the low level code separates= out the =E2=80=9Cdrive=E2=80=9D from the path already, but the curre= nt library doesn=E2=80=99t add in the mappings into the list that gets crea= ted (it is used for stdin: stdout: and stderr:) The thing is that the under= lying Shell APIs do handle this case, but the mapping is stripped before it= gets to that layer.

Tim

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Andrew Fish= via Groups.Io
Sent: Wednesday, September 4, 2019 5:35 PM
T= o: devel@edk2.groups.io; tim.lewis@insyde.com
Subjec= t: Re: [edk2-devel] Mappings and StdLib

Tim,

I don't know about the plans with the StdLib, but I do remember a lon= g time ago with the old shell there was a protocol that let you translate v= olume names (mappings) into handles and device paths.

<= /div>

So you could write a simple library that has 2 styles of APIs:

1) Handle + FilePath in Shell ma= pping with Volume Name out

2)= Shell file path with mapping Volume names in and Simple File System handle= Out with the file path

&nb= sp; a) A device path out version of th= is is also useful

You can make the lib just error r= eturn if the Shell protocol does not exist so you don't make it a requireme= nt. The caller handles that failure as the current working volume/directory= case.

Thanks,

Andrew= Fish

On Sep 4, 2019, at 5:14 PM, Tim Lewis <= tim.lewis@insyde.com> wrote:=

Following up on my last e-mail, I guess I had the wrong = assumption: there doesn=E2=80=99t appear to be a way to resolve mappings wi= thin StdLib.

Are there any plans here?

Thanks,
<= o:p>
Tim

------=_NextPart_000_05A8_01D563EA.ACAD8E10--