シェルスクリプト総合 その33
■ このスレッドは過去ログ倉庫に格納されています
シェルスクリプトに関する総合スレッドです。 全般 ・荒しは無視しましょう。 ・丁寧な姿勢を心掛けましょう。 ・ネチケット(死語)を意識しましょう。 ・「○○(他の言語)でいいやん」は禁止。他のスレに行ってください。 シェルスクリプト総合 その32 https://mevius.5ch.net/test/read.cgi/tech/1571929725/ >>662 たぶんPerlの呼出しコストにいちゃもん付けてる>>656 は >>654 とは別人。 あとheadやtailだと「バイト」単位では切出せない。 ところで head $(()) っていう技巧おもしろいね。初見だわ >>663 別人かもだけど、そういう気持ちは元コメから書いてあったから。。。 head/tailは、--bytesオプションがあるやろ? 算術式展開は、でもBash限定なんだっけ? ただ、いずれにしてもddにしろheadにしろtailにしろ、スキップが読み捨てなのか直シークなのかで速度が違いそう? >>661 ファイルの大きさを見て一番後ろを見に行くから遅いはずがない $ ls -1sh input.dat 10M input.dat $ dd if=input.dat of=output.dat bs=1M skip=1 count=1 $ ls -1sh output.dat 1.0M output.dat >>665 $(())は初見やったんちゃうの?w Bash限定のマイナー機能やったか!と思ったのに。。。 # Bashしか使わんから、互換性は意識してないからなー。 >>666 書いてることはちゃんと理解した? パイプ前のtailが、パイプ後のheadで捨てられるところも無駄に読み込んでまうやろ? おまけに、/dev/randomみたいなのからだと終わらないし。 >>667 読み始めの位置と読み出すサイズはブロック単位限定? 互いに素だとブロック単位を1にする? なんか遅そう? # 元コメ者よりもうるさくしてるな。。。 >>668 いや,実は算術演算の中身を書かない技巧があるのかと思ったんだわ。 そしたらどうやらそういう意図のコードじゃないらしいと後で分かって, 恥かしい勘違いだったんで黙ってたw >>670 素因数分解して,最適な読み出しサイズとブロック単位を決定するのおもしろそう。 すみません、 出来てもやるべきでないのは分かるんですけど、 日本語でシンボリックリンク張って日本語でコマンド呼び出しってできますっけ? $ エコー ヤッホー ヤッホー $ みたいな。 できると思うけどな 環境によりけりかな? 使ってる文字コードがシフトJISみたいなやつだとダメかも知れないが、それでも大丈夫なようには作れるからなんとも言えない そもそもLinux/UnixはShiftJISをサポートできない OSの設計的に不可能 ("無理やり"やってるのはあるが動作保証できない) >>676 逆にWindowsって,「無理やり」じゃなくShift-JISに対応できてたん? そっちの方が驚きなんだが。 俺には文脈不明の状態でエスケープ文字とバイト化文字の一部とを判別する OSネイティブな方法が思い付かないw >>677 Windows NTは最初のバージョン(1994年)から Unicode(UTF-16)対応だからね UTF-16は文字の一部にNULL文字が入るから 当時からC言語の標準ライブラリでは扱えないことがわかっていた マルチバイト文字は最初から対策済みなわけよ >>676 設計のどこにダメな要素が? シェルにはあるだろうが、カーネルにあるか? 「¥0」「/」が混じるとさすがに困るだろうが、それ以外ならどうにかできるやろ。 >>679 Linux/UnixはC言語で作られてる C言語の仕様に引っ張られてる >>678 同時に、OEM文字コードとしてシフトJISを採用したのだから、できない理由になってない。 ちなみに、UTF-16を採用したのは、当時は全多言語がUCS-2を前提にしてたからやろ。 振り返ると微妙な選択だったが、当時の外人にはわからんかったのはしゃあない。 >>681 Windowsは初期バージョンから多言語対応として作られてるという話 普通にShift-JISなUNIXとかあったし。 UNIXの多くのシステムコールでは、char*型引数は単なるバイト列で、別に\とかが意見を持ったりしない(ただしファイル名の/を除く。他に例外があるかは知らない。)。 Shift-JISでは2バイト目に/もnulも来ないから普通は問題ない。 ユーザーランドは何とでもなる。 今時のlinuxなら # localedef -f SHIFT_JIS -i ja_JP ja_JP.SJIS $ export LANG=ja_JP.sjis で動く。 ja_JP.utf8とja_JP.eucJPどっちでも動くなら、localeに対応しているから、多分sjisでも動く。 普通にシェルとかも問題ない。 >>680 じゃあ、C言語のどこにシフトJISを拒絶する要素が? C言語が文字コードに求めてるのは終端が「¥0」であることだけだろ。 シフトJISもその条件に反しないが。 なお、エスケープが面倒というのは、できない理由にはならないので、念のため。 >>683 いやいや、そこまで問題なくはないやろ。w たとえば、「ソ」「表」がパスに含まれたら、シェルそのままだと文字化けしたりするのでは。 localeはそこまで面倒見なさそう。 $ echo $BASH_VERSION 5.0.17(1)-release $ echo $LANG ja_JP.UTF-8 $ touch "$(echo ソ表.txt| nkf -s)" $ export LANG=ja_JP.sjis $ ls -1 *.txt 'ソ表.txt' $ ls -1 *.txt | od -tx1a 0000000 83 5c 95 5c 2e 74 78 74 0a etx \ nak \ . t x t nl >>684 どこがってソースコードにprintf("foo\tbar");って書いてあったら \tはタブになることぐらい知ってるやろ? >>687 もう一回書いてあげるで? エスケープが面倒というのは、できない理由にはならないので、念のため。 >>686 それは、lsとターミナルががんばったおかげじゃない?w ダメなケースがあるんじゃないかと思うんだけど、みんなに期待してええんかな? あ、シフトJIS対応についてのオレの認識は、カーネルには関係ないだろうしシェルは不可能ではないが茨の道やろなあ、くらい。 行末に、ダメ文字があれば、 \ で、改行がエスケープされるとか? やれやれだなw 例えば文字を一文字ずつ見ていって _をスペースに置き換える処理は 漢字を壊すんだよ bashでダメ文字列を試したら、 a)問題なし コマンドラインでの入力編集、ヒストリー、コマンドに渡る引数、外部コマンド呼び出し、カレントディレクトリの扱い、行末の\及びダメ文字の扱い、変数の代入と使用、変数のlengthとsubstring、コマンド置換、リダイレクトのファイル名、echo及びprintf、シェル関数名 など大部分 b)一部問題あり PS1の\wが文字化け($PWDを使うと化けない) c)問題あり ・globで、5cを含むマルチバイト文字が2文字とカウントされる(「ソ」が?ではなく??で選ばれる。他のASCIIと被る文字は問題ない。) ・変数の置換 abc=オソソソソソソソとして、 ${abc//オ/ロ}は動くけど${abc//ソ/ロ}は駄目 一方で${abc//オ/ソ}は問題ない たしか置換前の方がglob扱いだったから、これは上のglobを直せば同時に直るかもしれない ・alias名 ちょっとした修正で全く問題なくなりそう × ちょっとした修正で全く問題なくなりそう ○ 多数のソフトを修正しなければならないから大問題 SJISの問題は _ の話だけじゃないよ ASCII文字のほぼ半分。制御文字と数字と一部の記号除いた アルファベット文字に関する処理すべてが漢字の文字に影響する 例えばAを検索すると一部の漢字にマッチするし Aを置換すると一部の漢字を壊す cat sjis.txt | tr [a-z] [A-Z] > sjis2.txt ナニヌネノ -> オカガキギ に化ける 地震で津波が発生 -> 誰尻で津濡が発生 に化ける > 誰尻で津濡が発生 俺のフィンガーテクを受けたやつはみんなこうなる というか「WindowsのShift-JISへの対策・対応状況」と 「Linux (Unix) のShift-JISへの対策・対応状況」とでさして違いがない。 「LinuxでShift-JISに対応しようとすると多数のソフトの修正が必要」というのであれば 同じ問題がWindowsでも起きてる。 実際ダメ文字っていう概念はLinuxに限った概念じゃないからね。 むしろWindowsでShift-JISに対応しておらずダメ文字が問題になった例の方が、 人口比的なものもあるだろうけど、より有名じゃない? >>695 それはOSの問題ではない。 そんな処理をしたユーザーが問題。 たとえば、英字の大文字小文字変換としてコード値に0x20を加減したら、ASCIIならうまくいくが、UTF-8 ならうまくいかない。 現実のテキスト処理をするなら、文字コードの仕様にあわせることはあたりまえ。 シフトJISなら、バイトがマルチバイト文字の上位バイトか下位バイトかいずれでもないかは当然区別して処理しないと。 >>698 EUCは2バイト文字の右半分がASCII文字になることはない >>699 ぜんぜん違う Windows NTは内部文字コードをUTF-16で処理している カーネルとドライバは当然のことながら、Windows APIも ANSIバージョンであってもUTF-16に変換して処理している そりゃアプリは当然対応しなければいけないが OSそのものは最初から多言語対応になっている Linux/UnixはOS自体がC言語で作られ、内部文字コードは 1バイトのASCII文字互換であることを前提で作られてる 影響範囲が大きすぎる >>700 > そんな処理をしたユーザーが問題。 そんな処理がOSのあちこちに含まれてる 例えば起動時に実行するシェルスクリプトとかな >>700 > たとえば、英字の大文字小文字変換としてコード値に0x20を加減したら、ASCIIならうまくいくが、UTF-8 ならうまくいかない。 アホなの? UTF-8であっても「英字の大文字小文字変換」で「ASCIIの英字大文字」を渡したらうまくいく お前が言ってるのは「英字の大文字小文字変換」で「ASCIIの英字大文字以外(例えばASCIIの数字)」を 渡したらうまくいかないと言ってるのと同じことだぞ まとめ。 >>673 ファイル名に日本語を使っても? >>675 ええんちゃう? シフトJISはツラそうだがかんばればなんとか? >>676 「Linux/UnixはShiftJISをサポートできない」!!! 以降 「OS」の認識がゆるそうな>>676 に対する指摘。 シフトJISなLinux環境はあまり現代的じゃないし、わりとどうでもいいはずなんだけど。w >>703 アホなの? シフトJISに置き換えたらそのままだろうがよ! >>705 だからお前が持ち出した「英字の大文字小文字変換」という例は UTF-8でもSJISでも共に「英字の大文字」にしか対応しておらず 「英字の大文字以外」の動作は "未定義" のコードだろ 未定義なんだからうまくいかなくても想定通りの動作だ 俺が出した tr [a-z] [A-Z] というコードは 「英字の小文字を大文字に変換し"それ以外はそのまま"」というコードなんだよ UTF-8の文字列を渡した場合は、正しく動くが SJISの文字列を渡した場合は、正しく動かないんだよ SJISのために余計な処理が必要になる Linux/UnixでSJISに対応しようとしたら このような余計な処理がたくさん必要になるという話をしてる >>705 言い返したかったら 英字の大文字小文字変換としてコード値に0x20を加減するコード かつ、それ以外の文字は変換しないコードにしてみ? そしたらそれは、UTF-8なら正しく動作し、 SJISだと漢字を壊すコードになるから (SJISのための処理を追加しない限り) >>706 話が通じてないな。 そのへんは、UNIX/Linuxの問題ではない。 もう相手にしない。 >>699 >>701 XPが出始めの頃、エクスプローラでShift-JISのダメ文字が問題となって、 それに対応するパッチもあったと記憶している。 >>706 言い返したかったら 英字の大文字小文字変換としてコード値に0x20を加減するコード かつ、それ以外の文字は変換しないコードにしてみ? これすらできないもんなお前はw >>709 俺は記憶していない もしそんなのがあればWindows 2000でも問題になってるはずだが? >>709 そうそう。 それが修正されたことが「OSとしてのShift-JIS対応」だと言うんなら, Linuxでも「OSとしてのShift-JIS対応」はされてる。 C言語であろうが何であろうが,ダメ文字に対処することは可能だからね。 >>712 OSに関する点すべてを修正することが「OSとしてのSJIS対応」 局所的に一箇所だけ修正して、それ以外は修正されてないなら それは「OSとしてのSJIS対応」ではない 完全対応かどうかって話をしてる なんかもうあほらしくて議論する気がなくなってきたけど WindowsのShift-JIS対応が「完全」なら, どうしてWindows上でダメ文字対応する必要が(今だに)あるんですかね? あ、「それはWindows上のwin32 APIで用意されているShift-JIS対応の機能を使ってないからだ!」 っていう反論はなしね。 それってあなたが「LinuxはOSとしてはヾhift-JIS対応していない」ことの理由に挙げている 「Linux上のglibcやlibiconvで用意されているShift-JIS対応の機能を使えば」っていう文脈と同じだもの。 そろそろOSのスレに行ったら? シェルスクリプト関連からなんてOSの内部なんて知らん、せいぜいAPIがOSな感じ WindowsだってShift-JISとUnicodeとふた系統のAPIが用意され、Shift-JISのAPIを使ってたら=使われていた使われている同じ=シェルスクリプトのスレで違いを論じあってるのがおかしい >>714 アプリケーションコードレベルでなんかやってたらかな。まあやるだろうけど OSの内部でUnicodeだからアプリケーションもUnicodeでというのは、まあやらんな、Shift-JIS APIを使ってるようなのは シェルスクリプトで使うコマンドやシェルも同じことだな >>714 > どうしてWindows上でダメ文字対応する必要が(今だに)あるんですかね? 自分で「Windows上」って言ってるから、お前 OSの対応とOS上の対応は違うってわかっててわざと言ってるんだろ? そいうあからさまな釣りにレスする価値ないね でなおしてきな Shift-JISなんてLinuxなどでも今頃使わない廃れたコードに拘ってるのがおかしい 未だになんか(ちょっと)拘ってるOSがあるようだけど どうせなら、Unicode(UTF-8)でのLinuxなどの問題を言えよw Shift-JISなんて誰も使わないのを論じるより益があるだろう、発端のも別にShift-JISと言っているわけではないようだし >>718 今はOSが対応してるかの話をしてるだけ Windowsは内部コードがUTF-16でSJIS等はUTF-16に変換して処理される WindowsのAPIのうち、ANSI対応のAPIがSJIS等に対応しているAPIで このAPIの存在がまさにWindowsがSJIS等の対応しているという証明になってる そしてOSに付属しているコマンドもしっかりSJIS等に対応してある しかしLinux/UnixにはそういうったAPI(システムコール)が存在しない だからOSではない部分で独自に対応しないといけない上に、 付属のコマンドは多くががSJISに対応していない >>719 Windows APIを使ったのを書いたことがないとしか思えない Windows API には Shift-JISバージョンとUnicodeバージョンがある、Shift-JISバージョンを使っていたら内部でどうであれ同じ問題は起こり得る 同じように、Shift-JISに対応したLinuxなどではAPIで問題が起こることはないだろう、ロケールでShift-JIS設定できて問題ないんだろう実際に 何を論じてる、その違いでどう問題が起こると言っているのかさっぱりだな。てか、そんな問題は今時起こらない(UTF-8にしてるのが当たり前な)のでそんなの言っても意味ねえとしか思えんけど > Windows API には Shift-JISバージョンとUnicodeバージョンがある、 Shift-JISバージョンなどというものはない。 あるのはANSIバージョンだ。 そういう基本から、お前は理解していない。 > 同じように、Shift-JISに対応したLinuxなどでは 存在しない Shift-JIS 対応 Linux でぐぐればでてくるだろ? Linux の Shift JIS サポート http://www.ossforum.jp/jossfiles/Linux_SJIS_Support.pdf > なぜ Linux で Shift JIS ロケールがサポートされない > 現在、日本で利用されている多くの Linux ディストリビューションでも、Unicode 系の UTF-8 がデ > フォルトとされ、Shift JIS ロケールが用意されているケースでも、利用は推奨されていない。ちなみ > に、ユーザーのロケール設定は、Linux ターミナル画面で locale コマンドを打てば LANG= > ja_JP.UTF8 のように表示されるので確認できる。 > Shift JIS 系ロケール(sjis、cp932、ibm943 など、Appendix 1 参照)は、次のような理由のために推 > 奨されていない; > 1. Linuxの文字処理ライブラリ関数は、Unicode を扱うことを基本としているため、本ライブラリ > 関数を使ってインプリメントされた Linux システムコマンドでは、ファイルデータの中の文字 > 処理や、ファイル名の処理で、Unicode は正しく扱えても、Shift JIS は扱えないことがある。 > 2. Shift JIS データの処理は、「特別」な扱いとなり、メールクライアント Thunderbird など、個々 > のミドルウェアに多大な開発負担を負わせている。 > 3. 特に、正統 Shift JIS ロケール sjis では、 0x5C=U+00A5 というマッピングのために、オープ > ン系プログラム(C言語、Java など)の動作が保証されない。cp932 などでは問題ない。 >>721 そのANSIとやらの内部でShift-JISに対応してんだがな=Shift-JISバージョン 純粋にANSIとUnicodeしかなかったら、Shift-JISを受け入れるAPIはなんなんだかな マジでちょっとWebでちょっと見ての知ったかかよ >>722 それが対応してんだな、対応してなかったら使えない漢字があることになるだろうに だったらShift-JISなんてロケールできねえわな マジ知ったかすぎ > そのANSIとやらの内部でShift-JISに対応してんだがな=Shift-JISバージョン だから最初から俺が、SJISはWindows NTの内部文字コードであるUTF-16に変換しているから WindowsはSJISに対応してると言ってるだろ。APIはOSの機能だ。 > だったらShift-JISなんてロケールできねえわな 今LinuxでSJISロケールに対応しているものは現存しない あったら教えてくれや 昔、実験的に作られて実用的じゃなかったから 今LinuxでSJISロケールが存在ししてない。証拠の一つ。 Windowsが今も標準でSJISに対応してるのとは対象的だな ん?もしかしてこいつ。ANSIバージョンのAPIで もしSJISだったら特殊な処理を行う。みたいな行き当たりばったりな コードが入ってると思ってんじゃねーか?w ANSIバージョンのAPIは単純に現在のコードページ(SJIS等)から UTF-16に変換(またははその逆)をしてるだけなんだが Windows NTは内部的には全部UTF-16で処理してるのだからSJIS特有の処理は行っていない OSの機能としてANSIバージョンは文字コードの変換機能が行われてるだけ 繰り返すが。OSの機能として。これがOSの機能。 何その最初のごまかしは。お前は、 >Shift-JISバージョンなどというものはない。 >あるのはANSIバージョンだ。 と言っているんだけど?ただの厳密な(?)名称のをか?残念ながら日本ではShift-JISを使うのが当たり前で、ある意味後でUnicodeがなので、歴然とShift-JISバージョンのAPIという認識されてる 書いたことないなら知らんだろうけど >昔、実験的に作られて実用的じゃなかったから >今LinuxでSJISロケールが存在ししてない。証拠の一つ。 何それww存在してないわけではなくデフォで入ってないとかじゃないの?てか、やっぱり何それ だったら「全く」Shift-JISに拘る根拠は皆無だな >>727 お前が認識してるだけだろw 世界中でANSIバージョンはSJISバージョンのAPIだと思ってるわけがないだろ ほんと世界が狭いなw > 何それww存在してないわけではなくデフォで入ってないとかじゃないの?てか、やっぱり何それ だから追加できるなら、その追加方法をいえって。 削除されて追加できんねーんだよ 俺の言葉の揚げ足を取るんじゃなくて お前が証拠を突きつければいいだけ できないんだよなw >>726 Shift-JIS バージョンの API と Unicode バージョンの API ふた系統あると「俺は」「最初から」言っているんだがな お前が Shift-JISバージョンなんてない ANSIがあるだけだ と言い出したんだろうが 何その妄想。酷すぎw そんなこと考えるとしたらお前の方だろうがw 無知を色々晒して偉そうにのたまうからそんなわけわからんこと言い出すんだよ > 削除されて追加できんねーんだよ 削除されてというか一部で実験的に作られた程度で 本流にマージされたことはない 訂正な >>728 何それww 残念だったな ググればすぐあるけど?頑張れよ >>729 > Shift-JIS バージョンの API と Unicode バージョンの API ふた系統あると「俺は」「最初から」言っているんだがな SJISバージョンのAPIというものはない。 なんど言えば理解するんだ? そしてANSIバージョン+SJISのコードページに対応して Windowsが出荷されてるんだから。 ほれみろ。WindowsはSJISに対応してるじゃねーか > ググればすぐあるけど?頑張れよ それ自分で見つけられなかったときの言い訳じゃんw 相手に探させようとするww そこの拘るだけしかないんだな。意味ないな、ガンバレ 今SJISの話をしてるのだからSJISに拘るのは当たり前 >>733 いや、ググったらすぐにあったけど? 俺はShift-JISなんて今時使わないだからな、Shift-JISなんて無くてもいいんだから なんで 意味なく無知なのに偉そうな お前に 親切に 教えてあげなきゃならないのよ >>735 いや、そこじゃないんだけどw てか、またそれだとイミフだぞ?お前はLinuxでロケールでShift-JISなんてできないってんだろ?だったら拘る理由がゼロだろうに 論理破綻してるぞ?まあ頑張れ。イミフすぎてもうわけわからんが頑張れ > いや、ググったらすぐにあったけど? じゃあググったキーワードを書いて 見つけたサイトじゃなくていいよ キーワードだけでいい それぐらいできるでしょ? 検索したキーワードなんだから LinuxでロケールでShift-JISなんてできないということに拘るだけですが? ゼロって何の話ですか? Windowsは出荷状態でSJISに対応しているが LinuxはShift-JISなんてできない →そうですね で終わる話だと思いますがね? なんでそれでだめなんですか? 拘るというのは、そうですねで終われない人の方でしょう 全く面倒臭いな ・linuxカーネルはバイト列で扱うから\0と/さえ区別できれば良く文字コードの概念は基本的にない ・SJISは\0と/の条件を満たすから使える ・GNU/Linuxのユーザーランドにはglibcのlocaleサポートがあり >683に書いてある通り # localedef -f SHIFT_JIS -i ja_JP ja_JP.SJIS $ export LANG=ja_JP.sjis でSJISも使える これだけのこと WindowsにはA系APIがあるからセーフという理屈なら、UNIX/Linuxではiconvでもnkfでもあるんだからセーフ。w A系APIが対応してるのは、ANSIではなく、OEM文字コードなんだけどな。 ・linuxカーネルは〜 ・カーネルとOSは別である 論破w >>741 多くのアプリがiconvやnkfを使ってない >>743 アプリじゃなくてOSの話だそうです。>>717 >>743 知らんがな。 未対応なものがあったとしても、カーネルにもOSにも関係ない。 カーネルやOSで"対応していない"から ソフト側で対応するしかなくなって 結果対応してるソフトが大幅に減ってる >>747 カーネルやOSは、文字コードを限定していない。 アプリはアプリなので、まったく別の話。 >>748 Linuxはそうだね。だからLinuxはSJIS等に対応していない。 WindowsはOSがAPIを提供している。 >>749 抽象度の高い数学は、現実の物理の計算に対応してないってことだな。w また、Windowsの多くのAPIは、DLLで提供されてるただの関数でしかない。 まあ、もうええ。 >>753 > また、Windowsの多くのAPIは、DLLで提供されてるただの関数でしかない。 それをいうなら、 Windowsの多くのAPIは、OSで提供されてるただの関数でしかない。 だろ? 今はOSが対応しているかどうかの話をしてるんだから もうなんでもありやな。 Windowsってスゲー!w いやある意味マジで凄い,とも言えるな。 Linuxだと集客力がなさすぎて,ある程度論理的思考ができる人間しか寄せ付けないけれど, Windowsには(謎の)集客性があるから,[検閲されました]。 > [検閲されました]。 これ面白いと思って書いてんの? >>758 >>683 ,685,686 で、終わってる話だな。都合が悪くなったら訂正できずに話を逸らして持論を喚いてるだけの 論理的なんてあるわけがない。異常な執着さだけだな 日本語の設定表記ってjaなのかJPなのか分からなくなるわ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる