シバンには #!/usr/bin/bash と #!/usr/bin/env bash のどっちを書くべきか - Qiita
環境 Ubuntu20.4 はじめに 色々なシェルスクリプトの中身を見ていると、シバンには、#!/usr/bin/bash と記述しているものもあれば、#!/usr/bin/env bash と記述しているものもあります。 はたして、どちらが正しいのでしょうか？ #!/usr/bin/bash こちらの記述はbashの絶対パスを指定しています。確認のためにつぎのコマンドを実行すると、確かにbashの絶対パスが表示されます。 シバンにこちらの記述を指定すると、シェルスクリプトを別のディストリビューションに移植したとき、ディストリビューションによってシェルが入っているディレクトリ環境が異なるため、そのままでは動かない場合が出てきます。 他の環境に移植することがない場合は、この書き方でも問題ありませんが、シェルスクリプトを一般に公開して、色々な環境でマルチに利用してもらうような場合は、このような
PowerShellのスクリプトを書く時の諸注意
先日Windows向けの作業のちょっとした自動化のためにPowerShellのスクリプトを書いたので、少し躓いたポイントを書きます。 大人しくLinux版のPowerShellもインストールします WSL2のEmacsから快適に編集するためにシンタックスなどのエラーレポートなどがやはり欲しいですね。 Powershell - LSP Mode - LSP support for Emacs を使えば普通にLSPが利用可能ですが、インストールするためにpwshが実行ファイルとしてPATHに認識されている必要があります。 しかしWSL2上で作業しているのですから、 Windows上のpwsh.exeを使えば多重にインストールする必要がなくなるのではと考えました。 そこでlsp-pwsh-exeにpwsh.exeを追加してみたのですが、 Windows上のPowerShellをWSL2上で動かす
リストファイル記載FQDNからcurl実行、レスポンス情報を記録するbashスクリプト（ChatGPTによるリファクタリング） - Qiita
さっそくChatGPTによるリファクタリングを試してみた。AIの能力は素晴らしい。プログラミング、スクリプティング分野ではもはやかなう相手はいないだろう。人間というフィルタを通して翻訳するより、機械が書いてくれたほうがそりゃ立派なものができる。 AIにソースコードを書いてもらうことは、英語ネイティブの人に英会話してもらうようなものなんだろう。餅は餅屋。 ということで、前回の記事をさっそくChatGPTにリファクタリングしてもらった。 スクリプトの処理概要 ログファイル名に日付時刻を入れるため変数宣言 引数を変数に代入 引数の個数チェック 引数に記載するリストファイルの存在確認 引数で指定するグループ名ディレクトリの存在確認 ない場合はディレクトリを作成する ログディレクトリ名、ログファイル名の確定 ログファイルの空ファイル作成 ログファイル見出し行追記 リストファイル読み込み（while）
シェルスクリプトは「0が真」ではありません！ 真偽値と終了ステータスは違うものです - Qiita
はじめに シェルスクリプトの言語は他の言語と反対で 0 が真で 1（0以外）が偽であるという「間違った説明」をよく目にします。シェル言語も他の言語と同じで 0 は偽で 0 以外が真です。他の言語と真偽値の意味が「逆ではない」ので混同しないようにしてください。 間違ったシェルスクリプトの説明を JavaScript に置き換えるとこのようになります。 if (exit_status == 0) { // exit_status が 0 ならこちらが出力されるから JavaScript では 0 が真である console.log("true"); } else { console.log("false") }
How to use printf "%q " in bash?
I would like to print out augments of a function to a file. I was told a command printf "%q ", whose instruction is following, # man printf %q ARGUMENT is printed in a format that can be reused as shell input, escaping non-print‐ able characters with the proposed POSIX $'' syntax. On the basis of instruction above, I tried following code. #!/bin/bash # file name : print_out_function_augs.sh output
bashのfor文の中身を並列処理させる · sacre
こんなスクリプトがあったとして for i ($find ./src); do somecommand $i done forの中身 (somecommand) を並列で実行したい場合はこうすればよい for i ($find ./src); do somecommand $i & done wait いままでxargsを使ったりもしてたが、waitを使う方が分かりやすくてよい。 ただし、ループの数が数十とかで多くなってくるとプロセスを立ち上げすぎて遅くなったりするので、そういうときは xargs -P でやるのがよさそうではある。 参考 waitコマンド（子プロセスの完了を待つ） : JP1/Advanced Shell pidを指定しなかった場合は，実行中のすべての子プロセスの完了を待ちます tweet Share
set -e, -u, -o, -x pipefail explanation
bash_strict_mode.md Table of Contents set -e, -u, -x, -o pipefail set -e set -x set -u set -o pipefail Setting IFS Original Reference set -e, -u, -x, -o pipefail The set lines These lines deliberately cause your script to fail. Wait, what? Believe me, this is a good thing. With these settings, certain common errors will cause the script to immediately fail, explicitly and loudly. Otherwise, you ca
styleguide
Background Which Shell to Use Bash is the only shell scripting language permitted for executables. Executables must start with #!/bin/bash and minimal flags. Use set to set shell options so that calling your script as bash script_name does not break its functionality. Restricting all executable shell scripts to bash gives us a consistent shell language that’s installed on all our machines. In part
シェルスクリプトは変数代入で = の前後にスペースを置けない！･･･の本当の理由を知ると優れた文法が見えてくる - Qiita
シェルスクリプトは変数代入で = の前後にスペースを置けない！･･･の本当の理由を知ると優れた文法が見えてくるShellScriptBashUNIXshellPOSIX はじめに シェルスクリプトの変数代入で = の前後にスペースを置くことができない理由は、検索すれば「プログラマーの君！ 勘違いするな！ シェルスクリプトでは読みやすさのためにスペースを置くな！！ という話」のような記事がすぐに見つかります。記事に書いてあるとおり変数代入とコマンド呼び出しと区別がつかないからです。それは間違いではないんですが、私はもう少し説明が足りないと感じています。そこで今回は = の前後にスペースを置けない本当の理由を解説したいと思います。 の前に皆さんにはこの話を読みながら、自分がシェルスクリプトの言語設計者だったとしたら、どういう言語仕様にするかを考えて欲しいです。なぜかと言うとシェルスクリプトの文
Bash Strict Mode
Use Bash Strict Mode (Unless You Love Debugging) Let's start with the punchline. Your bash scripts will be more robust, reliable and maintainable if you start them like this: I call this the unofficial bash strict mode. This causes bash to behave in a way that makes many classes of subtle bugs impossible. You'll spend much less time debugging, and also avoid having unexpected complications in prod
シェルスクリプトで変数に改行文字を入れる方法の細かすぎる解説 - Qiita
すべての POSIX シェルで使用可能なので私はこれを推奨します。シェルスクリプトの改行コードは Windows の CR+LF ではなく LF を使用している前提です。いくつかの環境ではシェルスクリプトの改行コードに CR+LF を使用していても動くようなのですが（未調査）、遅かれ早かれ問題になるはずです。また需要は少ないと思いますが、POSIX シェル以前の Bourne シェルでも使える（おそらく）唯一の方法です。Solaris 10 などの古い環境にも対応させるのであればこの方法しかありません。 メリットはコードの量が最も少なく最も速いということです。デメリットは 2 行になるため少し不格好でインデントをする場合に困るだけですが、インデントに関してはこのような定数はスクリプトの上部の関数の外で定義するので通常は問題にならないはずです。 LF=$'\n' bash、ksh、mksh、
bashのhere-documentは一時ファイルを作成するらしい
出力はこう: this is here document 複数行に渡るテキストをリテラルとして表現したい場合に便利ですね。で、shellscriptからREST APIにリクエストを投げたくて、here-documentを使ってJSONをべたっとスクリプト内で書いてたんですけど、こんなエラーが出てました(パスはもちろん違いますよ。念のため。): /path/to/shellscript/using/here-document.sh: line 179: cannot create temp file for here-document: No space left on device 全然知らなかったけど、here-documentって一時ファイルを作成するんですね。確かめてみます。 $ docker run -it --rm centos:7 bash [root@8017e5e28d6
bashのexecute_command_internal()に関する疑問（メモ） - Qiita
pid_t paren_pid; int s; /*中略*/ paren_pid = make_child(/*ｓは使われない*/); if (paren_pid == 0) { s = (/*フラグとかを評価*/) s += (/*フラグとかを評価*/) last_command_exit_value = execute_in_subshell(/*sは使われない*/) /*ここで初めてｓの値が使われる*/ if (s) subshell_exit(last_command_exit_value); else sh_exit(last_command_exit_value); } /*これ以降ｓは使われない*/ コマンドがサブシェルで実行されるときは、このコードが実行されるっぽい。bashはmake_child()を呼び出して内部でfork()を呼び出す。そして、子プロセスはsにフラグの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【脱sed】いい加減シェルスクリプトで文字列をsedで置換するなんてやめよう - Qiita
set -uしてるときに変数が定義されてるかチェックする - Qiita
SC2028
SC2155
What are double colons :: in a shell script?
syntax error in conditional expression: unexpected token `;'
GitHub - DannyBen/bashly: Bash command line framework and CLI generator
