route127の日記： 田←Winキー 6
cmd.exeスレが面白かった。
ランチャに特殊用途(strawberry perl用とか)のcmd.exeを何個か登録していたりもするが、素のcmd.exeや管理者権限が必要な時にWinキー+Rでcmd呼び出すことも多い。
以前からWinキー絡みのショートカットキーをメモする時に「田+R」と手書きしていたが、今回
という表現を目にしてかつてのWinロゴのなんかなびいてる感じは旗の表現だったのか？と気になった。
90年代からロゴとして見続けていてあまり意味合いを考えてみたことがなかった。
そうすると最近のロゴで田により近くなったにも何か意味が？
𪉀の字をWindowsマシン5台を操作する鳥としてリバイバルさせようというのか。（陰謀）
PowerShellは普段遣いはしないが単体でCOMオブジェクト扱えたりWMIオブジェクトが扱えるところには魅力を感じる。
ただ打鍵数が増えるし普段のcmd.exeでの作業を置き換えるメリットまではないと感じていたがPowershellによるファイル連結の例が示されていたのにはちょっと興奮した。
実際テキストファイルで試したらcopyで連結するより1バイト小さくなった。
Get-Content .\001.txt,.\002.txt | Set-Content .\004.txt
2番目のファイル終端の改行を削ってるのか？
ちょうど最近ソシムのWindowsコマンド環境のすべてを読んでいた。
cmd.exeとPowerShellとlinuxでの操作が対照されているのが面白そうで手に取ったが読み進むうちに三者を対応付けることの難しさみたいなものを感じだした。
（その辺をツッコミながら読む楽しみというのもあるのかもしれない）
そこでもcmd上のcopyの特色としてファイルの連結を挙げていたが先のGet-ContentとSet-Contentの組み合わせの例の様にPSのCopy-Itemに拘らなければ書きようはあるもんなんだな。
linuxだとcatの仕事だけれどもこの本だとlessコマンドの代替としてちょっと顔を出す程度であまり出番はなかった。
ページャのlessやmoreとcatを並べて紹介するのも違和感はある。
ただこの辺のファイル表示もデバイスファイルへの出力と捉えれば大きな意味でのファイル操作なのか？
システムコールレベルで見たらまた違うんだろうか？よく分からん。
ファイル比較の項ではcmd上のfcやlinux上のdiffに対応するPS上の表現として
Compare-Object (Get-Content file1) (Get-Content file2)
と書き下したりなんかはしていた。
その時はなんかzshのプロセス置換みたいな書き方だなと思ったくらいだったが、そこから類推してファイル連結まで思い至らなかった。
パイプがテキストじゃなくてオブジェクトというのも理解が怪しい。
wingetがsortを通すと文字化けするのはcmd.exe上単機能フィルタであるsortとPS上のエイリアスのsortが錯綜してるがオブジェクト云々の話というより文字コードの話に思えた。
実際コードページをchcpで932から65001に変更するとsortを通した出力の文字化けが大幅に改善される。
これはsort.exeが出力字の文字コードをchcpに応じて変えてそうな挙動に思える。
実際に
winget | perl -pne ""
だと化けるが、
winget | perl -MEncode -ne "print encode('cp932', decode('utf8',$_))"
とすれば化けない。
ソシムの本は結構面白かったのだが一つ驚いたコマンドとしてbitsadminがあった。
PSのInvoke-WebRequestやlinuxのwgetが対応すると示されていたが、windowsにもcurlが標準装備されている時代に果たしてわざわざ使う必要があるのか。
名前からしてなんかもっと別の用途の為に生まれてきたのではないかという感じがする。
特にNT3.5の (スコア:1)
NT3.5（3.51からだっけ？）のOpenGLのスクリーンセーバーはどう見ても旗でした。
否、それ以前にWindows3.0のロゴマーク、左側の点々とフェードした表現を含め、私には窓には見えず、旗に見えました。
＃アメリカ人には窓に見えるのかな
＃今叩いているFKB8724(買いだめした)も旗の絵が描かれているし
Re: (スコア:0)
検索したら旗のようにたなびいているのはWindow(窓)とWind(風)をかけたものだという説を見かけたが、真偽不明。
＞2番目のファイル終端の改行を削ってるのか？ (スコア:0)
これで思い出したけど、テキストファイルがBOM付きUTF8の場合、
cat で連結ってどうしたもんなんだろ。
BOMって構造のないテキストファイルに構造を持ち込んでいる
ような気もするが、同じ不可視文字の改行コードと同じでは？とも。
同様に sort とか diff とか その他各種テキストツールは
BOMに対してどうふるまうべきなんだろ？
悩みは尽きまじ
Re:＞2番目のファイル終端の改行を削ってるのか？ (スコア:1)
そもそもBOMはUTF-16でエンディアンを識別するための記号だから、
UTF-8にBOMが付いてること自体がイレギュラー
ってのはさておき、タイトルな本題
> テキストファイルで試したらcopyで連結するより1バイト小さくなった
これは、元ファイルのファイルサイズ加算と比べて
「PowerShellが1バイト小さい」ではなく「cmdのcopyが1バイト大きい」ってことはないですかね?
cmd.exeで
copy 001.txt+002.txt 004.txt
とした場合、それぞれテキストとして処理するので、最後に「EOF(1A)」が付加されると思います。(あとは今時少ないでしょうけど、入力ファイルの途中にEOFがあったらそこで読み込み終了、って動作も)
copy /b 001.txt+002.txt 004.txt
ならバイナリ処理なのでEOFで読み込み中断しないし、出力にEOF付与しないので、
ファイルサイズは一致
Re:＞2番目のファイル終端の改行を削ってるのか？ (スコア:1)
＞「PowerShellが1バイト小さい」ではなく「cmdのcopyが1バイト大きい」ってことはないですかね?
＞最後に「EOF(1A)」が付加されると思います。
全くその通りでした。
元となる001.txt,002.txtの作成
PSによる連結003.txt、copyによる連結004.txt、copy /bによる連結004b.txtの作成
連結されたファイル3種についてバイト列比較
Re: (スコア:0)
BOMはそもそもつけないほうがいいというのは置いておくと、
BOMは改行しないゼロ幅空白文字扱いですよ。(この用途では別の文字があるのでBOMを使うのは推奨されないけど)
とくに対処しなくても、見た目的にはほとんど問題が出ないはず。
sortやdiffがどうすべきなのかはわからないけど、空白を無視するオプションをつけたら無視してほしいですね。