シェルスクリプト総合その35

**デフォルトの名無しさん** · 2020/11/24(火) 21:37:20.06

シェルスクリプトに関する総合スレッドです。

全般
・荒しは無視しましょう。
・丁寧な姿勢を心掛けましょう。
・ネチケット（死語）を意識しましょう。
・「○○（他の言語）でいいやん」は禁止。他のスレに行ってください。

前スレ: シェルスクリプト総合その34
https://mevius.5ch.net/test/read.cgi/tech/1597990675/

**デフォルトの名無しさん** · 2021/02/13(土) 21:13:09.13

超高速なシェルって言ってもどこを高速化したいのか分からんね
他のスクリプト言語と違ってプロセス起動を平気でやる性質があるから
JIT実装したところで、ねえ……

**デフォルトの名無しさん** · 2021/02/13(土) 21:18:19.57

>>865
>本当に違うんだったら、すまんかった。本当に違うなら
くっワロタ

**デフォルトの名無しさん** · 2021/02/13(土) 21:48:07.63

>>866
だよな
だから誰も必要としてないから誰も作ろうともしない、
シェルスクリプトの長い歴史から見ても
変わった人(いい意味で)がやろうと出ても企画倒れかな

**デフォルトの名無しさん** · 2021/02/14(日) 01:27:13.76

デーモン起動とかにも使われるシェルスクリプトは、速さよりもちょっとでも軽いほうがええやろ。
JITなんかにメモリを使う余裕はないな。

**デフォルトの名無しさん** · 2021/02/14(日) 14:36:19.88

デーモンとかに使うのは素の/bin/shで、言う通り軽い方なのが採用されてるだろう
JIT云々はそういうのではないのだろう。今あるbashとかzshとかそういう方向の

**デフォルトの名無しさん** · 2021/02/14(日) 15:27:49.90

シェルスクリプトの高速化って結局、exprに対する$()みたいな、外部コマンドの組み込みコマンド化が原則になると思うけど、
それで行き着く先ってPerlでしかないよね

まあRob Pikeの言う通り計測しろって話ではあるので、ボトルネックが実際fork/waitじゃなければまったくの的外れだけど

**デフォルトの名無しさん** · 2021/02/14(日) 18:02:37.21

シェルで使えるってだけならRUSTが速そうだけど

**デフォルトの名無しさん** · 2021/02/14(日) 23:21:01.83

>>871
JavaScriptの言語仕様を見ればわかるけど
JavaScript自体ではファイルの読み書きはできないんだよ
つまりI/Oを伴う機能は言語仕様としては本質的に不要と言える

外部コマンドなんて殆どがI/Oなので、それらを組み込む必要はない
Perlは多数組み込んでるので良くない

JavaScriptと同じように、I/Oを必要としないものは
シェル組み込みとして、メモリ計算処理を高速化すればいい
例えばメモリだけでできる単純な値比較や計算だけでもシェルは遅い

**デフォルトの名無しさん** · 2021/02/14(日) 23:39:01.27

>>873
おまえ、いつものポジキチやろ？

**デフォルトの名無しさん** · 2021/02/14(日) 23:58:12.52

>>874
違うけど、お前はいつもの「ポジキチと争ってるやつ」ってことは確定かなｗ

**デフォルトの名無しさん** · 2021/02/15(月) 00:59:58.92

争ってるがどこまでを指しているのかわからんが、反論してるのは複数居るだろう
確定しても意味なさげw

**デフォルトの名無しさん** · 2021/02/15(月) 01:11:01.23

>>873
ブラウザというホスト環境にのせるために考えられた言語だからI/Oがないだけ
ホスト環境がI/OやEvent Loopを補完しないと動かないし役に立たない

そういう種類の言語の仕様にI/Oがないからといって
一般的なプログラミング言語仕様にI/Oが本質的に不要なわけない
I/O無しではどんなプログラムも役に立たないから

**デフォルトの名無しさん** · 2021/02/15(月) 01:12:58.43

