はてなキーワード: シェルスクリプトとは
シェルスクリプトを特に推奨するベスプラは知らんが使うべきでないというベスプラも知らん。ちなみにAWSは公式がbashのサンプルコードを出しまくってるぞ。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/bash_s3_code_examples.html
同じこと書こうとしてたわ
別のポストでシェルスクリプトの行数は1行までって書いてたけど、AWS公式のサンプルコードで2行以上のbashスクリプトなんて無数にあると思うんだがね
増田のチームは契約プログラミング、データの整合性チェック、トランザクション、条件網羅レベルのユニットテストなどをすべてクリアしたシェルスクリプトのプログラムを作っているということであっているかい?
まあそういうチームがいるのは知っているがかなり希少なエンジニアだと思うね。
ワークフロー管理ツールからはキックするのはPythonやRuby、場合によってはJavaとかの高級言語想定だね。
自分が想定してた許容できるシェルスクリプトはコマンド呼び出すとか1行程度の物だね。
他に呼び出したいシェルコマンドとかがあるんであれば高級言語内から呼び出したほうが良い。
多くの高級言語では契約プログラミングとかデータの整合性とかを検証するコードを書きやすいから、コマンドとかの出力結果を信頼できるデータとして後続処理に送ることができる。
ワークフロー管理ツールからはなにを実行するの?シェルコマンド?
シェルスクリプトでプログラミングするのがまずいケースがあることは分かるけど程度問題なんだよな。
ちなみにシェルを経由とシェルスクリプトでプログラミングの境目はどこにあるの?ifやforが出てきたとき?パイプが出てきたとき?
ここを明確に分けるのって難しいと思うんだよな
何を想定したのかわからないけど、シェルスクリプトを経由しているようなものは想定してなかったね。
それは君が言ってる現実の範囲が狭すぎるわ。。。単にシェルスクリプトの運用ノウハウがない人たちの集まりだがフルマネージド化というプロジェクトの特質によりシェルスクリプトの利用を回避できているに過ぎないと納得した
別にそれは最適な判断だと思うよ。チームのノウハウとアーキテクチャによって最適な技術は変わる。ただし、そこから君が得たと思っている知見を世界中の全ての企業の全システムに適用するのは誤っている
そんな事無いよね。Linuxサーバの保守とかでパッチノートとか読んだこと無い?
インストールし終わったらほとんどアップデートしてない凄まじい運用してるんならあれだけど
これだとどう?
命に関わらないシステムを動かしてるWeb系の業界想定ならRustで書くのが非生産的なのは同意だけど、なんで危険になるのか知りたいね。
噛み合わないポイントはここらへんにあるかもね
別の人が規模や複雑さが大きくなるなら別の言語に切り替える的なこと書いてたでしょ。保守のコストが深刻になってきたら別の実装に切り替えるのは普通のことだと思うが。そういう用途だと昔はperlが使われたが今はどうなんだろうな。
シェルスクリプトしか知らないやつがあらゆる複雑な処理をシェルスクリプトで何とかしてる会社はやばいと思うが、適材適所でシェルスクリプトを使ってる会社はやばくないというかそれがあるべき状態だと思う
膨大な数のプロジェクト・プロダクションが、数行~十数行程度のシェルスクリプトやその組み合わせに依存しています
それらすべてが「ヤバい」と主張されるのかもしれませんが、「自分以外のほぼ全員がヤバい」と主張している場合、大抵その人自身がヤバいですね
あんさん、Dockerとか言ってるしあんまりシェルスクリプトの凄まじい現場とか見たこと無いのでは。
シェルってのは人間の向けのコマンドの出力結果をawkとかsedで分解して後続につなげるもんなんで出力結果が変わると困る。ただ、manにはこういう処理で使えるほどの詳細な挙動は書いてないことが多い。
そして、シェルは出力結果おかしくても型とかじゃなくて文字列処理だから割りと後続処理が実行できちゃう。おかしい箇所を発見するのも時間がかかる。
そういうことが無いようにバリデーションのコードとか書き始めると複雑で何百行にもなるシェルスクリプトができて、これが一層壊れやすいし保守開発がめんどいことになる。