UNIXの部屋 検索-リダイレクト
最終更新 2019-01-27 UNIX/Linux のシェル sh・bash・csh・tcsh のリダイレクトを説明する。ファイルへの出力、コマンド出力を別のコマンドの入力とする、標準入力・標準出力・標準エラー出力、パイプなどもあわせて説明する。
シェルのリダイレクトにまつわる失敗
Landscape トップページ | < 前の日 2004-03-27 2004-03-28 次の日 2004-03-30 > Landscape - エンジニアのメモ 2004-03-28 シェルのリダイレクトにまつわる失敗 当サイト内を Google 検索できます * シェルのリダイレクトにまつわる失敗この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [bash] シェルのリダイレクトについての理解が不十分なためにやってしまった失敗。 標準出力も標準エラー出力も /dev/null に捨てたいとき、間違えて以下のようにしてしまうことがときどきあった。最近はやらなくなったが。 # 間違い $ command 2>&1 >/dev/nullこれだと command の標準出力は /dev/null に向けられるが、command の標準エラー出力は画面に向いてし
低水準ファイル入出力関数を使おう - 68user's page
低水準ファイル入出力関数 perl でプログラミングするにしても、 基礎知識としてC言語のファイルディスクリプタの概念を知っておくにこしたことはありません。 特に 4引数 select を使うときには、 ファイルディスクリプタの知識があると理解が早いでしょう。 C言語でファイルを扱うときは、一般的に fopen・fread・fwrite・fclose などの ライブラリ関数を使います。これらは stdio.h で宣言されており、 標準入出力ライブラリ (標準入出力関数) と呼ばれます。 ファイルをオープンするときは FILE *fp; fp = fopen("file.dat", "r"); として FILE 構造体を得ます。それに対して fread・fwrite を実行します。 しかし、これら fopen・fread などのライブラリ関数も、 内部では open・read・write・c
パイプ - odz buffer
Unix(or its variants)のシェルがどうやってるのかは知らないけど (少し前に Artonさんのところで何か見たような記憶はあるが)、 Windowsの場合は大まかに コンソール プロセスを生成して標準ハンドルをリダイレクトする方法 にあるように 入力用、出力用の二つの無名パイプを作る(CreatePipe) → それぞれを起動する子プロセスのための 標準入力、標準出力および標準エラー出力用のハンドルににDuplicateHandle → 得られたリダイレクト用のハンドルを用いて CreateProcess という手順になるので、 複数段のパイプの尻尾から順番にこのハンドルの複写手順を取りながら 必要なプロセスを起動していくのではなかろうかと。 んー cmdline.split('\|').each{|prc| ほげほげ} て感じ? おー、UNIX も Windows もあ
inetd の仕組みを見てみる - naoyaのはてなダイアリー
inetd や xinetd (以下 inetd) はインターネットサービスをデーモン化するのに共通している処理を担い、ほとんどの時間をアイドル状態で過ごすその手のサービスに必要なリソースを節約する役割を果たします。 inetd のひとつ面白いところは、inetd でサービス化したいプログラムの標準入力/標準出力がクライアントソケットの入出力に接続されるところです。例えば daytime 相当のサービスを自分で作ろうと思った場合 #!/usr/local/bin/perl # daytime.pl use strict; use warnings; use DateTime; use IO::Handle; STDOUT->autoflush(1); STDOUT->printf( "%s\n", DateTime->now(time_zone => 'Asia/Tokyo') ); と標
C++と Pthreads でミニマルなHTTPサーバを書く - いやなブログ
C++と Pthreads でミニマルなHTTPサーバを書く 『UNIXネットワークプログラミング』を読んでいると、自分でも何かネットワーク系の小さなプログラムを書いてみたくなりました。そこで、ミニマルなHTTPサーバを C++と Pthreads で書いてみました。 同じ著者の「詳解UNIXプログラミング」もそうだったように、今回の本もほとんどすべてのページに、重要なことが書かれています（最後のほうのXTIの部分は例外かもしれませんが）。 たとえば、27章ではネットワークサーバの実装として、次の設計方針がそれぞれ検討され、実際のコード付きで解説されています。 クライアントごとに fork 事前に fork - 各プロセスで accept 事前に fork - ファイルロックで accept を保護 事前に fork - Mutex ロックで accept を保護 (PTHREAD_PRO
404 Blog Not Found:書評 - The Art of Unix Programming (邦訳版)
2007年06月26日13:45 カテゴリ書評/画評/品評Open Source 書評 - The Art of Unix Programming (邦訳版) このギーク度120%のタイトルにだまされてはいけない。 The Art of UNIX Programming Eric S. Raymond / 長尾高弘訳 [原著:The Art of UNIX Programming] なぜなら、本書はギークとつきあう必要のあるすべてのスーツ必携の一冊なのだから。 本書「The Art of UNIX Program」は、「七夕の国」で言う所の「窓が開きかつ手の届く」者である Eric S. Raymond (ESR)が、「UNIXプログラミングとは何か」ではなく、「なぜUNIXなのか」を説いた本である。 序章 本書は「how-to本」ではなく「why-to本」なのである。 目次 序章 第1部
UNIXカーネルの設計 - メモ帳
名著。OS 一般には興味がないが Unix が好きという人にとっても得るところがある。
エスケープよりexec - odz buffer
ref:更新履歴兼雑記 - wgrep, wlocate, wfind ref:更新履歴兼雑記 - ラッパと正しいエスケープ HTML の実体参照化もしたほうがいいんじゃないかとそういう話もあるけれど。 そもそも、単純に IO.popen に渡すコマンドをエスケープしないといけないというのがいけてない。ポータビリティとか考え出すと恐ろしいし。 ということで、Open3.popen3 を使うか、IO.popen で "-" を指定して fork/exec するとかしたほうが良いんじゃなかろうか。こういうのね。 def popen(cmd, args, mode, &block) IO.popen('-', mode) do |io| if io # parent block.call(io) else # child exec(cmd, *args) end end end popen('l
/usr - odz buffer
/usr の usr って何なんだろ。 「/usr は user services and routines の略」という話は、 話としては割と良く知られてることなのだけれども、 どうも信憑性が怪しい。 日本における原典と言われているのは JUS の機関誌 /etc/wall で、 これはさらに UniForum の機関誌からの翻訳記事つーことみたいだが。 しかし調べた限り、 hier(7) にこのことを記述している現行の UNIX 系 OS はないし、 ぐぐっても日本語のページしか出てこない。 さすがに 80 年代の事情までは分かりかねるわたくし。 大昔の習慣としては joe さんのホームディレクトリが /usr/joe だったりするし、 実際 V6 UNIX のビギナーズマニュアルを読むとそう書いてあったりする。 一方で V6 UNIX の頃には既に /usr/bin も存在していたの
Wataru's memo(2007-05-01)
● [Books][UNIX][Thoughts] UNIX システムプログラミング三大名著と図書館 2007年版の「UNIX システムプログラミング・お勧めの書」として、以下の３冊を紹介してきました。 UNIX 誕生から３０年以上経過した現在でも、３冊の発行は続けられていますが、残念なことに三大名著を揃える国内の図書館は数少ないようです。３冊の特徴を簡単に振り返った後に、この状況を確認してみましょう。 Understanding Unix/Linux Programming UNIX システムプログラミングの入門書として、本書を越える書籍は現時点でこの世に存在しないと、私は断言致します。ハーバード大学での授業をもとに練り上げられた本書の内容は、群を抜いた独創性に満ちており、ある意味 Stevens 氏の APUE を凌駕しています。 説明図、題材として使われるプログラム、すべてに工夫が凝
Perl and UNIX Network Programming (YAPC::Asia 2007) - naoyaのはてなダイアリー
YAPC::Asia で Perl UNIX ネットワークプログラミングについての発表をしてきました。UNIX ネットワークプログラミングの基礎の概論、I/O多重化の話、Perl のモダンなネットワークライブラリの話です。資料を以下に置いておきます。 http://bloghackers.net/~naoya/ppt/070404Perl_and_UNIX_Network_Programming.ppt (ppt, 122k) なお、会場では口頭で触れましたが、資料中のソースは簡単のためエラー処理を飛ばしています。また、途中で出てくる図は例えば vfs のページキャッシュをはしょってあったりとこれも簡単のため省略事項がある点にご注意ください。 それからフォントが Consolas なので Consolas が入ってない環境だと変になる、かも。
ウノウラボ Unoh Labs: UNIXデーモンを作ろう
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
builtin と fork/exec と - odz buffer
ref:404 Blog Not Found:あわてるな ディスクはそんなに 速くない コメント欄から 最後の例がそこそこ速いように見えていますが、echo じゃなくてディスクに触る処理だと結果は大きく変わるのでは。 いやいやいや。そういう話ではなくて、echo は shell の組み込みだから fork していないだけの話ですよ。以下、zsh で % find -type f -name '*.java' | wc -l 267 % time find -type f -name '*.java' | sed 's!^!echo !' | sh > /dev/null find -type f -name '*.java' 0.01s user 0.01s system 73% cpu 0.027 total sed 's!^!echo !' 0.01s user 0.00s syste
レポジトリとファイルの削除に関わるいやな思い出 - odz buffer
間違えてリポジトリを消した私は豆腐の角に頭をぶつけるしかないのか。(ぶ レポジトリはホームディレクトリの外に作りましょう、という話ではないだろうか。基本的には直接いじる必要ないし。 そういや、5、6年前に Java のコードを書いていて Jakarta Ant*1 でビルドしていたんだけども、あるときに <mkdir dir="~/target" />みたいなことを書いて実行したらプロジェクトのディレクトリ直下に "~" というディレクトリができてしまった。当時は "~" を shell が展開していることも理解していない阿呆だったわけだが、間違って作ってしまったディレクトリを削除しようと、直後に rm -rf ~なコマンドを実行した。ENTER を押した瞬間、「あー」となったのは言うまでもない。 まぁ、コードは全て別サーバの CVS に入れてあったので最悪の事態は避けられたわけだが、.e
xargs + shell script のはまりどころ - odz buffer
昨今、Java でプログラムを書く場合に外部ライブラリに依存することが多いと思うのだけども*1、そういう場合 #!/bin/sh java -cp commons-lang.jar:commons-logging.jar:log4j.jar:classes com.example.Foo "$@" な shell script を用意して使うことが多い*2。 で、この場合 find . -type f -print0 | xargs -0 -e ./foo.shてなことをやると、実際に java を起動する場合のコマンドラインが ARG_MAX を超えるなんて羽目になってはまる罠。 というようなことを誰も書かないなぁ、と思って書いてみたわけだけど、これって常識ではないんだろうか。だからこそだれも書かないのかな？ *1:Javaの場合コンパイル済みの JAR に CLASSPATH を通すだ
findのあれとか - odz buffer
find + rm ネタが微妙に盛り上がっているようだけど、消えて困るようなファイルはバージョン管理に入れておけという話だ。 あと、sed を使ってコマンド列に変換して sh に食わせる方法は、ファイル名に '*' とか '?' とか '\' とか入っていると死ねる罠。そんなに間違って消すのが怖いなら find . -type f -name '*~' -print0 | xargs -0 -e rm -iでいいんでないの？む、xargs に -e をつけろって話は出てきてないような。 そういえば、ファイル名に改行ってのは出来るんだっけ？ 追記 xargs rm -i はうまく動かないようだ。GNU の xargs なら xargs -p などを使ったほうがよさそう。
無精で短気で傲慢なプログラマ find には sh!
ウノウラボ Unoh Labs: コマンドラインで作業する上で知っておくといいテクニック% find . -name '*~' -exec rm {} \; 404 Blog Not Found:勝手に添削 - find(1)% find . -type f -name '*~' | xargs rm % find . -type f -name '*~' | perl -nle unlink わたしなら% find . -type f -name '*~' | sed 's/^/rm /'で確認し、OK なら% find . -type f -name '*~' | sed 's/^/rm /' | shで消します。 いまどき fork/exec rm のオーバーヘッドがどれほどのものか。 xargs を使うとき、rm が 1回だけ実行されるときと、ARG_MAX を超えたときに rm
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
暗黙のルール
Amazon.co.jp： The Art of UNIX Programming: 本: Eric S.Raymond,長尾 高弘
