My recollection is that the code that parses a command line is
basically the same whether the line is in a script or not.
Certainly there are places where that code checks to see if a
script is active, but I don't think it does so when it looks
to eliminate comments.
-Original Message-
Jaben,
The shell does not parse properly (my opinion) in some instances.
That is one of the reasons I wrote a separate parser for the shell I
maintain here at Dell.
One of the areas I feel the parsing is wrong is when an unescaped "#"
is inside a quoted string:
FS0:\> echo "This should #
Liming and Mike,
I don't feel there is any logical issue with this proposed fix.
However, there is some shell code that fails when the fix is in place.
I think that shell code probably should be changed; I'll see if I can
make an acceptable change there first.
Please disregard this patch; I'll
Oops! I think this change may have an issue.
Hold off and I'll let you know if that's the case.
--Jim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Dailey,
Jim
Sent: Friday, November 30, 2018 9:12 AM
To: liming@intel.com;
PathCleanUpDirectories does not handle "\..\" properly; it
returns "\" instead of "". This change fixes that
problem so that "" is returned.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jim Dailey
---
MdePkg/Library/BaseLib/FilePaths.c | 7 ++-
1 file changed, 6
Yes, Ray, that is the code block that I meant. It serves no purpose since
InputPath cannot possibly be NULL in that part of the code.
I appreciate your help in deleting this block and pushing the rest of the
patch. Also, thanks for your thorough review of this code (and the first
version)!
>-Original Message-
>From: Ni, Ruiyu [mailto:ruiyu...@intel.com]
>Sent: Tuesday, October 30, 2018 2:33 AM
>To: Dailey, Jim; edk2-devel@lists.01.org
>Cc: Carsey, Jaben
>Subject: RE: [PATCH v2 1/2] ShellPkg-UefiShellLib: Add a function to
>fully-qualify paths
>
>
>> -Original
Add a function to return a clean, fully-qualified version of some path.
This function handles a (possibly "dirty") input path that may or may
not include a file system reference.
If it does not include a file system reference, then if the input path
does not begin with a forward or backward
Provide fully-qualified path to shell scripts
Section 3.6.2 of version 2.2 of the shell specification requires that
the first positional argument (i.e. arg 0) of a shell script resolves
to "the full path name of the script itself."
Ensure that the startup script and any scripts launched by the
On Thursday, October 25, 2018 12:48 AM ruiyu...@intel.com wrote:
>On 10/25/2018 12:35 AM, jim.dai...@dell.com wrote:
>> Add a function to return the fully-qualified version of some path.
>>
>> ...
>> +CHAR16*
>> +EFIAPI
>> +FullyQualifyPath(
>> + IN OUTCHAR16 **Path
>This API assumes
Section 3.6.2 of version 2.2 of the shell specification requires that
the first positional argument (i.e. arg 0) of a shell script resolves
to "the full path name of the script itself."
Ensure that the startup script and any scripts launched by the shell
meet this requirement.
Contributed-under:
Add a function to return the fully-qualified version of some path.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jim Dailey
---
ShellPkg/Include/Library/ShellLib.h | 40 +
ShellPkg/Library/UefiShellLib/UefiShellLib.c | 93 +++-
2 files
Is the line:
Size = gST->Hdr.HeaderSize;
possibly a better way of handling this? Either way:
Reviewed-by: Jim Dailey
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni
Sent: Thursday, October 11, 2018 2:53 AM
To:
>-Original Message-
>From: Ni, Ruiyu [mailto:ruiyu...@intel.com]
>Sent: Monday, October 8, 2018 9:55 PM
>To: Dailey, Jim
>Cc: michael.d.kin...@intel.com; liming@intel.com; edk2-devel@lists.01.org
>Subject: Re: [edk2] [PATCH] MdePkg-BaseLib: Fix PathCleanUpDirectories() error
Resending, as I never saw this email on the mailing list.
>-Original Message-
>From: Ni, Ruiyu [mailto:ruiyu...@intel.com]
>Sent: Monday, October 8, 2018 2:00 AM
>To: Dailey, Jim; edk2-devel@lists.01.org
>Cc: michael.d.kin...@intel.com; liming@intel.com
>Subject: Re: [edk2] [PATCH]
>-Original Message-
>From: Ni, Ruiyu [mailto:ruiyu...@intel.com]
>Sent: Monday, October 8, 2018 1:42 AM
>To: Dailey, Jim; edk2-devel@lists.01.org
>Cc: jaben.car...@intel.com
>Subject: Re: [edk2] [PATCH] ShellPkg: Create a homefilesystem environment
>variable
>
>
>On 10/4/2018 12:02 AM,
>-Original Message-
>From: Ni, Ruiyu [mailto:ruiyu...@intel.com]
>Sent: Monday, October 8, 2018 2:00 AM
>To: Dailey, Jim; edk2-devel@lists.01.org
>Cc: michael.d.kin...@intel.com; liming@intel.com
>Subject: Re: [edk2] [PATCH] MdePkg-BaseLib: Fix PathCleanUpDirectories() error
Replace multiple, consecutive "\" characters prior to other processing
involving "\" characters. This fixes an issue where "\\..\\..",
"//..//..", and similar input paths are not cleaned properly.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jim Dailey
---
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
>Ersek
I'll attempt answer some of your questions, but Jaben may have to
answer some of them (like his commit speed :-) or questions about what
the shell spec allows).
>
>So my first question would have been, what if
ShellPkg-Cd: Ensure all valid cd targets are handled properly
Make sure that PathCleanUpDirectories() is called on all valid targets
of the cd command.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jim Dailey
---
ShellPkg/Library/UefiShellLevel2CommandsLib/Cd.c | 8
MdePkg-BaseLib: Fix PathCleanUpDirectories() error involving "\..\.."
The loop that removes "\..\" errs when multiple "\.." sequences are
in the path. Before this change the code would modify a path like
"FS0:\efi\tools\..\.." to "FS0:\efi\\.." and then to "FS0:\efi\", but
the correct path
Create a homefilesystem environment variable whose value is the file
system on which the executing shell is located. For example: "FS14:".
This eliminates the need for people to have to try and find the "boot"
file system in their startup script. After this change they can simply
execute
The InvalidChars[] array is only used in function IsValidCommandName().
The array should be deleted also, I think.
Regards,
Jim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of shenglei
Sent: Thursday, August 9, 2018 12:42 AM
To:
Reviewed-by: Jim Dailey
-Original Message-
From: Ruiyu Ni [mailto:ruiyu...@intel.com]
Sent: Wednesday, August 8, 2018 12:04 AM
To: edk2-devel@lists.01.org
Cc: Jaben Carsey; Dailey, Jim
Subject: [PATCH v2] ShellPkg/set: Fix EfiShellSetEnv to use case sensitive
compare
REF:
Ray,
Table 8 in version 2.2 of the Shell Spec says "lasterror" (lower-case L). Why
compare to "Lasterror"?
Regards,
Jim
-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Tuesday, August 7, 2018 12:57 PM
To: Ni, Ruiyu; edk2-devel@lists.01.org
Cc: Dailey, Jim
Thanks, Mike. I figured that out yesterday.
I think the only problem now is that any shell built with the original change
to edit will not work as expected if it is run on a system whose BIOS was
created before the second change was made (i.e. pretty much every existing UEFI
BIOS in the
Yes! Sorry if I was unclear.
-Original Message-
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Monday, June 4, 2018 11:22 AM
To: Dailey, Jim
Cc: af...@apple.com; Ni, Ruiyu; edk2-devel@lists.01.org; fel...@mail.ru;
Rothman, Michael A
Subject: Re: [edk2] How to Interpret
Please disregard the stupid "Confidential" line that our email tool
adds but hides from me when I send text. :-(
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Dailey,
Jim
Sent: Monday, June 4, 2018 11:00 AM
To: af...@apple.com
Cc:
Dell - Internal Use - Confidential
> From: af...@apple.com [mailto:af...@apple.com]
>
> The big picture difference is the original SimpleTextIn was the least common
> denominator with a serial terminal. The Ex version added more info about
> keyboards, so richer info on modifier keys.
I get
>Thanks/Ray
>
>> From: jim.dai...@dell.com
>>
>> I guess this is a question of UEFI spec interpretation. In the Console
>> I/O Protocol description of Version 2.5 of the spec (page 456), it says:
>>
>> If the Scan Code is set to 0x00 then the Unicode character is
>> valid and should
(Subject changed)
I guess this is a question of UEFI spec interpretation. In the Console
I/O Protocol description of Version 2.5 of the spec (page 456), it says:
If the Scan Code is set to 0x00 then the Unicode character is
valid and should be used.
To me that clearly says it all. The
Ray,
The patch in the message below was applied to the tree on 12 Feb this
year (5563281fa2b31093a1cbd415553b9264c5136e89).
Part of the change to MainTextEditor.c causes an issue where I cannot
enter (at least some) shifted punctuation. For example, after this
check in I cannot edit a shell
Please excuse the stupid email plug-in I have to use that puts the
"Internal Use" line in my text emails. The plug-in does not allow
me to see that text, so I have to remember to remove it every time
even though I never see it. Sadly, I sometimes forget.
-Original Message-
From:
Dell - Internal Use - Confidential
You need to use the shell's GUID, gShellVariableGuid, if you want to
create a shell variable.
Regards,
Jim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tiger Liu
Sent: Friday, November 3, 2017 12:01 AM
To:
Isn't ReallocatePool is the correct function to use in these cases?
For example:
NewCommandLine1 = ReallocatePool(NewSize, StrSize(OriginalCommandLine),
OriginalCommandLine;
Regards,
Jim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ni,
The shell spec says that "Each environment variable has a case-sensitive
name ...".
In the EfiShellSetEnv function of ShellProtocol.c a case-insensitive
compare is performed against the variable that is to be set to see if it
is one of the read-only variables. That means one cannot set a
I think the technicality here is that given "pci < inputfile", no
parameters are passed to the pci command, so it should, according to
the spec, display all the devices.
Another problem may be that in the "pci < inputfile" case, the pci
command has no way to know that its input is being
The shell's pci command was not written to read from standard input. It
expects all its input on the command line.
I would say in general that if you execute a command and pass it no
parameters, and it then prompts you in some way for input, then that
command will likely accept input redirected
Laszlo,
Are there any special considerations for Print() statements with respect
to the 80 character line length?
If "No", what is the preferred format if one wants to print strings that
are 80 or more characters such as:
Print(L"123456789 123456789 123456789 123456789 123456789 123456789
It is a tricky problem.
What I would like is for a new protocol to be defined, which should
not rely on devices, to contain certain identifying information
like this that would be useful to device drivers. It could be
created early in DXE.
What I fear is some future requirement that SMBIOS be
Not a helpful comment, but I wanted to air my feelings on the topic:
I view SMBIOS as data strictly for OS-level consumption and not for
any pre-boot code. I'm sure I'm in the minority, however.
One of the problems is that the BIOS needs to have scanned all
devices/resources and perhaps
Although this question is about the shell's drvdiag command, the answer
is related to the interpretation of the UEFI specification with respect
to the diagnostics protocol's RunDiagnostics() function.
Ultimately, the question is, is the drvdiag command in error in trying
to free the ErrorType
Thanks, Jaben. That makes sense.
Now I see the real issue is with the "app" I ran across. It is a driver,
and it was trying to access command line args. The driver crashed when
it tried to access the command line, but it had been loaded in memory via
the "load" command.
So, it seems "load" has
A question or two for all shell experts:
In the UEFI Shell Lib constructor code, if the Shell protocol cannot
be opened, then an attempt is made to locate it before "giving up".
However, if the Shell parameters protocol cannot be opened, no attempt
is made to locate it---the code simply leaves
Dell - Internal Use - Confidential
Thanks, Jeff. I wasn't thinking that through properly.
Printing the address and size seems ok. Then one could use dmem, for
example, to dump the actual data.
-Original Message-
From: Jeff Westfahl [mailto:jeff.westf...@ni.com]
Sent: Friday,
My point was that printing one byte of the data as hex is not much better (as
far
as avoiding the crash is concerned) than simply not printing the data at all.
If
we are just trying to avoid the crash, printing nothing is even simpler.
If the correct representation is hex bytes, fine; but why
Please disregard the earlier "Confidential" text. The stupid plug-in that adds
this
does not show the text in the mail when it is composed in text mode, so I often
forget to turn this "feature" off when posting. Sorry.
-Original Message-
From: edk2-devel
Dell - Internal Use - Confidential
Jeff,
Perhaps a better approach is to print *all* the LoadOptions data as hex bytes?
In addition, one might first analyze the LoadOptions data, and, when apropos,
print obvious strings as strings?
Regards,
Jim
-Original Message-
From: edk2-devel
48 matches
Mail list logo