JavaScriptは元々はブラウザ上で動くが発端だからな
勝手にどこぞからロードしてユーザの意思に関係なく勝手に動くプログラムだからな
ローカルファイルにアクセスなんて自由にできたらどうなるか火を見るより明らか
ていうのがあって、何言ってんだかなという>>874じゃないのかな。知らんけどw

**デフォルトの名無しさん** · 2021/02/15(月) 01:13:50.12

あ、なんか被ったw

**デフォルトの名無しさん** · 2021/02/16(火) 03:00:19.59

>>877
C言語にも、I/Oないよ

**デフォルトの名無しさん** · 2021/02/16(火) 03:21:55.67

>>880
だから、#includeだったりリンカオプションだったり、めんどくさい準備が必要なんだけどな。

**デフォルトの名無しさん** · 2021/02/16(火) 06:35:07.01

関係ないだろ

**デフォルトの名無しさん** · 2021/02/16(火) 10:30:49.70

>>880
嘘ついちゃだめ

**デフォルトの名無しさん** · 2021/02/16(火) 10:43:13.65

言語とライブラリの区別をつけたほうが良いと思うよ

**デフォルトの名無しさん** · 2021/02/16(火) 11:56:09.07

C言語を持ち出すのはアセンブリに無いと言っているようなもんだな
どういう意味かわかるかな？

**デフォルトの名無しさん** · 2021/02/16(火) 12:22:40.92

>>885
わからん。ｗ
自分でもわかってないやろ？

**デフォルトの名無しさん** · 2021/02/16(火) 13:03:01.94

アセンブリ言語に無いのは当たり前なのはわかるね？
でもアセンブリでもファイルI/Oはできるよね？
C言語はアセンブリに近しい言語だというのはわかる？
だったら「言語仕様」としては無いのは普通と言える
アセンブリでファイルI/Oはアセンブリで記述したライブラリ(サブルーチン)を用いるのと同じように

てか「言語仕様」としては無いが、原典である K&R C でもすでにファイルI/Oに関しては記述があるし、
それに則っての標準としてのライブラリが「必ず」あるだろうから、言語仕様としてないあれはライブラリというのは無理筋だな

プログラミング言語だからとどれも一緒の扱いにするのが間違いでもあるな

**デフォルトの名無しさん** · 2021/02/16(火) 13:06:51.96

>>887
>それに則っての標準としてのライブラリが「必ず」あるだろうから
ああ、無いのもあるか。有名なOSで
まあ、そういう独特なのも独特のファイルI/Oは必ずあるってことでw

**デフォルトの名無しさん** · 2021/02/16(火) 16:08:25.47

>>885
例えば8086のOUT命令はアセンブリにないことになってるの？

**デフォルトの名無しさん** · 2021/02/16(火) 16:14:30.97

>>887
ただの決めつけを根拠にしているから、理屈があやしいな。ｗ

まあ、おまえはまず「フリースタンディング環境」について調べろ。
IOはあるのが当然、ではない。

**デフォルトの名無しさん** · 2021/02/16(火) 16:32:25.56

>>889
OUT命令ってなんなのか知ってるのかっていう
対象はチップのポートだぞ

>>890
そのフリースタンディングでもフリースタンディングではI/Oは無いとは言ってないだろ
C言語の元といえば K&R C Program Language であり、それに標準ライブラリはあると書いてある
ないとこは標準ライブラリがない環境でCを持ってきてるある意味派生であるはずの標準ライブラリが無いだけだな

**デフォルトの名無しさん** · 2021/02/16(火) 16:47:09.77

初版とかどうなのかと思い探したらあった。いいないんたーねっつは

CHAPTER 7: INPUT AND OUTPUT

Input and output facilities are not part of the C language, so we have
de-emphasized them in our presentation thus far. Nonetheless, real pro-
grams do interact with their environment in much more complicated ways
than those we have shown before. In this chapter we will describe “the
standard I/O library,” a set of functions designed to provide a standard I/O
system for C programs. The functions are intended to present a convenient
programming interface, yet reflect only operations that can be provided on
most modern operating systems. The routines are efficient enough that
users should seldom feel the need to circumvent them “for efficiency”
regardless of how critical the application. Finally, the routines are meant to
be “portable,” in the sense that they will exist in compatible form on any
system where C exists, and that programs which confine their system
interactions to facilities provided by the standard library can be moved from
one system to another essentially without change.

We will not try to describe the entire I/O library here; we are more
interested in showing the essentials of writing C programs that interact with
their operating system environment.

**デフォルトの名無しさん** · 2021/02/16(火) 16:51:36.76

K&R The C Program Language が Cの原典ではないというなら話にならないからもう知らないw
フリースタンディング環境とやらののうちのどこぞの環境でファイルI/Oがないなんて、>>888と似たようなもんだろうとしか思えない

**デフォルトの名無しさん** · 2021/02/16(火) 16:59:57.69

>>891
>I/Oは無い
ファイルI/Oは無い
ね。一応訂正させていただきます

**デフォルトの名無しさん** · 2021/02/16(火) 20:04:17.80

なぜC言語の話が出るのか？
なぜアセンブリの話が出るのか？
と飛躍がありすぎて、なんの話なのか、まったくわからん。ｗ

>>893
K&Rなんか、今となっては怪しい歴史書やろ。ｗ
記紀とか聖書とかから現実を語ることはできまい。

**デフォルトの名無しさん** · 2021/02/16(火) 20:43:15.59

自分のそれ関連でレスしておいて何言ってんだか

**デフォルトの名無しさん** · 2021/02/16(火) 20:46:48.66

かと思ったら、以下も何言ってんだかだよ
冗談で逃げただけか？？
マジならお前がそう思うならそうなんだろな、お前の頭の中ではなんとかかんとかw
見損なったのぞお前w

**デフォルトの名無しさん** · 2021/02/16(火) 21:04:42.04

シェルスクリプトスレはいつ見ても
キチ vs キチのマウンティング合戦
サル山でもこうはならない

**デフォルトの名無しさん** · 2021/02/16(火) 21:26:41.96

シェルスクリプトではライブラリに相当するものは外部コマンド

**デフォルトの名無しさん** · 2021/02/17(水) 02:52:50.69

そうよ
だからそれをブラックボックスとして扱うんだ

**デフォルトの名無しさん** · 2021/02/17(水) 03:06:40.89

逆に全然枯れてないし俺環上等で本業のジョブ管理に役立つツールの話はもっとするべきだと思う
gnu parallelとかcoprocとか

**デフォルトの名無しさん** · 2021/02/17(水) 03:13:44.11

gnu parallel使うぐらいなら自力実装したほうが楽だと思うわ
coprocは知ってるけど使う理由が見当たらない

**デフォルトの名無しさん** · 2021/02/18(木) 09:30:54.83

シス管やデータサイエンティストとかのparallelヘビーユーザーではないんで効率は気にしてないけど、まあ変な文字の扱いが良くなったxargsとして便利だと思う
配るスクリプトならより普及してるxargsに置き換えた方が良いと思うけど
Perl実装だしいっそ同梱もありだと思うが

**デフォルトの名無しさん** · 2021/02/18(木) 09:35:31.03

ライセンス問題ないならね

**デフォルトの名無しさん** · 2021/02/18(木) 09:43:20.87

だから並列処理ぐらい自分で実装しろよｗ

**デフォルトの名無しさん** · 2021/02/18(木) 09:50:29.23

バイオ系のやつが使ってるけどddで割って割り当てると朝には落ち出るとか
情報出身じゃないのでなんか変な事してる可能性はあるが

**デフォルトの名無しさん** · 2021/02/18(木) 09:56:32.04

落ち出るのかソレは大変だな

**デフォルトの名無しさん** · 2021/02/18(木) 09:56:32.14

ローカルな並列処理はmakeでいいわ
途中で止めても簡単に再開できる

**デフォルトの名無しさん** · 2021/02/18(木) 10:15:23.24

