Introduce the ShellSortFileList() function, for sorting an
EFI_SHELL_FILE_INFO list, by FileName or by FullName.
Duplicates can be kept in the same list, or separated out to a new list.
In either case, the relative order between duplicates does not change (the
sorting is stable).
For the sorting, use OrderedCollectionLib rather than SortLib:
- The PerformQuickSort() function from the latter has quadratic worst-case
time complexity, plus it is implemented recursively (see
"MdeModulePkg/Library/UefiSortLib/UefiSortLib.c"). It can also not
return an error on memory allocation failure.
- In comparison, the Red-Black Tree instance of OrderedCollectionLib sorts
in O(n*log(n)) worst-case time, contains no recursion with the default
PcdValidateOrderedCollection=FALSE setting, and the OrderedCollectionLib
class APIs return errors appropriately.
The OrderedCollectionLib APIs do not permit duplicates natively, but by
using lists as collection entries, stable sorting of duplicates can be
achieved.
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3151
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Message-Id: <20210113085453.10168-7-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The UefiShellAcpiViewCommandLib is converted from NULL library to a
named library so that it may be used in modules other than shell.
The library interface exposes the main method for to AcpiView
functionality as well as a helper method to dump a buffer to a file.
The Shell module is still built by pulling UefiShellAcpiViewCommandLib
as a NULL library to preserve the modularity of shell builds.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Tomas Pilar <tomas.pilar@arm.com>
The UefiShell*CommandsLib instances have constructor functions that do
something like:
gHiiHandle = HiiAddPackages (...);
...
ShellCommandRegisterCommandName (..., gHiiHandle, ...);
and destructor functions that implement the following pattern:
HiiRemovePackages (gHiiHandle);
The -- semantic, not functional -- problem is that "gHiiHandle" is
declared with type EFI_HANDLE, and not EFI_HII_HANDLE, in all of these
library instances, even though HiiAddPackages() correctly returns
EFI_HII_HANDLE, and HiiRemovePackages() takes EFI_HII_HANDLE.
Once we fix the type of "gHiiHandle", it causes sort of a butterfly
effect, because it is passed around widely. Track down and update all of
those locations.
The DynamicCommand lib instances use a similar pattern, so they are
affected too.
NOTE: in practice, this patch is a no-op, as both EFI_HII_HANDLE and
EFI_HANDLE are typedefs to (VOID*). However, we shouldn't use EFI_HANDLE
where semantically EFI_HII_HANDLE is passed around.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
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 slash, then the input path is
relative to the current working directory of the current file system.
Otherwise, it is an absolute path within the current file system.
If it does include a file system reference, it may be a reference to the
current or some other file system. If the file system reference is not
immediately followed by a forward or backward slash, then the input path
is relative to the current working directory of the given file system.
Otherwise, it is an absolute path within the given file system.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jim Dailey <jim_dailey@dell.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
The ShellOpenFileByDevicePath() API promises to set the DeviceHandle
output parameter to the handle of the filesystem identified by the
FilePath input parameter. However, this doesn't actually happen when the
UEFI Shell 2.0 method is used (which is basically "always" nowadays).
Accordingly, the only caller of ShellOpenFileByDevicePath(), namely
ShellOpenFileByName(), defines a (dummy) local DeviceHandle variable just
so it can call ShellOpenFileByDevicePath().
Remove the useless output parameter.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1008
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
1. Do not use tab characters
2. No trailing white space in one line
3. All files must end with CRLF
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
MAX_FILE_NAME_LEN and FIND_XXXXX_FILE_BUFFER_SIZE are not used
by ShellLib so remove them.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
DumpHex() and CatSDumpHex() are public library APIs but don't have
EFIAPI modifier. Add the missing EFIAPI.
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 more proper place for macro SHELL_FREE_NON_NULL is ShellLib.h
instead of ShellBase.h.
Modify Compress.c to resolve build failure due to this change.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
This reverts commit c0bcd3433f.
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>
This reverts commit 0fcf8d4df8.
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>
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>