Re: [question] A piece of log.txt showed in uefi shell is not the same as showed in notepad++

[krishnaLee <sssky307@163.com>]

Andrew Fish,
Yes,I know it ,from a terminal's view,the 0x0C/0x0D/0x0E/...,some invisible chars like this have special means,
and I also think from a text-editor's view, I think the text-editor just do not show them,and should make sure all visible chars can visible,
but I think I am wrong.


> How did you dump the log?
I got a piece of buffer from uefi-shell's screen-buffer,when I output my buffer,I find it is not correctly aligned as history output.
because the screen-buffer's width is 'terminal_column_size + 2',the last extra two UINT16 maked this question,
I think when the terminal output a full line(terminal_column_size),it will automatically go to new line's begin,
CR is means go to most left corner of screen,,so I make the last two char with "CR+CR",the cursor will stay at the new line's begin;
and make the (CHAR16==0) to (CHAR16==SPACE),so all lines are (full line+CR+CR),except last line end is (CR+LF),
 and the result is aligned as the history showed.
but some times the result is missed some strings...


I may got what happened,the question is "...make the (CHAR16==0) to (CHAR16==SPACE),so all lines are (full line+CR+CR)"��
the lines may not all full line because some invisible will taken no space in terminal,it is not a full line,so CR+CR will make the line overlapped/disappeared.
I had mixed using text-editor's view and terminal's view in uefi,it's my fault.
I can duplicate this fault by follow test code:
//test-code-start
EFI_STATUS
EFIAPI
UefiMain (
  IN EFI_HANDLE        ImageHandle,
  IN EFI_SYSTEM_TABLE  *SystemTable
  )
{
  EFI_STATUS status;
  EFI_SHELL_PROTOCOL*                     shell;
  EFI_SHELL_PARAMETERS_PROTOCOL*          param;
#defineONE_LINE (100+2)
  CHAR16 buffer[ONE_LINE];
  UINTN bufferSize = ONE_LINE *sizeof(CHAR16);


for(UINTN i=0;i<ONE_LINE;i++)
  {
    buffer[i]=0x0020;
  }


  buffer[ONE_LINE-8]=L'a';
  buffer[ONE_LINE-7]=L'b';
  buffer[ONE_LINE-6]=L'c';


  buffer[ONE_LINE-4]=L'O';
  buffer[ONE_LINE-3]=L'K';
  buffer[ONE_LINE-2]=0x000D;
  buffer[ONE_LINE-1]=0x000A;


  status=gBS->LocateProtocol(&gEfiShellProtocolGuid,NULL,&(shell));
if(status!=EFI_SUCCESS)
  {
return0;
  }


  status=gBS->HandleProtocol(gImageHandle,&gEfiShellParametersProtocolGuid,&(param));
if(status!=EFI_SUCCESS)
  {
return0;
  }


Print(L"test1:\n");
  shell->WriteFile(param->StdOut,&bufferSize,buffer);
  shell->FlushFile(param->StdOut);


Print(L"test2:\n");
  buffer[ONE_LINE-9]=0x000D;
  buffer[ONE_LINE-5]=0x000D;
  shell->WriteFile(param->StdOut,&bufferSize,buffer);
  shell->FlushFile(param->StdOut);


return EFI_SUCCESS;
}
//test-code-end
thank you,
krishna.



At 2019-01-25 01:45:00, "Andrew Fish" <afish@apple.com> wrote:
Krishna,


From an EFI point of view BackSpace 0x08, LF 0x0A, and CR 0xD are defined for a ConOut device. 


From Ascii Control Codes:
0x0C - Form Feed
0x0E - Shift Out


The Shift Out is used with graphics characters. 


How did you dump the log? If EFI sends data to a serial terminal then it would use terminal emulation and the output stream would look different. 


Thanks,


Andrew Fish



On Jan 23, 2019, at 11:07 PM, krishnaLee <sssky307@163.com> wrote:


Andrew Fish,
thank you,in this case,you are right.
but I think there may be other case that the user data just contain some nosense-data
such as { UINT16 MyData[]={0x000c,0x000d,0x000d,0x000e}  } to the editor, 
the uefi editor may also meet this question,the editor may do not need output this,
but the editor should make sure other visible chars can output normal...


I don't know if it is a bug or not.


Thank you very much.
krishna.





&#65533;&#65533; 2019-01-24 12:13:50&#65533;&#65533;"Andrew Fish" <afish@apple.com> д&#65533;&#65533;&#65533;&#65533;

On Jan 23, 2019, at 7:17 PM, krishnaLee <sssky307@163.com> wrote:


Hi,
I dumped a small log.txt from my work,but the log.txt showed in uefi shell,is not the same as it showed in notepad++.
I had upload the log here:
https://github.com/krishna116/test/blob/master/log.zip


it seems the log showed in uefi shell had missed some strings...I don't know why,please help,




Krishna,


Your log.txt looks like a normal UTF-16 Unicode file. The leading  FF FE is the Byte order mark for UTF-16 Little Endian [1].  The file looks like it has CR line endings [2] so maybe that is confusing your editor? There seems to be a CR LF at the end, so the mixture of line ending may even be more likely confusing the editor. The byte order mark should let your editor know it is 16-bit Unicode and the correct endian. Hope this helps...