>>905
ちゃんとスケジュールするの割と大変じゃね？
フォアグラウンドでジョブ走らせたから別端末からアタッチ、5秒毎にpsしてコアの稼働率グラフ作ったが、シヌソイドみたいに振動してる
局所性とのTradeオフがあるから単に分ければいい訳じゃない
一度アフィニティー設定したら終わりじゃなくて、スループット監視しながら、少なくともPID制御程度のロジックは書かなきゃならんだろ

**デフォルトの名無しさん** · 2021/02/18(木) 11:02:26.51

>>908
欲張ってパイプ繋げて失敗するのあるある
だからと言ってteeでディスクに中間結果流すとボトルネックになるし

でもバッファリングを乗っ取ってコマンド実行するstdbufを最近知って捗った
二段以上繋ぐと前後のバッファリングモードの影響をモロに受けてた、特にいつも両脇挟まれるteeが…
コマンドがputc連打してるのか、printfにちゃんと改行付けてるのか、と調べるよりオプション全部試した方が早いね

**デフォルトの名無しさん** · 2021/02/18(木) 11:04:00.77

make色々活用してる人居るよな
試してみる、ありがとう

**デフォルトの名無しさん** · 2021/02/21(日) 04:01:15.96

>>902
coproc cmdだけで対話的に様子見たり追加で入力送って修整したりできるのが便利じゃないかな
スクリプト向けじゃなくてインタラクティブ向け

**デフォルトの名無しさん** · 2021/02/21(日) 12:39:32.90

シェルスクリプトってPOSIX準拠っていうか/bin/shを使うと
/bin/shの実体がいろんなシェルの場合があるから互換性問題に悩まされるな

bashだけしかなければ互換性問題に悩まされることはないが
交換可能性がある（つまりbashと同等の別の実装）があると
互換性問題に悩まされて、いろんなシェルに対応しようとすると
保守や移植のコストが増大してしまうな

**デフォルトの名無しさん** · 2021/02/21(日) 13:50:25.30

いわゆるbashismはUbuntuが/bin/shをbashからdashに変えてシステムの数あるスクリプトが動かないがあるのに気づいたのが発端でしかない
dashに変えたのはただ軽いからという理由でしかないし、dashに対応もしくはシバンを適切にという対応が終わってしまってる
いろんなシェルに対応しようとするというニーズはきわめて限られてるか、ただの空想だろな

**デフォルトの名無しさん** · 2021/02/21(日) 23:37:24.17

POSIX準拠すれば可搬性があるって言うけどあれ嘘なんだよね
そもそもシェルが完全にPOSIXに準拠してるわけじゃなくて互換性がないから
/bin/shを使ったとしても強制的にbashを使わされる環境ある

もちろん互換性がまったくないとは言わないよ
でもPythonのバージョンが違っていて動かなくなったって話と同じぐらい
別のシェルで動かなくなったって話がでる

**デフォルトの名無しさん** · 2021/02/21(日) 23:47:08.70

bashはアプリと思ってわざわざインストールするものと
思えばいいんじゃ
高機能でメモリ食う
たまたまshとかぶってる

**デフォルトの名無しさん** · 2021/02/22(月) 00:00:35.75

>>915
可搬性はある
だが、Write once, run anywhere ってことは絶対ではない
もしかしたら問題が起こることもあるが、そんな場合でも修正はそうでないより少なくて済む
くらいなかな

**デフォルトの名無しさん** · 2021/02/22(月) 00:29:31.87

POSIX準拠はOKだけど、POSIXコマンド縛りはアホなんだよな
例えば普通にgawkを使えばいい

gawkが提供する機能はPOSIXのawkの機能を超えていて一部互換性はないけど
gawkのソースコード自体はPOSIX準拠なんだから
どのOSでもインストールすれば使うことが出来る。

POSIXコマンド縛りは言い換えれば、インストールしない縛りでしかなくて
便利なものをインストールしないなら、開発コストが上がりますよという話

