プログラムの実行No.27536
Sa さん 10/01/30 07:30
 
メニュー右上の、その他、プログラムの実行に関してお願いが二つあります。
ver 7.11

------------------

例えばUTF8で書かれたperlのファイルを開き、
perl -wc <con >con とすると、処理内容がめちゃくちゃになります。
場合によってはコンパイルすら通りません。

エディタ内部はsjisで処理されてる(?)ようですが、開いてる形式通りの文字コード
でコマンドを実行するにはどうしたらいいでしょうか?
ちなみに、開いてる形式通りの文字内容が引数としてperlに送りつけられてると信じ
きっていたので、5時間ほどハマりました。

エディタ内部で扱っているsjisをそのまま出力しているとしたら、
指定されてる文字コードに変換して出力したほうが動作的に正しい気がします。
(と言うかもし強制sjis出力限定だとちょっと恐ろしくて秀丸でコマンド使えません)。


--------------------

perlが万が一ヌル文字を出力した場合、エディタ側で勝手に消滅させられます。
消滅させられると、解析もできなくなるので、消滅はさせずにおいてくれると助かり
ます。
ちなみに、これも以前それに気付かずかなりハマったことがあります。

[ ]
RE:27536 プログラムの実行No.27537
Iranoan さん 10/01/30 14:02
 
 Sa さん今日は、単なる一ユーザ Iranoan です。
> 例えばUTF8で書かれたperlのファイルを開き、
<snip>
> エディタ内部で扱っているsjisをそのまま出力しているとしたら、
> 指定されてる文字コードに変換して出力したほうが動作的に正しい気がします。
 確かに con でのやり取りは、Shift_JIS だと思います。
 Ver.8.00βには、「Unicodeで標準入出力」のオプションがあるので、おそ
らく出来るようになると思います。

 正式版の Ver.7.11 の場合、con ではなく %f を使ってはどうでしょう?
・ファイル全体を処理する事しかできない
・ファイル保存が必要
の欠点がありますが。

[ ]
RE:27537 プログラムの実行No.27539
Sa さん 10/01/30 16:20
 
> Ver.8.00βには、「Unicodeで標準入出力」のオプションが
情報ありがとうございます。
それに関しては、EUCも使いたいし、sjisも使いたいし、UTF8も使いたいです。
指定されてるバイトやビットの並びでそのまま入出力、ってのが一番素直で使いやす
いと思うんですが…、個人的には。

> 正式版の Ver.7.11 の場合、con ではなく %f を使ってはどうでしょう?
%fは、今知ったのですがとても便利そうですね。



秀丸開発者様には以下の要望を送りたいです。
データを壊す、消滅させる、改ざんさせる、の三つは1ビットたりともやめてほしい
です。

[ ]
RE:27539 プログラムの実行No.27549
秀丸担当 さん 10/02/01 11:40
 

>それに関しては、EUCも使いたいし、sjisも使いたいし、UTF8も使いたいです。
>指定されてるバイトやビットの並びでそのまま入出力、ってのが一番素直で使いやす
>いと思うんですが…、個人的には。

秀丸エディタの標準入出力のことでご迷惑をおかけして申し訳ありません。

プログラム実行 <con >con は、通常ではShift-JISとなるようになっています。

そうでないと、例えば sort <con >con としたとき、開いているエンコードの種
類によってソート結果が違うことになったらまずいと思います。
cmd /c dir >con としても、ファイルによってUTF-8と解釈してしまうと文字化け
してしまいます。
標準入出力は明示的に指定しない限りにShift-JISというのは、変えたらまずいの
ではないかと思います。
むしろ、そうでないと怖くて使えないものになってしまうと思います。

現在開発中のV8.00βにおいては「Unicodeで標準入出力」というオプションがあ
って、Unicodeでやりとりもできますが、こういったオプションとして明示的に指
定するのはありだと思います。
V8.00は正式版も近いことからやるかどうかわかりませんが、そういうオプション
ができたらいいということでネタとして参考にさせていただきます。


>> 正式版の Ver.7.11 の場合、con ではなく %f を使ってはどうでしょう?
>%fは、今知ったのですがとても便利そうですね。

Iranoanさんも書かれている通り、ファイルでやりとりすると情報がそのまま受け
渡しされるので、こちらの方法のほうがいいかもしれません。


>秀丸開発者様には以下の要望を送りたいです。
>データを壊す、消滅させる、改ざんさせる、の三つは1ビットたりともやめてほしい
>です。

エンコードの件は上記のようなことということにさせていただいて、あとはNULL
文字のことだと思いますが、確かにNULL文字が消えてしまうのはあまりよくない
と思います。

ファイルの読込みではNULL文字は空白に変換されています。
V8.00βにおいては[その他]→[動作環境]→[ファイル]→[エンコード2]に「NULL
文字の変換」というのが追加されていて、ファイルの読込み時にどう変換するか
が指定できるようになっています。
この設定と同じような変換が標準出力にもできるといいかもしれません。

この変換を適用したとしても、NULL文字はテキストの終端を表していているため、
完全に情報を保持してテキストを扱うのは難しいかもしれないです。
NULL文字を含んでコピーするとそこで終端とみなされて、貼り付けるとNULLのと
ころで切れるということが起きてしまい、これはWindowsの仕組み上避けられない
ということがあります。
秀丸エディタ間であれば独自形式を作って回避できる策もあるかもしれないです
が、他のアプリケーション間では避けられないと思います。

完全には難しいと思いますが、読込み時に保持できる設定と同じことを標準出力
にも適用できるように検討させていただきます。

こちらもファイルへの標準出力であれば問題無いと思います。

[ ]
RE:27549 プログラムの実行No.27563
Sa さん 10/02/01 19:17
 
大変申し訳ありませんが、返答を読みあまり真面目に返信したくなくなってしまいま
した。

こちらとしては、もうどうでもいいと思ってしまったので、要望とかは出さないこと
にしますが、
もし私から返信を聞きたいと言う胸があれば、明日にもう一度だけ来ますので、
私が考えている内容と、どう思っているか、その返信だけを書かせて頂きたいと思い
ます。

では。

[ ]
RE:27563 プログラムの実行No.27568
秀丸担当 さん 10/02/02 10:07
 

回答に何かご不満な点があったとしたら申し訳ありません。
ファイルのバイナリ状態のままできればいいですが、いろいろしがらみがあって
簡単ではなく、満足のいく状態ではないかもしれませんがご理解していただけた
らと思います。
まとめさせていただくと、以下のようなことになると思います。

・現状でUTF-8やNULL文字などファイルのバイナリ状態のままにするには、 <%f
や <input.txt >output.txt というようにするとできると思います。
・>con でNULL文字を保持できるようにするのは、V8.00の次のβ版で設定可能に
します。
・通常の設定のままで <con >con でShift-JISとなるのは仕様で、今後も変える
ことはできないです。
・将来バージョンにおいては、設定でShift-JIS/Unicode以外のエンコードも指定
できるようにする可能性もありますが、V8.00においては未定です。

あと、もう1つ対策があったので次のβ版で入れさせていただきます。
開いているファイルがShift-JISでない場合で、かつ<con >conの入力がある場合
に「プログラム実行」のダイアログ中にShift-JISに変換されるという警告文を表
示するようにさせていただきます。
こうしておくと間違うことが少なくなるかもしれません。

[ ]
RE:27568 プログラムの実行No.27585
Sa さん 10/02/03 01:29
 

長いです。返信いらないです。

>回答に何かご不満な点があったとしたら申し訳ありません。
いえ、対応ありがとうございます。

>ダイアログ中にShift-JISに変換されるという警告文を表示するようにさせていただ
>きます。
特にこうゆう対応は必要だと思います。

>標準入出力は明示的に指定しない限りにShift-JISというのは、変えたらまずいので
>はないかと思います。
秀丸を開いた再に文字コードと改行コードを指定しており、上部のタイトルバーにも
文字コードと改行コードが明記されています。
また、Ctlr+S では暗黙のうちにタイトルバー通りのコードで出力されます。
この状況で「明示的な指定がない限り」との返信は常識がないか独りよがりすぎるか
のどっちかじゃないでしょうかね。
ちなみにわざわざ書きませんでしたが、最初に5時間ほどハマった時、他にファイル
の復旧にも数時間かかっております。

なお、私としては文字コードを意図的に指定する手段として真っ先に思いつくのがテ
キストエディタです。
それをテキストエディタが放棄するのはちょっとひどいかな、とは思います。
なので、DOSなどのコマンドとエディタのコマンドを元々同列には考えておりません。
最初の要望もその考えに基づく物です。

>こうしておくと間違うことが少なくなるかもしれません。
ただし、間違ったのは私のほうではないと思います。


----------------------------------------------------------

なお、更新頻度の多い秀丸と見込んで書かせてもらいますが、
「テキストエディタについて」は以下のように考えております。
特に要望ではありませんし、相違があると思いますので聞き流して下さって構いませ
ん。
返信も必要ではありません。


「エディタの仕様決定の前提(憲法みないな物)」
1: 使用者の開発環境として最善であるべき。
2: 文字の処理や操作に関しては一つ残らず請け負うべき。


「エディタにとっての文字コード」
1: 出力時 (画面表示、ファイル出力、標準出力など) の表示のしかたとバイトの並
びかたのみに影響を与えるべき。

2: 文字コードの扱いの仕様を他のアプリやOSのせいにしたり依存すべきではない。
  (文字に関しては他のどのプログラムよりも利用者が意図した通りに、
  任意の文字コードで操作できるようにするべき)

3: 外部のアプリの仕様を勝手に決め付けるべきではない。
  (誰が何を作ってどこに何を送信をするのかは決め付けるべきではない。
  DOSみたいな使用範囲が限られたコンソールアプリと同列に考えられても困る)。
  入力時に関しては、検索文字などの自分自身が出力したGUIからの入力のみ決め付
けてかかっても良い。

