AWS の EC2 インスタンスに sqlite が入っているか調べたときに、
見たことのない記号を発見したので調査。
----------------------------------------
[ec2-user@xxx ~]$ yum list|grep sqlite
sqlite.x86_64 3.6.20-1.8.amzn1 installed
sqlite-devel.x86_64 3.6.20-1.8.amzn1 @amzn-main
apr-util-sqlite.x86_64 1.4.1-4.13.amzn1 amzn-main
libdbi-dbd-sqlite.x86_64 0.8.3-5.1.5.amzn1 amzn-main
python-sqlite.x86_64 2.6.0-1.10.amzn1 amzn-main
python24-sqlite.x86_64 2.6.0-1.13.amzn1 amzn-main
sqlite.i686 3.6.20-1.8.amzn1 amzn-main
sqlite-doc.x86_64 3.6.20-1.8.amzn1 amzn-main
sqlite-tcl.x86_64 3.6.20-1.8.amzn1 amzn-main
----------------------------------------
sqlite-devel についている @amzn-main って何？
と思ったら、結構 @ がついていることを発見。
----------------------------------------
...
alsa-lib.x86_64 1.0.22-3.9.amzn1 installed
apr.x86_64 1.4.6-1.10.amzn1 @amzn-main
apr-devel.x86_64 1.4.6-1.10.amzn1 @amzn-main
apr-util.x86_64 1.4.1-4.13.amzn1 @amzn-main
apr-util-devel.x86_64 1.4.1-4.13.amzn1 @amzn-main
apr-util-ldap.x86_64 1.4.1-4.13.amzn1 @amzn-main
aspell.x86_64 12:0.60.6-12.7.amzn1 @amzn-main
at.x86_64 3.1.10-43.8.amzn1 installed
attr.x86_64 2.4.44-7.9.amzn1 installed
audit.x86_64 2.2-2.17.amzn1 installed
audit-libs.i686 2.2-2.17.amzn1 installed
audit-libs.x86_64 2.2-2.17.amzn1 installed
authconfig.x86_64 6.1.12-10.16.amzn1 @amzn-updates
autoconf.noarch 2.63-5.1.7.amzn1 @amzn-main
automake.noarch 1.11.1-2.9.amzn1 @amzn-main
...
----------------------------------------
環境によっては、@ が付いていないマシンもある。うーむ。
----------------------------------------
[ec2-user@yyy ~]$ yum list|grep sqlite
sqlite.x86_64 3.6.20-1.8.amzn1 installed
apr-util-sqlite.x86_64 1.4.1-4.13.amzn1 amzn-main
libdbi-dbd-sqlite.x86_64 0.8.3-5.1.5.amzn1 amzn-main
python-sqlite.x86_64 2.6.0-1.10.amzn1 amzn-main
python24-sqlite.x86_64 2.6.0-1.13.amzn1 amzn-main
sqlite.i686 3.6.20-1.8.amzn1 amzn-main
sqlite-devel.x86_64 3.6.20-1.8.amzn1 amzn-main
sqlite-doc.x86_64 3.6.20-1.8.amzn1 amzn-main
sqlite-tcl.x86_64 3.6.20-1.8.amzn1 amzn-main
----------------------------------------
"yum list @" でググるも有用な情報が得られず、とうか一文字 "@" は検索条件に含まれていないっぽい。
"yum list アットマーク" でググるも、"アットマーク・アイティ" にひっかかる。。。
記号の検索はいつも困る。
http://tech.autodesk.jp/faq/faq/adsk_result_dd.asp?QA_ID=7537 で、
それっぽい記述を見つけたけど、インストールされているかどうかってこと？
インストールされているのは "installed" で表示されるんじゃないの？
----------------------------------------
...
yum list | grep xorg-x11-fonts-ISO8859
フォントパッケージがインストールされている場合、以下のような出力が返されます。
xorg-x11-fonts-ISO8859-1-100dpi.noarch 7.2-12.fc14 @updates
xorg-x11-fonts-ISO8859-1-75dpi.noarch 7.2-12.fc14 @updates
フォントパッケージがインストールされていない場合は、@(アットマーク)が表示されません。
xorg-x11-fonts-ISO8859-1-100dpi.noarch 7.2-12.fc14 updates
xorg-x11-fonts-ISO8859-1-75dpi.noarch 7.2-12.fc14 updates
...
----------------------------------------
そうだ man yum で調べよう。man yum を "@" で検索すると、それっぽい記述にマッチ。
----------------------------------------
install
Is used to install the latest version of a package or group of
packages while ensuring that all dependencies are satisfied.
(See Specifying package names for more information) If no pack-
age matches the given package name(s), they are assumed to be a
shell glob and any matches are then installed. If the name
starts with an @ character the rest of the name is used as
though passed to the groupinstall command. If the name starts
with a - character, then a search is done within the transaction
and any matches are removed. If the name is a file, then install
works like localinstall. If the name doesn’t match a package,
then package "provides" are searched (Eg. "_sqlite-
cache.so()(64bit)") as are filelists (Eg. "/usr/bin/yum"). Also
note that for filelists, wildcards will match multiple packages.
----------------------------------------
英語読めない。。。list じゃなくって install だからあまり関係ないかな。
----------------------------------------
OUTPUT
The format of the output of yum list is:
name.arch [epoch:]version-release repo or @installed-from-repo
----------------------------------------
こっちだね。インストール元のリポジトリ名ってことでいいらしい。
でも、"installed" との違いは何だろう？
日本語だとググるの限界？！英語でググるか。
でも、そもそも「アットマーク」って、英語でなんて言うんだろう。
"アットマーク 英語" でググる。
http://allabout.co.jp/gm/gc/59547/
"at sign" らしい。
"yum list "at sign"" でググる。うーむ、わからん。断念。
ご存じの方教えて下さい。。。
何となく使ってきてしまったシェバングの env の意味について調査。
今のところの理解は以下の通り。
* #!/usr/bin/perl とか #!/bin/perl という書き方ではコマンドのパスが変わったときに
シェバングを書き換える必要があるので env がでてきた。
* 最近は env を使った書き方が主流？！
* でも、env の弊害に対する批判もあるらしい (どっかでみたような...)
"シェバング env" でググる。
いきなり、批判記事ヒット http://ya.maya.st/d/200606c.html#d20060625。
結局、環境変数 PATH や env の場所に依存しちゃうじゃん。ってことかな。
そもそも、shebang はシェバングよりシバンが正しいのかも。
by Wikipedia (http://ja.wikipedia.org/wiki/%E3%82%B7%E3%83%90%E3%83%B3_%28Unix%29)
で、env の元々の役割はというと、
* 環境変数のリストを出力する
* 特定の環境下 (環境変数) で、他のコマンドを実行する
2 番目の使い方を、本来の「環境を変える」使い方ではなく、
「環境を変えない」使い方で、トリック的にコマンドのパスを記述しなくてもよくしているだけ。
で、どうでしょう。
今のところの理解は以下の通り。
* #!/usr/bin/perl とか #!/bin/perl という書き方ではコマンドのパスが変わったときに
シェバングを書き換える必要があるので env がでてきた。
* 最近は env を使った書き方が主流？！
* でも、env の弊害に対する批判もあるらしい (どっかでみたような...)
"シェバング env" でググる。
いきなり、批判記事ヒット http://ya.maya.st/d/200606c.html#d20060625。
結局、環境変数 PATH や env の場所に依存しちゃうじゃん。ってことかな。
そもそも、shebang はシェバングよりシバンが正しいのかも。
by Wikipedia (http://ja.wikipedia.org/wiki/%E3%82%B7%E3%83%90%E3%83%B3_%28Unix%29)
で、env の元々の役割はというと、
* 環境変数のリストを出力する
* 特定の環境下 (環境変数) で、他のコマンドを実行する
2 番目の使い方を、本来の「環境を変える」使い方ではなく、
「環境を変えない」使い方で、トリック的にコマンドのパスを記述しなくてもよくしているだけ。
で、どうでしょう。
- UNIXシェルスクリプトハンドブック (Technical handbook series (.../ソフトバンククリエイティブ
- ￥2,310
- Amazon.co.jp