いろんな環境に移植されてる便利なコマンド（bashとかgawkとかgsedとか）を
インストールしてOKという前提に立てば、それらを使ったほうが
移植性を犠牲にすること無く開発コストは下げられる

**デフォルトの名無しさん** · 2021/02/22(月) 00:33:24.80

あとPOSIXコマンド縛り（インストールなし縛り）にすれば20年後でも動くぜ
ただし開発コストが上がるから、弊社が作った独自コマンドをインストールしろよな！
っていうのは矛盾しまくりｗ

そんな独自コマンドをインストールするなら
各OSに広く移植されてるコマンドをインストールしたほうがいい
例えばrubyとかpythonとかな

**デフォルトの名無しさん** · 2021/02/22(月) 00:43:28.47

そう無闇に否定するのも無闇にPOSIX準拠を押し付けるのと変わりないな

**デフォルトの名無しさん** · 2021/02/22(月) 00:49:11.43

むやみに否定してるんじゃなくて
理由を言いながら否定してるから問題ないでしょ？

**デフォルトの名無しさん** · 2021/02/22(月) 00:50:52.03

否定したいだけというのを無闇にという

**デフォルトの名無しさん** · 2021/02/22(月) 00:53:08.85

https://dictionary.goo.ne.jp/word/%E7%84%A1%E9%97%87/

１結果や是非を考えないで、いちずに物事をすること。また、そのさま。「―な約束はしない方がよい」
２物事の状態が度を超えて甚だしいさま。ひどい。「―に金がかかる」

どちらにも当てはまらない

**デフォルトの名無しさん** · 2021/02/22(月) 00:55:37.40

結果や是非を考えないで、いちずに物事をすること
に当たるだろうwわかりやすくいうと非しか考えてないだな

**デフォルトの名無しさん** · 2021/02/22(月) 00:56:39.64

結果や是非を述べて否定してるだろ？

**デフォルトの名無しさん** · 2021/02/22(月) 00:58:09.47

是非があるのに非しか言ってないという自覚がないんじゃ話にならない
その読めなさは

**デフォルトの名無しさん** · 2021/02/22(月) 00:58:51.57

もう一回述べるか？

POSIXコマンド縛りをしないほうが
高い移植性に加えて開発コストの削減を実現できるのだから
POSIXコマンド縛りはアホ

**デフォルトの名無しさん** · 2021/02/22(月) 01:00:10.74

無闇だなww
話が通じないのはわかった

**デフォルトの名無しさん** · 2021/02/22(月) 01:00:15.42

>>926
是非を考えるっていうのは、
是と非の両方を言うって意味じゃないぞｗ

是と非の両方を「考える」という意味だ
考えた結果、POSIXコマンド縛りはアホというのが結論だ

**デフォルトの名無しさん** · 2021/02/22(月) 01:01:23.37

POSIX準拠には利点もあるし欠点もある
適時もしくは各々の好みで好きにしろってだけだな

**デフォルトの名無しさん** · 2021/02/22(月) 01:02:56.43

POSIX準拠じゃなくてPOSIXコマンド縛りなｗ
POSIX準拠だとgawkのソースコードもPOSIXに準拠してるだろ

じゃあお前がPOSIXコマンド縛りの是非を考えて
是となる部分を言えばいいじゃん
何も言ってないのはお前の方だぞ

**デフォルトの名無しさん** · 2021/02/22(月) 01:04:37.72

>>829
わかった？
わからんだろうけど。今だに是非を自分の都合の良い視点でしか理解できないみたいだからなあ
言いたいこと言ったのでおしまいおしまい

>>831
やっぱりわからんかったか。てかいつもの話題変えるのか
POSIX準拠の利点とそう変わらないだろうに。わからんのね

**デフォルトの名無しさん** · 2021/02/22(月) 01:06:46.96

いいから早くPOSIXコマンド縛りの
是の部分を言えよｗ

**デフォルトの名無しさん** · 2021/02/22(月) 01:07:15.01

918 名前：デフォルトの名無しさん[sage] 投稿日：2021/02/22(月) 00:29:31.87 ID:Vv8+u1qd [1/9]
POSIX準拠はOKだけど、POSIXコマンド縛りはアホなんだよな
例えば普通にgawkを使えばいい

