1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Problem with UnicodeOutput

Discussion in 'Support' started by Jim Cook, Nov 26, 2008.

  1. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    I recently set UnicodeOutout=Yes and then got some very funny results.

    I'm using "cmd /?" simply as a test program that generates text output.

    This exists at least back to 4NT 6, and I don't understand why it
    would behave this way. Appending to the clipboard appears to be
    different than just writing to it. Using "LIST CLIP:" shows that the
    first part of the file is Unicode (16 bit wide characters), but the
    second half is ASCII (8 bit wide characters).

    D:\>Option //UnicodeOutput=No
    D:\>cmd /? > clip:
    D:\>cmd /? >>clip:
    D:\>*tail clip:

    The completion code deals correctly with file names that contain spaces
    or other special characters by placing quotes around the matching path.
    Also, if you back up, then invoke completion from within a line, the
    text to the right of the cursor at the point completion was invoked is
    discarded.

    The special characters that require quotes are:
    <space>
    &()[]{}^=;!'+,`~

    However, when I set UnicodeOutput:
    D:\>Option //UnicodeOutput=Yes
    D:\>cmd /? > clip:
    D:\>cmd /? >>clip:
    D:\>*tail clip:
    The completion code deals correctly with file names that contain spaces
    or other special characters by placing quotes around the matching path.
    Also, if you back up, then invoke completion from within a line, the
    text to the right of the cursor at the point completion was invoked is
    discarded.

    The special characters that require quotes are:
    <space>
    &()[]{}^=;!'+,`~
    ??????????????????????????????????????????????????????????????????????+???????????????+++?????4????????????????????????????
    ++??????????????????????????????+++????????????????????????????????++?????????/++??????????????????????????????????+++?????
    ???4???????????????????????????++?????????????????????????????????+++????????+?????????????????????????????????????+???????
    ?????
    etc.

    --
    Jim Cook
    2008 Fridays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Saturday.
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,991
    Likes Received:
    84
    UnicodeOutput only affects the output of TCC's internal commands, not the
    output of external apps (see the help).

    If you do something like this:

    dir /? > clip:
    dir /? >> clip:

    you'll see that everything is saved as expected.

    You'll have to ask Microsoft why CMD behaves that way.

    Rex Conn
    JP Software
     
  3. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0

    I disagree with the statement that UnicodeOutput does not affect the
    output of external apps.

    As evidence, I used the simplest "Hello world" program:

    #include <stdio.h>
    int main(int argc, char * argv[])
    {
    printf("Hello world\n");
    }

    Then I ran it like this
    Option //UnicodeOutput=Yes
    helloworld.exe > clip:
    helloworld.exe >>clip:
    list /x clip:

    Touching the U key once shows this output:

    0000 ff fe 48 00 65 00 6c 00 6c 00 6f 00 20 00 77 00 ”H.e.l.l.o. .w.
    0010 6f 00 72 00 6c 00 64 00 0d 00 0a 00 48 65 6c 6c o.r.l.d.....Hell
    0020 6f 20 77 6f 72 6c 64 0d 0a 00 o world...

    Running the same test with //UnicodeOutput=No does what I would expect:

    0000 48 65 6c 6c 6f 20 77 6f 72 6c 64 0d 0a 48 65 6c Hello world..Hel
    0010 6c 6f 20 77 6f 72 6c 64 0d 0a lo world..

    I submit that the only difference is the UnicodeOutput setting.

    If I've missed something here, I'm more than happy to admit my
    ignorance and be educated.

    --
    Jim Cook
    2008 Fridays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Saturday.
     
  4. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0

    I disagree with the statement that UnicodeOutput does not affect the
    output of external apps.

    As evidence, I used the simplest "Hello world" program:

    #include <stdio.h>
    int main(int argc, char * argv[])
    {
    printf("Hello world\n");
    }

    Then I ran it like this
    Option //UnicodeOutput=Yes
    helloworld.exe > clip:
    helloworld.exe >>clip:
    list /x clip:

    Touching the U key once shows this output:

    0000 ff fe 48 00 65 00 6c 00 6c 00 6f 00 20 00 77 00 ”H.e.l.l.o. .w.
    0010 6f 00 72 00 6c 00 64 00 0d 00 0a 00 48 65 6c 6c o.r.l.d.....Hell
    0020 6f 20 77 6f 72 6c 64 0d 0a 00 o world...

    Running the same test with //UnicodeOutput=No does what I would expect:

    0000 48 65 6c 6c 6f 20 77 6f 72 6c 64 0d 0a 48 65 6c Hello world..Hel
    0010 6c 6f 20 77 6f 72 6c 64 0d 0a lo world..

    I submit that the only difference is the UnicodeOutput setting.

    If I've missed something here, I'm more than happy to admit my
    ignorance and be educated.

    --
    Jim Cook
    2008 Fridays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Saturday.
     

Share This Page