アカウント名:
パスワード:
次はデフォルトの文字コードに手を付けてくれたまへ
Windowsの文字コードって複数あるの?
メモ帳のだぞデフォルトだとANSIになってる他にUnicode、Unicode big endian、UTF-8が使える
最近はHTMLやソースコード関連がUTF-8推奨なのでデフォルトをUTF-8に変えても良さそう
BOM困るよね。スクリプトとか設定ファイルとかメモ帳で弄っちゃって、BOMのせいで動作しないってケースが希にある。
改行コードが CRLF になっているくらいで command not found とか言うシェルのうんこっぷりを直す方が良い気がする。頑なにCRを無視するようにしないのは、したらいけない理由がなんかあるんだろうか
シェルスクリプトってものが分かってない奴が好き勝手に書いてるな。あれは人間から見たらテキストファイルだけど、カーネルから見たらプログラム(実行ファイル)だぞ。Windowsで言えばexeファイルの先頭が「0x5A4D」以外でも動作しろって言ってるレベルで酷い。
OSは#!で始まるファイルが起動されたら、それが参照するバイナリをロードするって厳然とした規格なので1行目だけは「柔軟な対応」は出来ないし、やってはいけない。2行目以降なら起動されたプログラム側(/bin/shや/usr/bin/perlなど)が好きに処理できるが。
https://ja.wikipedia.org/wiki/%E3%82%B7%E3%83%90%E3%83%B3_(Unix) [wikipedia.org]
シェルスクリプトってものが分かってない奴が好き勝手に書いてるな。あれは人間から見たらテキストファイルだけど、カーネルから見たらプログラム(実行ファイル)だぞ。
だから何なの?"#!" の前に Unicode の BOM を認めらばよいだけ。#! (BOM無し)0xEF 0xBB 0xBF #! (UTF-8)0xFE 0xFF #! (UTF-16 BE)0xFF 0xFE #! (UTF-16 LE)0x00 0x00 0xFE 0xFF #! (UTF-32 BE)0xFF 0xFE 0x00 0x00 #! (UTF-32 LE)上記の6通りを実行できるようにカーネルを書き換えれば良いだけ。何故やってはいけないの?セキュリテ
プロセス起動に分岐なんて入れたら全プロセスが単純に6倍遅くなるぞ。バカじゃねーの?
ぜひパッチを作ってLinux Kernelへ貢献してください。
カーネル書き換えの是非は置いておくとして。
全プロセスと言いますがもしファイルから起動しないプロセスでも遅くなるというのなら致命的なので設計を見直すべきですね。
また6倍遅くなるという表現からif文の羅列みたいなものを想定されていると思うのですがもしそういう実装であるというのならif文の羅列の末尾に追加する分には現行より6倍遅くなることはありえません。
繰り返しますがBOMに対応すべきとは言いません。
そこのリンク先のWikipediaの記事に書いてあるように、#!の解釈は結構OSによってブレがあります。なので、LFの手前のCRを切り捨てたり、EF BB BF # !の5バイトもshebangとして認識するシステムが将来登場しても別におかしなことではないと思います。
OSは#!で始まるファイルが起動されたら、それが参照するバイナリをロードするって厳然とした規格なので1行目だけは「柔軟な対応」は出来ないし、やってはいけない。
そのWikipediaの記事内からリンクが貼られている The #! m [in-ulm.de]
本気でそう思うならLKMLでLinusあたりに提案してみてくれ。本人も見てるから最大級の感謝の言葉を貰えるぞ。systemdやSELinuxを超える歴史のページになりそうだ。
こんなアホなこと言ってるレベルのやつに感謝の言葉なんて来るはずないだろ
将来登場する可能性は否定しないが、現在逸脱したシステムが存在しないってことは、それは「変えてはいけない部分」でしょう。っていうか2バイトを5バイトに変更って簡単な話じゃないぞ・・・・・もう新種のOS作った方が早いかもしれない。
そのwikipediaに書いてあるように、シバンには仕様上の制限が問題になってるにも関わらず実装側のトリックで回避せざるを得ないほど「手を付けてはいけない部分」なんだよ。POSIXも全ての実装を網羅してるわけではないがUNIXの長年の歴史が作った不文律が相当存在する。
linusからの謝辞なら来るだろw
https://linux.srad.jp/story/18/01/23/078252/ [linux.srad.jp]
投機実行のペナルティが発生するから実際には6倍じゃ済まないけどな。いや、そもそも必要がない処理を作ってはいけないんだが。
VC++しか使ったことがない奴がカーネル書いてる人に意見出せるか考えた方がいいよ。まるで秒単位の世界で話をしてるリニアに「10分しか変わらない」とか言って迂回ルートをねじ込むみたいな話だ。
たかだかBOMが入ってただけでスクリプトが動作しないような不便なOSだからシェアが取れないんだと思うよ
そうですね、 BOM 付の .bat ファイルがちゃんと動作しない Windows はとても不便な OS ですね :-p
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
いいぞ (スコア:0)
次はデフォルトの文字コードに手を付けてくれたまへ
Re: (スコア:0)
Windowsの文字コードって複数あるの?
Re: (スコア:0)
メモ帳のだぞ
デフォルトだとANSIになってる
他にUnicode、Unicode big endian、UTF-8が使える
最近はHTMLやソースコード関連がUTF-8推奨なので
デフォルトをUTF-8に変えても良さそう
Re: (スコア:5, すばらしい洞察)
Re:いいぞ (スコア:0)
BOM困るよね。
スクリプトとか設定ファイルとかメモ帳で弄っちゃって、BOMのせいで動作しないってケースが希にある。
Re: (スコア:0)
改行コードが CRLF になっているくらいで command not found とか言う
シェルのうんこっぷりを直す方が良い気がする。頑なにCRを無視するように
しないのは、したらいけない理由がなんかあるんだろうか
Re: (スコア:0)
シェルスクリプトってものが分かってない奴が好き勝手に書いてるな。
あれは人間から見たらテキストファイルだけど、カーネルから見たらプログラム(実行ファイル)だぞ。
Windowsで言えばexeファイルの先頭が「0x5A4D」以外でも動作しろって言ってるレベルで酷い。
OSは#!で始まるファイルが起動されたら、それが参照するバイナリをロードするって厳然とした規格なので
1行目だけは「柔軟な対応」は出来ないし、やってはいけない。
2行目以降なら起動されたプログラム側(/bin/shや/usr/bin/perlなど)が好きに処理できるが。
https://ja.wikipedia.org/wiki/%E3%82%B7%E3%83%90%E3%83%B3_(Unix) [wikipedia.org]
Re: (スコア:0)
シェルスクリプトってものが分かってない奴が好き勝手に書いてるな。
あれは人間から見たらテキストファイルだけど、カーネルから見たらプログラム(実行ファイル)だぞ。
だから何なの?
"#!" の前に Unicode の BOM を認めらばよいだけ。
#! (BOM無し)
0xEF 0xBB 0xBF #! (UTF-8)
0xFE 0xFF #! (UTF-16 BE)
0xFF 0xFE #! (UTF-16 LE)
0x00 0x00 0xFE 0xFF #! (UTF-32 BE)
0xFF 0xFE 0x00 0x00 #! (UTF-32 LE)
上記の6通りを実行できるようにカーネルを書き換えれば良いだけ。
何故やってはいけないの?
セキュリテ
Re: (スコア:0)
プロセス起動に分岐なんて入れたら全プロセスが単純に6倍遅くなるぞ。
バカじゃねーの?
Re: (スコア:0)
ぜひパッチを作ってLinux Kernelへ貢献してください。
Re: (スコア:0)
カーネル書き換えの是非は置いておくとして。
全プロセスと言いますが
もしファイルから起動しないプロセスでも遅くなるというのなら
致命的なので設計を見直すべきですね。
また6倍遅くなるという表現からif文の羅列みたいなものを想定されていると思うのですが
もしそういう実装であるというのなら
if文の羅列の末尾に追加する分には現行より6倍遅くなることはありえません。
繰り返しますがBOMに対応すべきとは言いません。
Re: (スコア:0)
そこのリンク先のWikipediaの記事に書いてあるように、#!の解釈は結構OSによってブレがあります。なので、LFの手前のCRを切り捨てたり、EF BB BF # !の5バイトもshebangとして認識するシステムが将来登場しても別におかしなことではないと思います。
OSは#!で始まるファイルが起動されたら、それが参照するバイナリをロードするって厳然とした規格なので1行目だけは「柔軟な対応」は出来ないし、やってはいけない。
そのWikipediaの記事内からリンクが貼られている The #! m [in-ulm.de]
Re: (スコア:0)
本気でそう思うならLKMLでLinusあたりに提案してみてくれ。
本人も見てるから最大級の感謝の言葉を貰えるぞ。
systemdやSELinuxを超える歴史のページになりそうだ。
Re: (スコア:0)
こんなアホなこと言ってるレベルのやつに感謝の言葉なんて来るはずないだろ
Re: (スコア:0)
将来登場する可能性は否定しないが、現在逸脱したシステムが存在しないってことは、それは「変えてはいけない部分」でしょう。
っていうか2バイトを5バイトに変更って簡単な話じゃないぞ・・・・・もう新種のOS作った方が早いかもしれない。
そのwikipediaに書いてあるように、シバンには仕様上の制限が問題になってるにも関わらず実装側のトリックで
回避せざるを得ないほど「手を付けてはいけない部分」なんだよ。
POSIXも全ての実装を網羅してるわけではないがUNIXの長年の歴史が作った不文律が相当存在する。
Re: (スコア:0)
linusからの謝辞なら来るだろw
https://linux.srad.jp/story/18/01/23/078252/ [linux.srad.jp]
Re: (スコア:0)
Re: (スコア:0)
投機実行のペナルティが発生するから実際には6倍じゃ済まないけどな。
いや、そもそも必要がない処理を作ってはいけないんだが。
VC++しか使ったことがない奴がカーネル書いてる人に意見出せるか考えた方がいいよ。
まるで秒単位の世界で話をしてるリニアに「10分しか変わらない」とか言って迂回ルートをねじ込むみたいな話だ。
Re: (スコア:0)
そうですね、 BOM 付の .bat ファイルがちゃんと動作しない Windows はとても不便な OS ですね :-p