**デフォルトの名無しさん** · 2021/02/22(月) 01:08:23.33

>POSIX準拠の利点とそう変わらない
これがわからないんだったら語る資格はない
俺はあんたのママではないぞ
もう全て語ってるからあとはあんた次第、頑張れ

**デフォルトの名無しさん** · 2021/02/22(月) 01:13:01.92

「POSIXコマンド縛りの是の部分を言え」

という言葉の意味がわかりませんか？

**デフォルトの名無しさん** · 2021/02/22(月) 01:23:33.23

POSIXにはPOSIX socketやPOSIX スレッドなど多くのAPIを含んでいるが
POSIXコマンドはPOSIX全体のごく一部しか利用しておらず
POSIXコマンド縛り＝POSIXの一部しか使えない制限という意味でもある

POSIX（C言語中心のOSとのインターフェース）は必要だから作っれたけだが
POSIXの一部しか使えないPOSIXは、必要なものが使えないということを意味する

**デフォルトの名無しさん** · 2021/02/22(月) 01:25:24.66

訂正

POSIX（C言語中心のOSとのインターフェース）は必要だから作られたわけだが
POSIXの一部しか使えないPOSIXコマンドは、必要なものが使えないということを意味する

**デフォルトの名無しさん** · 2021/02/22(月) 01:30:49.08

POSIX準拠にはPOSIXで規定されたコマンドおよびコマンドのオプションだけを利用することを規定してるのもあるな

**デフォルトの名無しさん** · 2021/02/22(月) 02:19:05.57

> 規定してるのもあるな

なんの話してるんだよｗ

そんなものないって言ったら
あるって言って証拠出してくれるんだよな？

**デフォルトの名無しさん** · 2021/02/22(月) 02:37:55.58

キチガイがまた暴れてる

**デフォルトの名無しさん** · 2021/02/22(月) 03:05:20.65

gawkやRubyなんかを使うくらいならPerlを使うべき。
異論の余地はない。

**デフォルトの名無しさん** · 2021/02/22(月) 04:19:52.69

簡単なシェルスクリプトならググらず書けるようになった新参者だけど、
オプションの法則に統一性ないのが一番解せないわ
ショートオプションはハイフンの後が一文字っていうけどfindの-typeからして守ってないしさ
wgetにも-nvがあるけど既に形骸化してんの？

**デフォルトの名無しさん** · 2021/02/22(月) 05:47:22.05

>>942
適切なツールを使いましょうってだけ
コマンドを組み合わせて使うなら
シェルスクリプトが一番適切
他のどの言語もコマンドを組み合わせて使うのには適していない

>>943
一部のコマンドに変なオプションがあるだけだよ
開発者がよく知らずに実装してしまっただけ

**デフォルトの名無しさん** · 2021/02/22(月) 12:30:54.33

メモリが安価になったという意味で時代は変わったんだから
組込含めてdashを選ぶ必要性はないでしょ

POSIX準拠なんてかつては大衆芸能だったが今では伝統芸能で
保存対象になるつつある歌舞伎みたいなもんだよ

**デフォルトの名無しさん** · 2021/02/22(月) 13:38:19.02

>>945
文句はディストリ屋に言ってくれ
Debian/Ubuntuはdashを選んでるし
Alpineはbusyboxを選んでるんだ
嫌でもdashやbusyboxを使わないといけないんだだよ

**デフォルトの名無しさん** · 2021/02/22(月) 13:42:31.76

>>943
ロングオプションなんかぐにゅの後出しみたいなもんやし、互換性のほうが重要やし、しゃあない。
統一性を期待するもんでも、守る守らないを議論するもんでもない。

コマンドラインの世界は、ただ混沌を受け入れるのみ。。。

**デフォルトの名無しさん** · 2021/02/22(月) 14:06:32.02

ロングオプションっていうかハイフン2個で始まるオプションに関しては統一されてる
変なオプションがあるのはハイフン1個で始まるやつ

