redirection with pipe don't work

[wolle]

I use tc 14.03.51 x64 on OS Windows 7 64bit and if i try to redirect via pipe the result are always zero.

dir d:\ | findstr zip in a tcc shell the resut ist empty

[C:\Program Files\JPSoft\TCMD14x64]dir d:\ | findstr zip
[C:\Program Files\JPSoft\TCMD14x64]

in a cmd shell

C:\Program Files\JPSoft\TCMD14x64>dir d:\ | findstr zip
13.11.2012 10:43 546.365 deploy-tftp.zip
C:\Program Files\JPSoft\TCMD14x64>
Any ideas?

Cheers
Wolfgang

 

[rconn]

Not reproducible here. Do you have an alias for DIR?

TCC doesn't (cannot!) affect the FINDSTR behavior, but the DIR format is a little different between CMD and TCC.

 

[wolle]

the findstr is not the issue, if I use grep the result is the same. so I wil try to deinstall and install TC. I know that it works in all older versions, but I have no feeling at what time it begans to fail:-(.

 

[rconn]

What happens with a simple:

*dir | list

?

 

[wolle]

First the reinstalling was not really successfullyL

The output for *dir | list looks fine for me. Sorry the beginning, it’s GermanJ

STDIN │ F1 Hilfe │ Spalte 0 Zeile 1 0%
Datenträger in Laufwerk C ist unbezeichnet Seriennummer ist 7aac:4ecd
Verzeichnis von C:\Program Files\JPSoft\TCMD14x64\*

28.11.2012 14:58 <DIR> .
28.11.2012 14:58 <DIR> ..
14.11.2012 11:37 5.310 alias.lst
22.02.2006 21:40 34.304 BorlndMM.dll
26.11.2012 18:05 621.208 English.dll
…………

If I use ls.exe or fi.exe everything works fine.

If I use only one digit I get a result like this. If I copy this to notepad, there is a space between all characters.

[C:\Program Files\JPSoft\TCMD14x64]dir | findstr t
D a t e n t r õ g e r i n L a u f w e r k C i s t u n b e z e i c h n e t S e r i e n n u m m e r i s t 7 a a c : 4 e c d
V e r z e i c h n i s v o n C : \ P r o g r a m F i l e s \ J P S o f t \ T C M D 1 4 x 6 4 \ *
1 4 . 1 1 . 2 0 1 2 1 1 : 3 7 5 . 3 1 0 a l i a s . l s t
2 6 . 1 1 . 2 0 1 2 1 8 : 0 5 6 4 7 . 8 3 2 I t a l i a n . d l l
2 6 . 1 1 . 2 0 1 2 1 8 : 0 5 4 1 0 . 2 6 4 I t a l i a n D . d l l
2 9 . 0 6 . 2 0 1 2 2 1 : 5 2 9 . 4 6 9 l i c e n s e . t x t
2 9 . 0 6 . 2 0 1 2 2 1 : 5 2 7 . 1 3 1 r e a d m e . t x t
2 4 . 0 1 . 2 0 0 0 1 1 : 0 1 4 5 3 . 6 3 2 s t d v c l 4 0 . d l l
2 6 . 1 1 . 2 0 1 2 1 8 : 0 4 1 . 5 2 2 . 1 7 6 t a k e c m d . d l l

 

[Charles Dye]

If I use only one digit I get a result like this. If I copy this to notepad, there is a space between all characters.

[C:\Program Files\JPSoft\TCMD14x64]dir | findstr t
D a t e n t r õ g e r i n L a u f w e r k C i s t u n b e z e i c h n e t S e r i e n n u m m e r i s t 7 a a c : 4 e c d
V e r z e i c h n i s v o n C : \ P r o g r a m F i l e s \ J P S o f t \ T C M D 1 4 x 6 4 \ *
1 4 . 1 1 . 2 0 1 2 1 1 : 3 7 5 . 3 1 0 a l i a s . l s t
2 6 . 1 1 . 2 0 1 2 1 8 : 0 5 6 4 7 . 8 3 2 I t a l i a n . d l l
2 6 . 1 1 . 2 0 1 2 1 8 : 0 5 4 1 0 . 2 6 4 I t a l i a n D . d l l
2 9 . 0 6 . 2 0 1 2 2 1 : 5 2 9 . 4 6 9 l i c e n s e . t x t
2 9 . 0 6 . 2 0 1 2 2 1 : 5 2 7 . 1 3 1 r e a d m e . t x t
2 4 . 0 1 . 2 0 0 0 1 1 : 0 1 4 5 3 . 6 3 2 s t d v c l 4 0 . d l l
2 6 . 1 1 . 2 0 1 2 1 8 : 0 4 1 . 5 2 2 . 1 7 6 t a k e c m d . d l l

Aha -- you have UnicodeOutput turned on, and your utilities aren't expecting to see UTF-16. Try OPTION //UNICODEOUTPUT=NO and see if that doesn't make them happy.

 

[wolle]

Thanks for your great support:-) It works!

 

[Charles Dye]

If you type OPTION and select the first tab ("Startup"), you'll find an item called "Unicode Output" in the right-hand column. That sets the default value for that option; you probably want to turn it off. (On the rare occasion when you do want to write Unicode, you can turn it on temporarily with OPTION //UNICODEOUTPUT=YES, and then turn it off afterwards with OPTION //UNICODEOUTPUT=NO.)

 

[Rodolfo]

In my case I have the option set to Yes.

If I type

assoc | find /I "bat"

I get no result.

But, if I type

assoc |! find /I "bat"

I get the correct lines.

In my case, "which find" says "find is an external : F:\WINDOWS\system32\find.exe".
So, maybe the in-process piping is using only ansi? Is this correct or is it a bug?

Thank You and regards

Rodolfo Giovanninetti

 

[Charles Dye]

So, maybe the in-process piping is using only ansi? Is this correct or is it a bug?

It looks like the in-process pipe is also generating UTF-16, but in-process pipes get a BOM and real pipes don't. I don't know whether that's an actual bug, or whether Rex has some deep reason for doing it that way!

 

[rconn]

It looks like the in-process pipe is also generating UTF-16, but in-process pipes get a BOM and real pipes don't. I don't know whether that's an actual bug, or whether Rex has some deep reason for doing it that way!

WAD. As with 99% of the things that don't make a lot of sense, it's for compatibility with CMD.EXE (which doesn't add a BOM for unicode output).

In-process pipes are different for two reasons: (1) they're actually redirected files (>output & <input), so they need a BOM so the file handling code can interpret them, and (2) CMD doesn't support them, so compatibility is irrelevant.