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--