I think that the changes look fine. Note that we have switched to GIT for our source control. This would be must better as a series of 3 or 4 changes. I had to manually edit all of the 3 diff files (modified ones attached) to get them to be merged in. There was "too much path" as you did the file path from above the root of the revision controlled system.
There are additional changes required before this is committed. You need to update the INF files for the library and the shell itself and change the revision minor by +1. -Jaben From: [email protected] [mailto:[email protected]] Sent: Monday, February 08, 2016 11:03 AM To: Carsey, Jaben <[email protected]> Cc: Qiu, Shumin <[email protected]> Subject: RE: [edk2] [PATCH] ShellPkg Fix ASCII and UNICODE file pipes Importance: High Strange. I didn't see them on the mailing list posting, but I assumed the list had stripped them. They are attached to the message that is in my outbox. I'll just blame Outlook and say that for no particular reason, it decided to cause trouble. :) I have attached them here too. Hopefully you'll get them this time. Regards, Jim -----Original Message----- From: Carsey, Jaben [mailto:[email protected]] Sent: Monday, February 08, 2016 12:50 PM To: Dailey, Jim Cc: Carsey, Jaben Subject: RE: [edk2] [PATCH] ShellPkg Fix ASCII and UNICODE file pipes I don't see any attachments... > -----Original Message----- > From: edk2-devel [mailto:[email protected]] On Behalf Of > [email protected]<mailto:[email protected]> > Sent: Monday, February 08, 2016 9:45 AM > To: [email protected]<mailto:[email protected]> > Cc: Carsey, Jaben ; Qiu, Shumin > > Subject: [edk2] [PATCH] ShellPkg Fix ASCII and UNICODE file pipes > Importance: High > > ShellPkg: Fix ASCII and UNICODE file pipes. > > 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 > > (diff files attached) > > > _______________________________________________ > edk2-devel mailing list > [email protected]<mailto:[email protected]> > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
