Powershell'de GnuWin32 / sed beklenmedik davranış

Windows Komut Satırı / Powershell'de GnuWin32 araçlarını kullanıyorum .

Ne görüyorsun:

 11:15 enlil D:\Users\x> Get-ChildItem .gitconfig  | sed "s/ */ /g"


 D i r e c t o r y : D : \ U s e r s \ x


 M o d e L a s t W r i t e T i m e L e n g t h N a m e
 - - - - - - - - - - - - - - - - - - - - - - - - - - -
 - a - - - 6 / 2 3 / 2 0 1 4 4 : 1 1 P M 5 6 . g i t c o n f i g

Ne görmeyi umuyordum:

 11:15 enlil D:\Users\x> ls .gitconfig  | sed "s/ */ /g"


 Directory: D:\Users\x


 Mode LastWriteTime Length Name
 ---- ------------- ------ ----
 -a--- 6/23/2014 4:11 PM 56 .gitconfig

Amacım , PowerShell tarafından eklenen veri sütunları arasındaki fazlalık boşluklardan kurtulmak. Komik olan, bu bir bilgisayarda (Win8.1 ile) mükemmel çalışıyor, ancak Win7 ile diğer bilgisayarlarda çalışmıyor.

Ve daha basit örnekler için çalışır:

 11:49 enlil D:\Users\x> echo "t  a t" |  sed "s/ */ /g"
 t a t

Herhangi bir yardım çok takdir edilecektir.

FYI - Get-ChildItems'in normal çıktısı şöyle görünür:

 11:22 enlil D:\Users\x> ls .gitconfig


    Directory: D:\Users\x


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
-a---         6/23/2014   4:11 PM         56 .gitconfig

— mnmnc
kaynak

Neden sadece her şeyi powershell kullanmıyorsunuz? Nihai amaç nedir?

— EBGreen

Nihai hedef, cutve trve gibi gnuWin32 araçlarını kullanabilmektir sort. Bu benim tercih edilen yöntemim, çünkü Powershell sözdizimini gerçekten sevmiyorum Command | Select this and that | Format-table. Ayrıca powershell'de borudan geçen birçok şey bashta akarsu olan nesnelerdir - benim için manipülasyonu çok kolaydır.

— mnmnc

Bu ortamda bir kodlama sorunu olacak. Bunu engellemenin bir yolu, çıktıyı hangi kodlamanın işe yaradığını gösteren bir dosyaya koymak için Out-File kullanmak ve daha sonra dosyayı sed'e kadar okumak olacaktır.

— EBGreen

Bu Unicode. Sed'den çıkan şeyler, PowerShell'in Unicode ve ASCII arasında ayrım yapmak için kullandığı 2 baytlık ön eki olmayan Unicode'dur. Böylece, PowerShell bunun ASCII olduğunu düşünüyor ve boşluk olarak görüntülenen \ 0 baytı (2 baytlık Unicode karakterlerden gelen üst bayt) bırakır. PowerShell dahili olarak Unicode ile ilgilendiğinden, aslında her bir baytı 2 baytlık bir Unicode karakterine genişletir. PowerShell'i Unicode'u kabul etmeye zorlamanın yolu yoktur. Çevresindeki olası yollar şunlardır:

Unicode SED'e girdi olarak geliyor mu? Düşük bir ihtimal ama sanırım mümkün. Şunu kontrol et.

SED'in çıktısını Unicode göstergeli \ uFEFF ile başlatınız. Muhtemelen SED kaynak kodunda kaçırılan şey:

_setmode(_fileno(stdout), _O_WTEXT); // probably present and makes it send Unicode
wprintf(L"\uFEFF"); // probably missing

Kodu SED komutunun içine,

sed "1s/^/\xFF\xFE/;..." # won't work if SED produces Unicode but would work it SED passes Unicode through from its input
sed "1s/^/\uFEFF/;..." # use if SED produces Unicode itself, hopefully SED supports \u

Sed dosyasının bir dosyaya yazıp Get-Content -Encoding Unicode ile okuyun. Dosyaya geçişin, cmd.exe içindeki komutta yapılması gerektiğine dikkat edin:
```
cmd /c "sed ... >file"
```
Dosyanın> PowerShell'de ele alınmasına izin verirseniz, aynı şekilde karışıklığa yol açar.
Sonuç metindeki \ 0 karakterleri PowerShell'e bırakın. Bu, 0xA veya 0xD kodunu içeren Unicode baytlarını oluşturan uluslararası karakterlerle iyi çalışmaz - bunun yerine satır bölmeleriyle bitirdiniz.

— Sergey Babkin
kaynak

Harika, zamanın ve analizin için çok teşekkür ederim. Şu an benim için çok daha net.

— mnmnc