目的 他者／他社からzipやtar.gzで.shファイルを受領、 linux環境で実行してみると以下のエラーメッセージが表示される。 /bin/bash^M: bad interpreter: そのようなファイルやディレクトリはありません (No such file or directory) - 特に送り主がWindowsをメインとしている環境からの場合が要注意 結論 改行コードをCRLFからLFに置換して実行できるかを確認する。 より正確に言うならCRを除去する 経緯 エディターで表示させてもUTF-8の.shファイル、しかしlinux上で実行すると、 /bin/bash^M: bad interpreter: そのようなファイルやディレクトリはありません (No such file or directory) まずcatで改行コードを確認してみる ^MがCR、$がLFを表す
ある実験をするためにシェルスクリプトを書いたのですが、「そのようなファイルやディレクトリはありません」と言われてしまいました。 ネット検索をしてみると、よくある原因は改行コードがCRLFになっていること（CRが余計）らしいのですが、今回は違いました。 真犯人は「BOM」でした。 経緯 どんなスクリプトを書いても同じ結果になるので、以下のシンプルなスクリプトにして実験しました。 #!/bin/bash echo "Hahaha!" このスクリプトを「uho.sh」というファイルにして、実行したのですが ./uho.sh: 行 1: #!/bin/bash: そのようなファイルやディレクトリはありません と表示されます。そこで、 cat -A uho.sh としたら、 M-oM-;M-?#!/bin/bash$ $ echo "Hahaha!"$ と表示されました。 ^M（CRを表す）は無く、
$ cowsay -f turtle Hahaha ________ < Hahaha > -------- \ ___-------___ \ _-~~ ~~-_ \ _-~ /~-_ /^\__/^\ /~ \ / \ /| O|| O| / \_______________/ \ | |___||__| / / \ \ | \ / / \ \ | (_______) /______/ \_________ \ | / / \ / \ \ \^\\ \ / \ / \ || \______________/ _-_ //\__// \ ||------_-~~-_ ------------- \ --/~ ~\ || __/ ~-----||====/~ |==================| |/~~~~~ (_(__/ ./ / \_\ \. (_(___/ \_____)_)
LD_LIBRARY_PATHなど、いちいち設定するのが面倒な環境変数を、 シェルスクリプトに記述できたら便利です。 [env_set.sh] # 環境変数の設定 export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/hoge さっそく、このシェルスクリプトを実行してみます。 $ ./env_set.sh $ echo $LD_LIBRARY_PATH $ …？。恐らく、シェルスクリプトで設定した内容は、反映されていないはずです。 通常、シェルの中で設定された環境変数は、そのシェルを抜けると消去されるためです。 シェルスクリプト内で設定した環境変数を、呼び出し元のシェルにも反映するためには、 次のようにしてシェルスクリプトを実行すればOKです。 $ source ./env_set.sh $ echo $LD_LIBRARY_PATH
はじめに bash などのシェルには [ ... ] と [[ ... ]] の二種類の比較方法があります。一つはコマンド、もう一つはシェルの文法なのですが、具体的にはこの二つは一体何が違うのでしょうか？ そもそもなぜ似ている機能が二つもあるのでしょうか？ この記事は言語設計者の気持ちになって考えることで、その理由を解き明かそうという記事です。 なお、違いについての簡単な説明については「test と [ と [[ コマンドの違い - 拡張 POSIX シェルスクリプト Advent Calendar 2013 - ダメ出し Blog 」の記事がよくまとめられていますので紹介します。一通りの違いを素早く知りたい方はこちらを参照してください。 参考 シェルの歴史や種類については「シェルの歴史 総まとめ（種類と系統図）と POSIX の役割」に詳しくまとめています（系統図とか頑張って書いたので見
![シェルスクリプトの [ ] と [[ ]] の違いを歴史的に解説 〜 言語設計者の気持ちになって理解しよう - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/647514abcaea7b5f8e1a1cdb8e496644eb63f609/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JUUzJTgyJUI3JUUzJTgyJUE3JUUzJTgzJUFCJUUzJTgyJUI5JUUzJTgyJUFGJUUzJTgzJUFBJUUzJTgzJTk3JUUzJTgzJTg4JUUzJTgxJUFFJTIwJTVCJTIwJTVEJTIwJUUzJTgxJUE4JTIwJTVCJTVCJTIwJTVEJTVEJTIwJUUzJTgxJUFFJUU5JTgxJTk1JUUzJTgxJTg0JUUzJTgyJTkyJUU2JUFEJUI0JUU1JThGJUIyJUU3JTlBJTg0JUUzJTgxJUFCJUU4JUE3JUEzJUU4JUFBJUFDJTIwJUUzJTgwJTlDJTIwJUU4JUE4JTgwJUU4JUFBJTlFJUU4JUE4JUFEJUU4JUE4JTg4JUU4JTgwJTg1JUUzJTgxJUFFJUU2JUIwJTk3JUU2JThDJTgxJUUzJTgxJUExJUUzJTgxJUFCJUUzJTgxJUFBJUUzJTgxJUEzJUUzJTgxJUE2JUU3JTkwJTg2JUU4JUE3JUEzJUUzJTgxJTk3JUUzJTgyJTg4JUUzJTgxJTg2JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz01MjNkMGI4OGJlMzhhMTc4N2JhMjc1NDk1ZjhkNjdmNA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTcxNiZ0eHQ9JTQwa28xbmtzbSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTMyJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9YzU4ZjdmNmRhMDNjMTE2MGZlNWU3ZTc5Y2Y2OTljYTk%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D93ef0dfa5f01edb32750f9b33392ebfc)
ここ数年、再利用するかも知れないコードは可読性がいいPythonで書くことが多かったものの、最近「スクリプトを書くほどでもないなぁ」的な作業が頻発し、bashのワンライナーで誤魔化してみたところ、最近のbashは変数展開や置換機能がずいぶん充実していて、かつてはsedやtr、awkを使って書いていた処理が、ほぼbashの機能だけで書けるようになっていました。 そこで改めてbashのマニュアル等を確認したら、「へー、こんなこともできるんだ」的な機能があれこれ目について、ちょっとbashに対する認識を改めているところです。今回は、そのようなbashの便利な機能をいくつか紹介してみようと思います。 bashの来歴 Linux系ディストリビューションのデフォルトのシェルであるbashは、GNUプロジェクトが開発したシェルで、"Bourne Again SH"の略になっています。 この"Bourn
Windows 使いのみなさん、MSYS2 使っていますか？使っていなければ、ぜひ使ってみてください。便利ですよ！ さて、そのMSYS2＠Windows を使っていると、シェルスクリプトを Linux でもMSYS2＠Windows でも動くようにしておきたい場合があります。いわゆるマルチプラットフォーム対応ですね。組込み開発に限らずですが、開発ツールの都合でLinuxとWindowsを行ったり来たりすることがあるので、マルチプラットフォーム対応にしておくと便利です。 シェルスクリプトにてOSがWindwosかどうか判定する 基本的に bash ならどこでも動くと思いますが、Windows かどうかで記述を分岐させたい場合が時々あります。ディレクトリ構成や使える外部ツールが違う時などですね。そういう時は環境変数COMSPECを参照します。 下記のようにCOMSPECを確認することで、Win
普通のプログラミング言語での開発に慣れた人ほどシェルスクリプト、特にBashで戸惑う部分の一つに、i = 0のように空白を開ければエラーになるし、かといってif[$i!=0]のように詰めてもやっぱりエラーになる、という点が挙げられます。書きたい物を思うように書けなくて「なんだよこのクソ言語は！！！」とブチギレる人は少なくないのではないでしょうか。この記事では、そのイライラを解消するポイントをお伝えしようと思います。 以下、特に断り無く「シェルスクリプト」と書いている場合はすべて「Bashのスクリプト」という意味になります。zsh等他のシェルではまた事情が異なりますので、ご注意ください。 （※以前プログラマーの君！ 騙されるな！ シェルスクリプトはそう書いちゃ駄目だ！！ という話という記事を書いたのですが、この記事は、その増補リファイン版として執筆させて頂いたSoftwareDesign 2
シェルスクリプトは変数代入で = の前後にスペースを置けない！･･･の本当の理由を知ると優れた文法が見えてくるShellScriptBashUNIXshellPOSIX はじめに シェルスクリプトの変数代入で = の前後にスペースを置くことができない理由は、検索すれば「プログラマーの君！ 勘違いするな！ シェルスクリプトでは読みやすさのためにスペースを置くな！！ という話」のような記事がすぐに見つかります。記事に書いてあるとおり変数代入とコマンド呼び出しと区別がつかないからです。それは間違いではないんですが、私はもう少し説明が足りないと感じています。そこで今回は = の前後にスペースを置けない本当の理由を解説したいと思います。 の前に皆さんにはこの話を読みながら、自分がシェルスクリプトの言語設計者だったとしたら、どういう言語仕様にするかを考えて欲しいです。なぜかと言うとシェルスクリプトの文
はじめに シェルスクリプトに関しての長所と短所をまとめてみました。多くの短所を上げていますが、私はシェルスクリプトを嫌っているわけではなく（むしろ逆）、現在のシェルスクリプトが抱える問題点を明らかにし、シェルスクリプトはどう使うべきか？ またはどう使うべきではないか？ 問題点があるならばそれを解決することはできないか？ を考えるためにまとめています。問題を解決するにはまず問題点を明らかにしなければいけません。 またシェルスクリプトを本来の用途に合わないものに使うと逆に開発が難しくなってしまいます。それは使い方が悪いわけでシェルスクリプトの問題ではありません。間違った使い方によってシェルスクリプトの価値が不当に下げられてしまうことを減らすために、あえて多くの短所をあげています。つまり最初からこんな用途に使おうと思うな。ということです。（使うことを禁止はしませんが、わかった上でやりましょう。実
要約：決定版はとくにない。 kzys氏のシェルスクリプトを書かないという記事は面白かった。 https://blog.8-p.info/ja/2021/09/15/bash/ シェルスクリプト、ごくたまに書くことはあるが、ほんともう細かい話とかはすべて忘れているし、覚える価値を感じない。いまさら覚える必要のない技術だなと感じる。が、その一方でなかなか代替品がないようなニッチでもある。 自分は必要に応じてPythonかRubyか、といったあたりを使うことが多いが（perlはもう書けなくなった）、なかなかこれという感じには思い至らない。なにがいいんだろうね？という。 前提条件：インタラクティブな環境（REPL）はなくてもいい。そこはもう既存のシェルでいい。自動化したシェルスクリプト的なタスク記述を目標とする。bashの置き換えという意味では「どこにでもインストールされていることを前提にしないと
今年から、できるだけシェルスクリプトを書くのをやめようとしている。私が毎日 zsh に打ち込んでいるのも広義のシェルスクリプトだし、自分用の雑なスクリプトを書くことはあるけれど、チームの他の人も将来に使ったり改変したりするようなものは、なるだけ他の言語を使っている。 シェルスクリプトを書くのは難しいし、その難しさは、学ぶに値しないといったら言い過ぎかもしれないけれど、2021年に初心者が取り組むべき問題とは言い難いと思う。 シェルは悪いプログラミング言語である Bash Strict Mode とかを使ってみても、シェルスクリプトには落とし穴が多すぎる。自分で書いたものを自分で使っている分には大丈夫なのだけど、スクリプトがチーム内で使われるようになると、考慮していなかったところ、例えばファイル名に空白文字が含まれるとか、そういうレベルの微妙なところで、ちゃんと書かれていないスクリプトは壊れ
補完機能を利用し、ターミナルを使ってみよう 近年、Linux の話題は GUI 中心の展開をしています。Windows 的なアプローチでは厄介者のイメージが強いかもしれないコマンド操作ですが、元々コマンドをシェルにしている Linux/UNIX には便利なコマンドラインツールがたくさんあります。ここでは、各コマンドの紹介、説明は行いませんが、bash を便利に拡張する bash-completion パッケージとコマンドを使い始めるための基礎の基礎、ターミナル利用の Tips をいくつか紹介します。 ここに書いた操作方法は GUI 画面のターミナル上でも、CUI のコンソールでも同様に使えます。CUI に馴染んでおけば「X が起動しない」とか、「レスキューモードに入らなければ」というときでも、落ち着いて作業できます。 bash-completion は bash の補完機能を大幅に拡張する
みなさんはHomebrewをお使いでしょうか。macOSをお使いの多くの開発者が使っていると思います。 HomebrewのインストーラーはRubyで書かれており、次のコマンドでインストールするようになっていました。 /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" HomebrewがRubyに依存していることは良いのですが (formulaの書きやすさはRubyならでは)、インストーラーの話になると事情が変わってきます。HomebrewのインストールコマンドはmacOSの工場出荷状態でも動く必要があります。こういうものにRubyを使っているのはリスクがあります。 将来的にmacOSデフォルトにRubyやPythonが含まれなくなる (参考リンク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
