| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Commit bd3fc8133b2b ("ShellPkg/App: Fix memory leak and save resources.",
2016-05-20) added a FreePool() call for Split->SplitStdIn, near end of the
RunSplitCommand(), right after the same shell file was closed with
CloseFile(). The argument was:
> 1) RunSplitCommand() allocates the initial SplitStdOut via
> CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix
> the memory leak.
There is no memory leak actually, and the FreePool() call in question
constitutes a double-free:
(a) This is how the handle is established:
ConvertEfiFileProtocolToShellHandle (
CreateFileInterfaceMem (Unicode),
NULL
);
CreateFileInterfaceMem() allocates an EFI_FILE_PROTOCOL_MEM object and
populates it fully. ConvertEfiFileProtocolToShellHandle() allocates
some administrative structures and links the EFI_FILE_PROTOCOL_MEM
object into "mFileHandleList".
(b) EFI_SHELL_PROTOCOL.CloseFile() is required to close the
SHELL_FILE_HANDLE and to release all associated data. Accordingly,
near the end of RunSplitCommand(), we have:
EfiShellClose()
ShellFileHandleRemove()
//
// undoes the effects of ConvertEfiFileProtocolToShellHandle()
//
ConvertShellHandleToEfiFileProtocol()
//
// note that this does not adjust the pointer value; it's a pure
// type cast
//
FileHandleClose()
FileInterfaceMemClose()
//
// tears down EFI_FILE_PROTOCOL_MEM completely, undoing the
// effects of CreateFileInterfaceMem ()
//
The FreePool() call added by bd3fc8133b2b conflicts with
SHELL_FREE_NON_NULL(This);
in FileInterfaceMemClose(), so remove it.
This error can be reproduced for example with:
> Shell> map | more
> 'more' is not recognized as an internal or external command, operable
> program, or script file.
which triggers:
> ASSERT MdeModulePkg/Core/Dxe/Mem/Pool.c(624): CR has Bad Signature
with the following stack dump:
> #0 0x000000007f6dc094 in CpuDeadLoop () at
> MdePkg/Library/BaseLib/CpuDeadLoop.c:37
> #1 0x000000007f6dd1b4 in DebugAssert (FileName=0x7f6ed9f0
> "MdeModulePkg/Core/Dxe/Mem/Pool.c", LineNumber=624,
> Description=0x7f6ed9d8 "CR has Bad Signature") at
> OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c:153
> #2 0x000000007f6d075d in CoreFreePoolI (Buffer=0x7e232c98,
> PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:624
> #3 0x000000007f6d060e in CoreInternalFreePool (Buffer=0x7e232c98,
> PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:529
> #4 0x000000007f6d0648 in CoreFreePool (Buffer=0x7e232c98) at
> MdeModulePkg/Core/Dxe/Mem/Pool.c:552
> #5 0x000000007d49fbf8 in FreePool (Buffer=0x7e232c98) at
> MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:818
> #6 0x000000007d4875c3 in RunSplitCommand (CmdLine=0x7d898398,
> StdIn=0x0, StdOut=0x0) at ShellPkg/Application/Shell/Shell.c:1813
> #7 0x000000007d487d59 in ProcessNewSplitCommandLine
> (CmdLine=0x7d898398) at ShellPkg/Application/Shell/Shell.c:2121
> #8 0x000000007d488937 in RunShellCommand (CmdLine=0x7e233018,
> CommandStatus=0x0) at ShellPkg/Application/Shell/Shell.c:2670
> #9 0x000000007d488b0b in RunCommand (CmdLine=0x7e233018) at
> ShellPkg/Application/Shell/Shell.c:2732
> #10 0x000000007d4867c8 in DoShellPrompt () at
> ShellPkg/Application/Shell/Shell.c:1349
> #11 0x000000007d48524d in UefiMain (ImageHandle=0x7e24c898,
> SystemTable=0x7f5b6018) at ShellPkg/Application/Shell/Shell.c:631
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Marvin Häuser <Marvin.Haeuser@outlook.com>
Cc: Qiu Shumin <shumin.qiu@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Fixes: bd3fc8133b2b17ad2e0427d1bf6b44b08cf2f3b2
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Marvin Häuser <Marvin.Haeuser@outlook.com>
|
|
The "SPLIT_LIST.SplitStdOut" and "SPLIT_LIST.SplitStdIn" members currently
have type (SHELL_FILE_HANDLE *). This is wrong; SHELL_FILE_HANDLE is
already a pointer, there's no need to store a pointer to a pointer.
The error is obvious if we check where and how these members are used:
- In the RunSplitCommand() function, these members are used (populated)
extensively; this function has to be updated in sync.
ConvertEfiFileProtocolToShellHandle() already returns the temporary
memory file created with CreateFileInterfaceMem() as SHELL_FILE_HANDLE,
not as (SHELL_FILE_HANDLE *).
- In particular, the ConvertShellHandleToEfiFileProtocol() calls need to
be dropped as well in RunSplitCommand(), since
EFI_SHELL_PROTOCOL.SetFilePosition() and EFI_SHELL_PROTOCOL.CloseFile()
take SHELL_FILE_HANDLE parameters, not (EFI_FILE_PROTOCOL *).
Given that ConvertShellHandleToEfiFileProtocol() only performs a
type-cast (it does not adjust any pointer values), *and*
SHELL_FILE_HANDLE -- taken by EFI_SHELL_PROTOCOL member functions -- is
actually a typedef to (VOID *) -- see more on this later --, this
conversion error hasn't been caught by compilers.
- In the ProcessNewSplitCommandLine() function, RunSplitCommand() is
called either initially (passing in NULL / NULL; no update needed), or
recursively (passing in Split->SplitStdIn / Split->SplitStdOut; again no
update is necessary beyond the RunSplitCommand() modification above).
- In the UpdateStdInStdOutStdErr() and RestoreStdInStdOutStdErr()
functions, said structure members are compared and assigned to
"EFI_SHELL_PARAMETERS_PROTOCOL.StdIn" and
"EFI_SHELL_PARAMETERS_PROTOCOL.StdOut", both of which have type
SHELL_FILE_HANDLE, *not* (SHELL_FILE_HANDLE *).
The compiler hasn't caught this error because of the fatally flawed type
definition of SHELL_FILE_HANDLE, namely
typedef VOID *SHELL_FILE_HANDLE;
Pointer-to-void silently converts to and from most other pointer types;
among them, pointer-to-pointer-to-void. That is also why no update is
necessary for UpdateStdInStdOutStdErr() and RestoreStdInStdOutStdErr()
in this fix.
(
Generally speaking, using (VOID *) typedefs for opaque handles is a tragic
mistake in all of the UEFI-related specifications; this practice defeats
any type checking that compilers might help programmers with. The right
way to define an opaque handle is as follows:
//
// Introduce the incomplete structure type, and the derived pointer
// type, in both the specification and the public edk2 headers. Note
// that the derived pointer type itself is a complete type, and it can
// be used freely by client code.
//
typedef struct SHELL_FILE *SHELL_FILE_HANDLE;
//
// Complete the structure type in the edk2 internal C source files.
//
struct SHELL_FILE {
//
// list fields
//
};
This way the structure size and members remain hidden from client code,
but the C compiler can nonetheless catch any invalid conversions between
incompatible XXX_HANDLE types.
)
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Marvin Häuser <Marvin.Haeuser@outlook.com>
Cc: Qiu Shumin <shumin.qiu@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
When user doesn't press key to exit the timeout waiting in Shell,
and there is no startup.nsh, Shell exits with failure status.
aaf51f08ee104447207bba571649556095befc93 introduced this bug.
The patch fixes this issue.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Chen A Chen <chen.a.chen@intel.com>
|
|
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
|
|
Cc: Chen A Chen <chen.a.chen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
|
|
According to Shell spec 2.2 '-exit' invocation option is used to specify
that after running the command line when launched, the UEFI Shell must
immediately exit.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen A Chen <chen.a.chen@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen A Chen <chen.a.chen@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
In QuarkPlatformPkg/Library/PlatformBootManagerLib/PlatformBootManager.c,
there is a definition of mUefiShellFileGuid which is a constant reference
to the FILE_GUID as defined in ShellPkg/Application/Shell/Shell.inf.
To prevent the need for duplicating it to other modules, promote it to
a proper global GUID, and add it to the ShellPkg.dec package declaration.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
For pointer subtraction, the result is of type "ptrdiff_t". According to
the C11 standard (Committee Draft - April 12, 2011):
"When two pointers are subtracted, both shall point to elements of the
same array object, or one past the last element of the array object; the
result is the difference of the subscripts of the two array elements. The
size of the result is implementation-defined, and its type (a signed
integer type) is ptrdiff_t defined in the <stddef.h> header. If the result
is not representable in an object of that type, the behavior is
undefined."
In our codes, there are cases that the pointer subtraction is not
performed by pointers to elements of the same array object. This might
lead to potential issues, since the behavior is undefined according to C11
standard.
Also, since the size of type "ptrdiff_t" is implementation-defined. Some
static code checkers may warn that the pointer subtraction might underflow
first and then being cast to a bigger size. For example:
UINT8 *Ptr1, *Ptr2;
UINTN PtrDiff;
...
PtrDiff = (UINTN) (Ptr1 - Ptr2);
The commit will refine the pointer subtraction expressions by casting each
pointer to UINTN first and then perform the subtraction:
PtrDiff = (UINTN) Ptr1 - (UINTN) Ptr2;
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
https://bugzilla.tianocore.org/show_bug.cgi?id=332
When the ShellLib ShellExecute() API or the Shell
Protocol Execute() API are used to execute a
command, the arguments are parsed to produce the
Argc/Argv list in the Shell Parameters Protocol and
double quotes are removed from arguments that are
surrounded by double quotes. This is the required
behavior of the Shell Parameters Protocol.
The ProcessCommandLine() function in the shell
implementation uses the Argc/Argv list from the
Shell Parameters Protocol to assemble a new command
line, but the double quotes that may have been
originally present for an argument are not preserved.
ProcessCommandLine() is updated to check if an
argument added to the generated command line
contains one or more white space characters, and
if it does, double quotes are added around the
argument.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
|
|
When ">v" is used to redirect the command output to environment
variable, the ending "\r\n\0" is removed before setting to environment
variable but the length is not updated.
It causes ">>v" fails to append data to the environment variable
created by ">v".
The patch fixes the above bug.
Signed-off-by: Chen A Chen <chen.a.chen@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
When ">v" is used to redirect the command output to environment
variable (e.g.: "echo xxx >v yyy"), we only called SetVariable()
to update the variable storage but forgot to update the cached
environment variables in gShellEnvVarList.
When updating the variable storage, the existing code unnecessary
saved the ending NULL character into variable storage.
The patch fixes all the above issues.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen A Chen <chen.a.chen@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Tapan Shah <tapandshah@hpe.com>
|
|
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
|
|
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
The destination GUID comes first; from
"MdePkg/Include/Library/BaseMemoryLib.h":
> GUID *
> EFIAPI
> CopyGuid (
> OUT GUID *DestinationGuid,
> IN CONST GUID *SourceGuid
> );
Here "NewGuid" is the GUID looked up by GetGuidFromStringName(), and
"Guid" is where EfiShellGetGuidFromName() has to propagate that result to.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Tim Lewis <tim.lewis@insyde.com>
Reported-by: Tim Lewis <tim.lewis@insyde.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Tim Lewis <tim.lewis@insyde.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen A Chen <chen.a.chen@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
|
|
Update CRC32 in the EFI System Table header after shell changes the
value of gST->ConsoleOutHandle and gST->ConOut
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia <cinnamon.shia@hpe.com>
Reviewed-By: Tapan Shah <tapandshah@hpe.com>
Reviewed-By: Jaben Carsey <Jaben.carsey@intel.com>
|
|
As per ECR 1349 change in UEFI Shell Specification 2.2, expanding
a special output file name to include "NULL". Previously it only
supported "NUL" as a special output file and it was case sensitive.
With this change both "NUL" and "NULL" are special output file and
checked as case insensitive.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tapan Shah <tapandshah@hpe.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
According to the latest shell spec, in function FindFiles(),
when no files were found, it should return EFI_NOT_FOUND.
But current codes don't follow the spec.
This patch is to fix this issue.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
|
|
This reverts commit c0bcd3433f33876c519bf5567e0ab69261b57fe9.
The above commit causes several regression of "echo" command:
1. Double quotes are not being stripped from the final text. UEFI Shell 2.2 section 3.4.5 chops out the quotes.
2. Output redirection is not working as expected. Text is being redirected, but the ‘> …’ text should not be.
3. Inconsistent special character handling. For example, comments with # seem to be parsed out correctly, but handing of ^ is incorrect.
In summary, ‘echo “You are ^#1” > t.txt’ results in the below content in t.txt:
“You are ^#1” > t.txt
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Tapan Shah <tapandshah@hpe.com>
|
|
When the FilePattern is similar to "fsx:EFI\BOOT", FindFiles()
cannot handle it correctly because it always assumes there is
"\\" after "fsx:".
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Tapan Shah <tapandshah@hpe.com>
|
|
It should shows files in root directory of current map.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Tapan Shah <tapandshah@hpe.com>
|
|
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Tapan Shah <tapandshah@hpe.com>
|
|
Commit 9168df3dea65f707d1e9c32eba5e18ef6b84e5cd
"ShellPkg/ShellProtocol.c: Handle memory allocation failure"
only keeps the protocol clean up in CleanUpShellProtocol() and
creates a new function CleanUpShellEnvironment() which calls
CleanUpShellProtocol(), then unregisters the hotkey callback.
But the commit forgot to change the Shell.c to call
CleanUpShellEnvironment() which causes the hotkey callback is
not unregistered while the callback function doesn't exist
when Shell exits.
This causes system hang when pressing CTRL+C after exiting shell.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
|
|
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
|
|
And add Shell prefix to the two library APIs.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
1) RunSplitCommand() allocates the initial SplitStdOut via
CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix
the memory leak.
2) In RunSplitCommand(), SplitStdOut is checked for equality with
StdIn. This cannot happen due to the if-check within the swap.
Hence remove it.
3) UefiMain() doesn't free SplitList. Delete all list entries and
reinitialize the list when in DEBUG. This does not include the
CreateFileInterfaceMem()-allocated SplitStd mentioned in 1), so
keep the ASSERT() until resolved.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com>
Reviewed-by: Qiu Shumin <shumin.qiu@intel.com>
|
|
The EFI_UNICODE_COLLATION_PROTOCOL can have two different GUIDs.
Look for both to support more UEFI implementations.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com>
Reviewed-by: Qiu Shumin <shumin.qiu@intel.com>
|
|
If 'ReadKeyStroke' function return EFI_NOT_READY then skip it.
If the return value is EFI_DEVICE_ERROR clean the currentString buffer.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Pedroa Liu <pedroa.liu@insyde.com>
Reviewed-by: Qiu Shumin <shumin.qiu@intel.com>
|
|
CC: Qiu Shumin <shumin.qiu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com>
Reviewed-by: Qiu Shumin <shumin.qiu@intel.com>
|
|
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Qiu Shumin <shumin.qiu@intel.com>
|
|
UEFI Shell 2.x cannot recognize whether a .EFI file is an application or
a driver. This means when we typed in a driver image in Shell command
line, Shell will load the driver image and try to run the entry point
function of the driver.
This patch check the ImageCodeType to fix the issue.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin <shumin.qiu@intel.com>
|
|
the performance.
Currently UEFI Shell reads variable storage to get the environment
variables every time running a new command. And reading(writing)
UEFI variables is a high cost operation on most platforms. In order
to enhance the performance this patch read the variable storage once
and cache the environment variables in memory. Every further 'set'
command will save the variable not only to Shell cache, but also the
flash variable storage.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin <shumin.qiu@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by:Ruiyu Ni <ruiyu.ni@intel.com>
|
|
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Shumin Qiu <shumin.qiu@intel.com>
|
|
The BuildOptions for AARCH64 in Application/Shell/Shell.inf only affect
the core Shell binary, and not the Shell component libraries which are
merged into the final Shell binary via NULL library class resolution.
This means we need to override the UEFI_APPLICATION build options in
the platform .DSC anyway, there is no point in setting these options
here as well. So remove them.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
|
|
Remove the unused local variable to refine the code.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc:Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin <shumin.qiu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
|
|
This patch makes Shell support -nonesting invocation option. This option
specifies that EFI_SHELL_PROTOCOL.Execute API nesting of a new Shell
instance is optional and dependent on the 'nonesting' Shell environment
variable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Qiu Shumin <shumin.qiu@intel.com>
Reviewed-by: Jim Dailey <Jim_Dailey@Dell.com>
|
|
Free 'FoundFileList' when read 'TAB' key fail to avoid memory leak and ASSERT.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin <shumin.qiu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
|
|
Use DOS format end of line(CR, LF).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin <shumin.qiu@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
If data of any real size were to be piped from one command to another,
an inordinate amount of time could be taken up by reallocating memory
that is only 10 bytes bigger than what is currently needed. Also, this
could cause unwelcome memory fragmentation.
Added a define to control how much memory is reallocated beyond that
which is currently needed. Set it to 1K vs. the original 10 bytes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jim Dailey <jim_dailey@dell.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jim Dailey <jim_dailey@dell.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
The shell uses the memory file structure to manage temporary files in
memory that support piping of output from one command into the the
input of another command. The BufferSize member is the size of the
internal buffer, not the size of the data that was written to the
file. So, it was possible to read beyond the EOF of these files as
reads used BufferSize. Now FileSize tracks the actual size of these
files (the number of bytes written, not the number of bytes available
in the buffer), and the reads use this member.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jim Dailey <jim_dailey@dell.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
If the BOM is stripped from StdIn, then an app that duplicates StdIn
will not be able to duplicate, say, a UCS2 file that was piped into
it (the output file it creates would not start with a BOM).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jim Dailey <jim_dailey@dell.com>
Reviewed-by: Jaben Carsey <Jaben.Carsey@intel.com>
|
|
UEFI Shell scandalizes the help message in spec level so that a standalone
UEFI shell application can never get "-?" switch, instead the Shell core
(interpreter) detects the "-?" and finds .MAN file for that shell
application in certain spec defined paths, then show the help extracted
from that .MAN file.
But it means distributing a UEFI shell application not only means
distributing a .EFI file but also distributing a .MAN file. If the text
formatted .MAN file is corrupted (edited by user by mistake), or is
missing (deleted by user by mistake), no help will be shown to user.
So this patch enhance the Shell to make it support finding help message
imbedded in resource section of application image.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin <shumin.qiu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
|
|
The pointer 'FileInterface->Buffer' returned from 'AllocateZeroPool' in function
'CreateFileInterfaceMem' may be NULL and will be dereferenced at the following code.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin <shumin.qiu@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
|
Fix various errors when piping a UNICODE or ASCII file to a simple shell application that reads standard input and writes it to standard output.
1) When the memory file is created by CreateFileInferfaceMem() to capture the pipe output, no UNICODE BOM is written to the memory file. Later, when the memory file is read by the application using ShellFileHandleReadLine(), the function indicates that the file is ASCII because there is no BOM.
2) If the file is piped as ASCII, the ASCII memory image is not correctly created by FileInterfaceMemWrite() as each ASCII character is followed by '\0' in the image (when the ASCII data is written to the memory image, the file position should only be incremented by half the buffer size).
3) ShellFileHandleReadLine() does not read ASCII files correctly (writes to Buffer need to be cast as CHAR8*).
4) FileInterfaceMemRead() and FileInterfaceMemWrite() as somewhat hard to read and difficult to debug with certain tools due to the typecasting of This. Added a local variable (MemFile) of the correct type to these functions and used it instead of This.
Enhancement: ShellFileHandleReadLine() now returns EFI_END_OF_FILE when appropriate.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jim Dailey <jim_dailey@dell.com>
reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
|