$ hexdump -C /Users/andrewfish/Downloads/log/log.txt 
00000000  ff fe 20 00 20 00 20 00  4d 00 58 00 32 00 35 00  |.. . . .M.X.2.5.|
00000010  4c 00 31 00 32 00 38 00  37 00 35 00 46 00 20 00  |L.1.2.8.7.5.F. .|
00000020  20 00 20 00 20 00 49 00  44 00 3a 00 30 00 78 00  | . . .I.D.:.0.x.|
00000030  43 00 32 00 32 00 30 00  31 00 38 00 20 00 20 00  |C.2.2.0.1.8. . .|
00000040  20 00 20 00 53 00 69 00  7a 00 65 00 3a 00 20 00  | . .S.i.z.e.:. .|
00000050  31 00 36 00 33 00 38 00  34 00 4b 00 42 00 20 00  |1.6.3.8.4.K.B. .|
00000060  28 00 31 00 33 00 31 00  30 00 37 00 32 00 4b 00  |(.1.3.1.0.7.2.K.|
00000070  62 00 29 00 20 00 20 00  20 00 20 00 20 00 20 00  |b.). . . . . . .|
00000080  20 00 20 00 20 00 20 00  20 00 20 00 20 00 20 00  | . . . . . . . .|
*
000000c0  20 00 20 00 20 00 20 00  0d 00 0d 00 20 00 20 00  | . . . ..... . .|
000000d0  20 00 20 00 20 00 20 00  20 00 20 00 20 00 20 00  | . . . . . . . .|
*
00000190  20 00 20 00 0d 00 0d 00  20 00 20 00 20 00 20 00  | . ..... . . . .|
000001a0  4d 00 58 00 32 00 35 00  4c 00 36 00 34 00 37 00  |M.X.2.5.L.6.4.7.|
000001b0  33 00 45 00 20 00 20 00  20 00 20 00 49 00 44 00  |3.E. . . . .I.D.|
000001c0  3a 00 30 00 78 00 43 00  32 00 32 00 30 00 31 00  |:.0.x.C.2.2.0.1.|
000001d0  37 00 20 00 20 00 20 00  20 00 53 00 69 00 7a 00  |7. . . . .S.i.z.|
000001e0  65 00 3a 00 20 00 38 00  31 00 39 00 32 00 4b 00  |e.:. .8.1.9.2.K.|
000001f0  42 00 20 00 28 00 36 00  35 00 35 00 33 00 36 00  |B. .(.6.5.5.3.6.|
00000200  4b 00 62 00 29 00 20 00  20 00 20 00 20 00 20 00  |K.b.). . . . . .|
00000210  20 00 20 00 20 00 20 00  20 00 20 00 20 00 20 00  | . . . . . . . .|
*
00000260  0d 00 0d 00 20 00 20 00  20 00 20 00 20 00 20 00  |.... . . . . . .|
00000270  20 00 20 00 20 00 20 00  20 00 20 00 20 00 20 00  | . . . . . . . .|
*
00000320  20 00 20 00 20 00 20 00  20 00 20 00 0d 00 0d 00  | . . . . . .....|
00000330  53 00 50 00 49 00 20 00  42 00 41 00 52 00 3a 00  |S.P.I. .B.A.R.:.|
00000340  20 00 46 00 45 00 30 00  31 00 30 00 30 00 30 00  | .F.E.0.1.0.0.0.|
00000350  30 00 20 00 20 00 20 00  20 00 20 00 20 00 20 00  |0. . . . . . . .|
00000360  20 00 20 00 20 00 20 00  20 00 20 00 20 00 20 00  | . . . . . . . .|
*
000003f0  20 00 20 00 20 00 20 00  0d 00 0d 00 20 00 20 00  | . . . ..... . .|
00000400  20 00 20 00 20 00 20 00  20 00 20 00 20 00 20 00  | . . . . . . . .|
*
000004c0  20 00 20 00 0d 00 0d 00  46 00 50 00 54 00 20 00  | . .....F.P.T. .|
000004d0  4f 00 70 00 65 00 72 00  61 00 74 00 69 00 6f 00  |O.p.e.r.a.t.i.o.|
000004e0  6e 00 20 00 53 00 75 00  63 00 63 00 65 00 73 00  |n. .S.u.c.c.e.s.|
000004f0  73 00 66 00 75 00 6c 00  2e 00 20 00 20 00 20 00  |s.f.u.l... . . .|
00000500  20 00 20 00 20 00 20 00  20 00 20 00 20 00 20 00  | . . . . . . . .|
*
00000590  0d 00 0d 00 20 00 20 00  20 00 20 00 20 00 20 00  |.... . . . . . .|
000005a0  20 00 20 00 20 00 20 00  20 00 20 00 20 00 20 00  | . . . . . . . .|
*
00000650  20 00 20 00 20 00 20 00  20 00 20 00 0d 00 0d 00  | . . . . . .....|
00000660  0d 00 0a 00                                       |....|
00000664




[1] https://en.wikipedia.org/wiki/Byte_order_mark#UTF-16
[2] https://en.wikipedia.org/wiki/Newline


Thanks,


Andrew Fish





thank you,
by krishna.





_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel




\x16&#65533;&