Problem with UnicodeOutput

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
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.
 

rconn

Administrator
Staff member
May 14, 2008
10,158
86
#2
>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:
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
>>I recently set UnicodeOutout=Yes and then got some very funny results.

> UnicodeOutput only affects the output of TCC's internal commands, not the
> output of external apps (see the help).
> dir /? > clip:
> dir /? >> clip:
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
>>I recently set UnicodeOutout=Yes and then got some very funny results.

> UnicodeOutput only affects the output of TCC's internal commands, not the
> output of external apps (see the help).
> dir /? > clip:
> dir /? >> clip:
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.