もし今からオプションを規格化するとしたら、俺なら
-で始まるのは一文字のオプションだけ。オプションの引数はなし
--で始まるのはロングオプションで、オプションの引数はあって無くてもよいが
ある場合は --long=value みたいに必ずハイフンでつなげること
--long value形式は無しってルールにするだろうな

そうしないとオプションの解析は面倒くさすぎる

**デフォルトの名無しさん** · 2021/02/22(月) 14:28:14.65

2020年代にもなってオプション解析を自前でやらなきゃいけないという時代錯誤感よ

**デフォルトの名無しさん** · 2021/02/22(月) 14:49:21.32

自分でやりたくないならライブラリでも使えば？

**デフォルトの名無しさん** · 2021/02/22(月) 14:53:50.85

>>948
今さら「俺」ルールなんかいらんわ。ｗ

https://linuxjm.osdn.jp/html/LDP_man-pages/man3/getopt.3.html

もっとも、これを使うも使わないも、個々の自由。。。

**デフォルトの名無しさん** · 2021/02/22(月) 19:20:10.80

>>951
俺ルールじゃなくて、既存のルールのサブセットだけどな
まあ知らない人にとっては特殊なルールに見えるんだろうね

**デフォルトの名無しさん** · 2021/02/22(月) 21:20:04.93

>>946
シェバンに/bin/bash、 debian/control に Depends: bash って書くがよい

**デフォルトの名無しさん** · 2021/02/22(月) 21:48:09.71

何か作業しようとするときにログインがbashかそうでないかは重要

**デフォルトの名無しさん** · 2021/02/22(月) 22:36:34.00

>>952
それが「俺ルール」なんだっつーの。
アホなの？ｗ

**デフォルトの名無しさん** · 2021/02/22(月) 22:47:21.38

>>952
すでにデファクトスタンダードになってるだろう、>>951のがあるんだから「俺なら」ってのはいらないって話じゃないの
シェルスクリプト用には>>915を用いたのがになるだろうし
「俺なら」がGNUとBSDの違い(があるなら)を勘案してのかと思ったら、解析は面倒くさすぎるって言ってるから違うっぽいかな

**デフォルトの名無しさん** · 2021/02/22(月) 22:54:09.71

>>951はC言語のインターフェースじゃんｗ
ロングオプションにも対応してないし

**デフォルトの名無しさん** · 2021/02/22(月) 23:05:43.02

よく読め。色々よく読め

**デフォルトの名無しさん** · 2021/02/22(月) 23:05:58.69

シェルで標準的に使われてるのってgetoptかgetoptsじゃないの？
どっちも微妙だけど

**デフォルトの名無しさん** · 2021/02/22(月) 23:33:06.17

getoptはPOSIX準拠じゃないうえにMacで挙動が違うしな

**デフォルトの名無しさん** · 2021/02/24(水) 21:20:00.07

現行ディレクトリ直下にあるファイルを日付順に処理したい。
dateの-dオプションと'%s'書式を使ったやりかた
（-dオプションにlsの出力の日付欄を渡して，%s書式でsortに回しやすい形式に変換する）
は思い付くのだが，できればもうちょっと汎用性のあるやりかたでやりたい。
それこそAlpine Linuxでもできるようなやりかた，せめてSUS準拠くらいで。

**デフォルトの名無しさん** · 2021/02/24(水) 21:42:59.94

lsでソート出力すればいいじゃん

**デフォルトの名無しさん** · 2021/02/24(水) 22:44:33.75

Alpine LinuxだのSUS準拠だの言ってるくせに...

**デフォルトの名無しさん** · 2021/02/25(木) 00:58:03.42

>>962
lsで日付順ってできたっけ。
しかもaccessとかmodifyとか色々あるけど。

**デフォルトの名無しさん** · 2021/02/25(木) 01:17:21.10

最近はマニュアル読まないで人に聞く豆腐が増えたよな

シェルスクリプト総合 その35

シェルスクリプト総合その35