Re: [9fans] xd bug - Plan9

This is a discussion on Re: [9fans] xd bug - Plan9 ; If you look more closely at the alignment of the characters to the hex values you will see that xd thinks Q has character code 0x525 and R has character code 3. It should look more like % xd -c ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: [9fans] xd bug

  1. Re: [9fans] xd bug

    If you look more closely at the alignment of the characters to the hex
    values you will see that xd thinks Q has character code 0x525 and R
    has character code 3. It should look more like

    % xd -c -x bad
    0000000 e0Q R S \n
    0 e0515253 0a000000
    0000005

    On Jul 14, 2008, at 12:43 PM, Russ Cox wrote:

    >> Hello. Regarding my previous question, the file /n/sources/contrib/
    >> pietro/xd.out shows a bug in xd regarding characters that can't be
    >> printed with the %c format. There should be no space between a non-
    >> printing and a printing character; but the two spaces screw the rest
    >> of the line up. This shows a deficiency in the table-based
    >> implementation. I'll do my best to fix it in a clean way. Thanks.

    >
    > It would help a lot if (1) you cut and pasted things into email
    > instead of making us go look on sources for four-line files
    > and (2) you told us exactly what you thought was wrong.
    >
    > Your xd.out says:
    >
    > % xd -c -x bad
    > 0000000 e0 Q R S \n
    > 0 e0515253 0a000000
    > 0000005
    >
    > which looks fine to me. If I create the same file and add some
    > more text just to fill things out, I get:
    >
    > % xd -c -b -x a | sed 6q
    > 0000000 e0 Q R S \n L o r e m i p s u m
    > 0 e0 51 52 53 0a 4c 6f 72 65 6d 20 69 70 73 75 6d
    > 0 e0515253 0a4c6f72 656d2069 7073756d
    > 0000010 d o l o r s i t a m e t ,
    > 10 20 64 6f 6c 6f 72 20 73 69 74 20 61 6d 65 74 2c
    > 10 20646f6c 6f722073 69742061 6d65742c
    >
    > which still looks just fine. In particular I don't see any
    > alignment difference between the first line and the second line.
    >
    > Russ
    >
    >




  2. Re: [9fans] xd bug

    > If you look more closely at the alignment of the characters to the hex
    > values you will see that xd thinks Q has character code 0x525 and R
    > has character code 3. It should look more like
    >
    > % xd -c -x bad
    > 0000000 e0Q R S \n
    > 0 e0515253 0a000000
    > 0000005


    -x by itself doesn't output the hex codes
    for bytes, it outputs the hex codes for 4 byte
    integers. i think you're thinking of this command
    line instead

    ; xd -c -1x bad
    0000000 e0 Q R S \n
    0 e0 51 52 53 0a

    - erik



  3. Re: [9fans] xd bug

    > If you look more closely at the alignment of the characters to the hex
    > values you will see that xd thinks Q has character code 0x525 and R
    > has character code 3. It should look more like
    >
    > % xd -c -x bad
    > 0000000 e0Q R S \n
    > 0 e0515253 0a000000
    > 0000005


    The -c and -x formats are not intended to align.
    If you want hex codes aligned with characters, use -b.

    % echo ABCD | xd -c -x
    0000000 A B C D \n
    0 41424344 0a000000
    0000005
    %

    Russ



  4. Re: [9fans] xd bug

    On Jul 14, 2008, at 1:13 PM, erik quanstrom wrote:
    > -x by itself doesn't output the hex codes
    > for bytes, it outputs the hex codes for 4 byte
    > integers. i think you're thinking of this command
    > line instead
    >
    > ; xd -c -1x bad
    > 0000000 e0 Q R S \n
    > 0 e0 51 52 53 0a



    On Jul 14, 2008, at 1:22 PM, Russ Cox wrote:
    > The -c and -x formats are not intended to align.
    > If you want hex codes aligned with characters, use -b.


    Thanks for the clarifications. -b == -1x, so both solve this
    misunderstanding.


+ Reply to Thread