Rustで自作シェル書いてみた
はじめに 自作シェルを書いてみた記事はよく見かけるのですが、そのほとんどが fork -> exec という流れです。仕組みを学ぶという点で非常に有効なのでそれはそれで良いとして、 Rust では標準ライブラリの std::process::Command を使用してもっと簡単にコマンド実行ができるよ！ という記事があまりないので書いてみました。 コマンドの実行 REPL パース処理はできるだけシンプルに書きます。 標準入力から1行読み取り、Command::spawn() で実行します。 それを繰り返すのが REPL （Read-Eval-Print Loop）です。 これだけでシェルと言い張っても良いと思っています🤔 use std::io::{self, Write}; use std::process::Command; fn main() { loop { // プロンプト p
パイプに関係するさまざまなバッファ、ちゃんと意識していますか？ - Qiita
はじめに コマンドをパイプでつなげた時、各コマンドの間にはいくつかのバッファが存在します。そのバッファについてちゃんと意識しているでしょうか？ バッファの存在によって各コマンドの実行には分かりづらい変化があります。そのバッファを知らないと罠にハマってしまう・・・かもしれません。 プロセス間のパイプ通信のバッファ まずプロセス間のパイプ通信に存在しているバッファです。多くのコマンドは行単位でデータを処理しますが、一般的にパイプでつなげた各コマンドはそれぞれ処理速度が異なります。処理がすぐに終わるコマンドもあれば時間がかかるコマンドもあります。各コマンドは並列で動作可能ですが必ずしも並列で動作するわけではありません。 一般論としてパイプライン全体の処理にかかる実時間はパイプでつながったコマンドの中で一番遅いコマンドに足を引っ張られます。いくら並列で動作可能と言ってもデータが到着しなければ処理す
タスクランナーとしてのmakeを使う際の工夫と注意点 - KAYAC engineers' blog
SREチームの長田です。 みなさま開発・運用上の定形オペレーションに伴うタスク実行をどのように管理していますか？ 今回は make をタスクランナーとして使う例を紹介します。 タスクランナーがほしい タスクランナーを使う主なモチベーションは以下の2つです。 タスクをリスト化したい タスクの実行インターフェイスを統一したい タスクがリスト化されていれば、それ自体が生きたドキュメントとして機能します。 また、タスクの実行インターフェイスが統一されていれば、 例えばタスクに前処理や後処理を追加したとしても、 開発・運用メンバーが実行するべき操作が変わることはありません。 操作変更の周知コストも下がりますし、変更に伴う操作ミスも減らすことができます。 タスクランナーに求めるもの タスクランナーの機能としては必要最低限のものがよいと考えています。 高機能なタスクランナーも魅力的ではあるのですが、タス
The #! magic, details about the shebang/hash-bang mechanism
Bourne | Ash | #! | find | ARG_MAX | Shells | whatshell | portability | permissions | UUOC | ancient | - | ../Various | HOME "$@" | echo/printf | set -e | test | tty defs | tty chars | $() vs ) | IFS | using siginfo | nanosleep | line charset | locale The #! magic, details about the shebang/hash-bang mechanism on various Unix flavours 2001-08-13 .. 2021-10-20 (see recent changes) Here you'll find
PATH の扱い - Qiita
unix 系 OS では ${PATH} 環境変数を参照してコマンドの検索パスを指定する事ができます。 通常はログイン時にシステムデフォルトのコマンド検索パスが ${PATH} に自動で設定されていますが、ユーザ毎のシェルのログインファイル (${HOME}/.profile 等）で自分用のコマンド検索パスを追加設定する事が多いと思います。 ここで気をつけるべきは ${PATH} 中のヌルパス (::) はカレントディレクトリ (.) と同等に扱われてしまう事です。 例えば
sh -cで呼び出したコマンドがbashだと孫プロセスにならないことがある | おそらくはそれさえも平凡な日々
前提として、/bin/sh は、デフォルトでは、RHEL系の場合bashシェル、Debian系の場合dashシェルへのsymlinkになっています。この2つのシェルの挙動は細かいところで結構異なります。そもそもの思想として、dashシェルはPOSIX互換を目指す軽量なシェルであり、bashは拡張された高機能なシェル。なのでbash前提で書かれたシェルスクリプトがdashでは動かない、みたいなことはよくあります。そういう感じで困ることがままありますが今回もそういう話。 例えば % sh -c "sleep 100" のようなコマンドを実行した場合、呼び出し元の子プロセスが sh になり、その更に子プロセスが sleep になると直感的には思うでしょう。つまり以下のような具合。 . \_ sh -c sleep 100 \_ sleep 100 しかし、 sh の実体が bash である場合な
Vagrantのshell provisionerでApacheのビルド済tarボールをOSバージョン毎に作る術
Pepabo AdventCalendar 2014の10日目の記事です。昨日はあんちぽサンタ記事を見て入社したlaughkでした。明日はhisaichi5518です。 ソフトウェアのビルド方法について。 今年は特にセキュリティ関連でCVE対応が多かったり 経年したサービスのOSは刷新したいけど同じミドルウェアのバージョンを使いたかったり な時に、rpmをビルドするのはしんどい（弊社は主にRHELクローンなディストリを使っています）ということで、今年は社内でVagrantを利用した、ビルド済ソフトウェアのtarボールを作るのが流行りました。 今日はその一例としてApacheのビルドについて。サンプルのプロジェクトを tnmt/vagrant-build-apache22に置きました。 git clone https://github.com/tnmt/vagrant-build-apach
パイプとフィルタ ~ソフトウェア工学における有用なアーキテクチャ~ | POSTD
パイプライン は、最近のソフトウェアエンジニアリングにおいて、非常に便利な（そして驚くほど活用されていない）アーキテクチャパターンです。ソフトウェアでデータの流れを制御するためにパイプとフィルタを用いる考え方は、最初のUNIXシェルが作られた1970年代からあります。もしターミナルエミュレータでパイプ” | ”を使ったことがあるなら、”パイプとフィルタ”を活用できていることになります。以下の例を見てみましょう。 cat /usr/share/dict/words | # Read in the system's dictionary. grep purple | # Find words containing 'purple' awk '{print length($1), $1}' | # Count the letters in each word sort -n | # Sort l
近頃の開発環境 : Mosh、z、tmux、Emacs、Perl について - naoyaのはてなダイアリー
昨日は年始の挨拶ついでに ELPA について脈絡もなく突然書きましたが、引き続き近頃の開発環境についてもだらだらと書いてみよう。 Mosh mosh というと一部の人間はひげなんとかさんが開発しているモナー的なあれを思い浮かべるかもしれないがそうではなく、mobile shell のことである。 思い切り簡略化して言うと「快適なssh」。回線が不安定な所でもエコー遅延など全く気にせず使えるし、Mac をスリープさせて復帰させたときもリモートホストにそのまま繋がりっぱなしのように見せかけてくれたりする。 詳しくはこの辺を。 mosh: MITからモバイル時代のSSH代替品 - karasuyamatenguの日記 インストールはリモートとローカル両方に必要ですが、まあ大概パッケージがあると思います。EC2 の Amazon Linux でも yum レポジトリの EPEL を有効にすれば y
シェル操作課題 (cut, sort, uniq などで集計を行う) 設問編 - Yamashiro0217の日記
この記事は弊チームの新人の方にシェル操作に慣れてもらうために作った課題である。 皆様のチームの新人にやってもらってもいいですね。 あとで解答編を書く。 もちろん他の方も解いてもらって構わない。 というか僕の解答以上の解答がきっとあるはずなので、それを教えて欲しい。 はてブで解答でも面白解答お待ちしてます。 さて本題。 Webアプリケーションを作っていると偉いさんとか、いわゆる企画の人とかから 「ちょっと○○がどうなってるかログから数字だせない？」 とさらっとお願いされたりする。 そこで「いや、ちょっと手が空いてなくて（こっちは忙しいんだよ糞がっ）」と答えたくなるかもしれないが、 そこは「じゃあさくっとやっておきますよ！僕にかかればちょろいっすよ！」と答えらればかっこいい。 （あまりさくっとやりすぎるとそういう細々依頼がたくさんくる諸刃の剣） 例えば以下のようなログファイルがあったとする。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - atuinsh/atuin: ✨ Magical shell history