4: 文字コードのわずらわしさを使用者に意識させないのではなく、前面に見えるよ
うにするべき。
  (実際には文字コードの存在を前面に押し出して扱うべき。
  タイトルバーにもデフォルトで文字と改行コードを表示させたほうが個人的には
好感がる。
  windowsが初期設定で拡張子を隠すのは意味がわからない。
  テキストエディタが文字コードの扱いを暗黙に決定するのは不可能であるし、ま
たするべきでもない)

5: 実際にエディタが内部で文字をどのように扱っているかは、一切ユーザーや外部
に悟らせるべきではない。
  外部に内部データを見せること前提で仕様を考えようとするから、
   >秀丸エディタ間であれば独自形式を作って回避できる策もあるかもしれないです
   >が、他のアプリケーション間では避けられないと思います。
  こうゆうよくわからない問題が起きる。しかもこっちに言われても困るしどうし
ょもない。

6: 入出力される全てのデータの並びに関して自己主張をするべきではない。
  (それはプログラマーが決めるし、そのためにテキストエディタを開いている)


「コマンドを実装してる限りは」
1: 入力内容、出力内容がどこのOSで動くかも分からないアプリ、もしくはデータと
考えるべき。

2: 文字列とバイナリが混ざり合ったデータ(もしくは文字列だらけのバイナリ)の入
出力があると考えるべき。
  いや、バイナリだけが返ってくる可能性もある。

3: 処理の仲介地点として使われることも考慮すべき。
  ( <con >con によりバイナリデータが返ってくる。→さらに<con >con で文字列
に変換されて返ってくる、など。
  こんなのは動作のtestでよくあること。なにしろテキストエディタは開発環境な
のだから。)
  テキスト限定のエディタなら考える必要はないが、プログラム用エディタならあ
って当たり前と考えるべき。
 
4: windows稼動のエディタだから秀丸から他OSに接続がないと決め付けるべきではな
い。
  tellnetでunixに繋がるかもしれない。
  もしちょっとでも「そんな使い方あるのか?」って思ったらテキストエディタと
開発環境なんたるかがわかってない。


「利用者にとっての文字コードとは」
1: sjis[あいうえお]をEUCにした場合、
  82A082A282A482A682A8 から A4A2A4A4A4A6A4A8A4AA へと変換されることを意味す
る。
  (特にプログラマーは文字を文字だと思っていない。バイトやビットの並びだと思
っている)。

2: 文字コードを扱いたくなったとき、もしくは意図した文字コードで操作したいとき、
  おそらくまずテキストエディタを開く。

「利用者にとってのテキストエディタとは」
1: バイト(ビット)の並びと文字列の優れた仲介役。
2: キーボードから字を書ける。(バイナリエディタでは不備が多い)
3: 増加した文字コード達をまとめて収拾してくれる。
4: 特定の意図したOSで動かすためのプログラムの開発環境。同じOSとは限らない。
  (開発環境としては違うOSだろうとその場でテストするのが最速なのでその場でや
ることも普通)



「最善の開発環境とは」
1: データを勝手に壊したり改ざんしない
2: 意図しないことを暗黙にやり始めたりしない
3: データの整理や扱いが容易。
4: 正しいデータの解析や扱いに関して手助けを行う。
5: 操作や作業手順は簡潔で円滑
  (ファイルに保存しなきゃダメ…とか使えない上、conが意図的なトラップ)



「その他」
1: windws付属アプリ同士でsjisでやりとり出来るのは必然。
  テキストエディタが強制的にsjisに変換してやり取りできたのは偶然。

2: EUCで操作が不可能な部分があるエディタってどうなんだろ。
3: 今の仕様のままで「プログラムの実行」を使うのは危険
4: 一度ファイルに保存するなら、優れたコマンドランチャーと言うのがあって
  「プログラムの実行」の存在があまり意味ない。

あと気付いたのは、ヘルプファイルにconでコンパイラに渡してexeに〜…との記述が
ありますが、詐欺じゃないですか。
Cですらコンパイルが通らなくなることがあると思います。
インタプリタなら、運悪く正しくパースされたら改ざんされたバイトコードのかたま
りがその場で実行されます。
まぁ、個人的には秀丸にsjis限定のポリシーがあって明記されるなら構わないと思い
ますけど、ちょっと仕様の貧弱さを感じます。

ああ、あとちなみに、私は(特に通信が発生する処理では)ファイル名ですらsjisと決
め付けてませんし、
入力出力に関しては全て疑ってかかってます。もちろん外部アプリの仕様もです。
そのかわりプログラム自体の文字コード(バイトの並び)に関しては絶対だと言う前提
で物を作ってます。
そしてそれをテキストエディタで作ってるんです。
その前提をを秀丸から覆してバグを発生させるって、どうなんでしょうね。

(※現時点での実装の困難さと、あるべき仕様は完全に別物だと思います。
  もし先の返答で不満があるなら、それを混同して当然のように責任を転嫁させた
書き方です。
  内輪ごとは内輪で片付けるのがいいと思います。こっちに言われてもどうにもな
りませんし、どうにも出来ません)


最後にもう一度。
上記までのことは要望とはしません。(つまり期待はしないでおきます)



[ ]