|
usen-221x242x135x85.ap-US01.usen.ad.jp (221.242.135.85) の方、 /~68user/net/sample/http-auth/secret.html に 21分間で 25万回アクセスするのは、ぜひともやめていただきたい。 って言っても、どうせ見てないんだろうし、deny したところでおそらく動的に IP アドレスを振ってるだろうし、こういう輩はどうしたらいいんですかねぇ。 |
|
>>4221 68user いや、もう、それは管理部門に連絡するのが良いでしょう。 満足いく内容かどうかはともかく、大抵は何らかの返答はありますよ。 ＃釈迦に説法のような気がしてなりませんが。 |
|
>>4222 へにか なるほど、そういうものですか。usen ならここらへんでしょうか。 http://www.fttx.co.jp/jp/contact/abuse.html ただ、マシンが落ちるなどの実害はなかったことと、usen の web によると 実名を書けだの、仲介しかしないだの、めんどくさそうなので今回は 放置します。 ちなみに「どうしたらいいのか」というのは技術的な解決方法はないですかねぇ、 という意味でした。たとえば一定時間に指定の閾値を超えた IP アドレスは deny するような apache のモジュールがどこかにありそうですよね。 というわけで探したらありました。 http://www.netnice.org/pukiwiki.php?%B4%FB%C2%B8%A4%CEApache%A5%C8%A5%E9%A5%D5%A5%A3%A5%C3%A5%AF%C0%A9%B8%E6%A5%E2%A5%B8%A5%E5%A1%BC%A5%EB まぁほんとにしつこくやってくるようなら usen ごと deny するので 別にいいんですけどね。 |
|
あぁ、技術的な話でしたか。 それに似た話は、某掲示板群で話題になってますね。 http://qb5.2ch.net/operate/kako/1113/11135/1113508190.html http://qb5.2ch.net/test/read.cgi/operate/1113647422/ しつこいクローラー＆過剰リロード対策についての議論です。ご参考までに。 因みに、他の業者に対しては本名を名乗ったことはありません(へにかのまま)。 usenも変な話で、被害をこうむったほうの名前は聞くけど、被害を出したほうの 名前は出さないっていうことですよね？ その辺を突っついてみると、なんらか の回答が出るかもしれません。・・・が、放置されるとの事ですので、補足意見 とさせてください。 |
|
"ネットワークプログラミングの基礎知識"等にある サンプルプログラムのライセンスはどうなっているのでしょうか？ |
|
>>4222 へにか 危ない その輩は server:os-ns01.usen.ad.jp address:61.122.127.122 name:221x242x135x85.ap.221.ftth.ucom.ne.jp address:221.242.135.85 私は server:os-ns01.usen.ad.jp address:61.122.127.122 name:******* address:61.116.228.135 なんですけどサーバーが同じだと危ないのですかね？ |
|
>>4225 mmm 過去ログ読んでから質問した方がいいですよ。 ライセンスについては >>4089 68user にあります。 |
|
すいません、質問させてください。 UNIX上で、ファイルをmac用にstuffit形式に圧縮できるツールを探しているのですが、 ありますでしょうか。 |
|
素人ですが質問させてください。 solaris9 cにて開発しています。 クライアントサーバ間を常駐プロセス１：１（クライアント１、サーバ１プロセス）にて TCP/IPソケット通信しようと考えています。 １接続毎にconnect/closeするのではなく、常にconnectionし続けようと考えています。 そこで、質問ですが、通信中にサーバ側がなんらかの理由により切断された場合、クライアント側は connectからやり直す必要があるのでしょうか？ それともsendを行えば内部的にconnectを行って、sendしてくれるんでしょうか？ 質問が下手ですみません。 |
|
環境はSunOS 5.8です。 ------------------------ #!/bin/csh -fx setenv LANG ja_JP.PCK ・・・ ------------------------ というrootから起動されるshellスクリプトを実行すると （あるバッチ処理管理ソフトを使って起動するとrootから起動されるのです） setenv LANG ja_JP.PCK Locale could not be set properly というエラーになってしまうのですが、何故か分からず困っています。 助けて下さい。 m(＿ ＿)m telnetでuser01でログインしてsetenvを実行すると LANG=ja_JP.PCK となっていますが、上記スクリプトにsetenvを記述すると LANGは表示されません。 スクリプトにsetenv LANG ja_JP.PCKを記述しないと echo チェックリスト作成処理(/disk1/hoge/hoge01/sh/AAA001.csh) 開始 Unmatched ` というエラーになります。 telnetでuser01でログインして実行するとsetenv LANG ja_JP.PCKが なくても正常終了します。 どうぞ宜しくお願い致します。 |
|
>>4226 匿名 > なんですけどサーバーが同じだと危ないのですかね？ う〜ん、僕には力不足で答えられないです。ところで危ないって、どういう局面を想定されていますか？ しかし、その輩、ftth.ucom.ne.jpって、FTTH！ うらやましいなぁ。そんな贅沢な帯域があるんだったら、有効に使ってほしい今日この頃です。 |
|
>>4224 へにか なるほど、そちらも参考にさせていただきます。 >>4226 匿名 > server:os-ns01.usen.ad.jp というのは、あなたが使用している DNS サーバが os-ns01.usen.ad.jp であることを示しているだけです。普通は、どの IP アドレス・FQDN に ついて正引きや逆引きをしても、「server」の部分は変化しません。 >>4228 りゅう シェアウェアっぽいですが、 http://www.stuffit.com/unix/index.html など。あと、 http://www.asl.ee.meisei-u.ac.jp/kaken/stuffit.j.html によると netatalk にも含まれているとか。 >>4229 しず > connectからやり直す必要があるのでしょうか？ コネクションが切れた場合は、connect しなおす必要があります。 >>4230 まつ よくわかりませんが、手元の Solaris8 でも同様の結果になりました。setenv が 呼ばれると、シェルは putenv(3) するだけではなく setlocale(3) あたりも呼ぶ 必要があるような気がしますが、Solaris8 の csh はそこの処理にバグがあるのでは ないかと思います。 csh をやめて sh・tcsh・ksh などに切り替えるか、あるいは #!/bin/sh exec env LANG=ja_JP.PCK 実行したいスクリプト名 というような wrapper スクリプトをかませてはどうでしょうか。 |
|
>>4232 68user 他のサーバー（同じくSunOS5.8だったはずです）では同じように rootから実行できているのです。何かが違うのでしょうね。。 両サーバーのrootの環境を比較するなりしてみます。 ＃サーバー管理者へ依頼する必要があるのですが・・・ 社内の人より下記で逃げられるという指摘もありました が、他サーバーで出来ているので腑に落ちません。 ----------------------------- unsetenv LC_ALL setenv LANG ja_JP.PCK setenv PATH .:$PATH /usr/bin/env set echocmd=/usr/bin/echo $echocmd 'チェックリスト作成処理($0) 開始' ----------------------------- それでも分からなければwrapperスクリプトをかませてみます。 他に何かありましたらご教示下さい。 |
|
>>4233 まつ > が、他サーバーで出来ているので腑に落ちません。 想像ですが、OS インストール時に ja_JP.PCK を選択すると うまく動くのかもしれません。 |
|
>>4233 まつ 問題のあるサーバだけLC_ALLが設定されていませんか？ localeコマンドの結果を比較してみてください。 どちらのサーバでも設定されているのであれば 導入されているロケールパッケージ（？）の差だと思います。 |
|
>>4235 zsh お察しの通り、問題のあるサーバだけLC_ALLが設定されていました！ --動かないサーバー----------- LANG= LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL=JA16SJIS --問題ないサーバー----------- LANG=ja_JP.PCK LC_CTYPE="ja_JP.PCK" LC_NUMERIC="ja_JP.PCK" LC_TIME="ja_JP.PCK" LC_COLLATE="ja_JP.PCK" LC_MONETARY="ja_JP.PCK" LC_MESSAGES="ja_JP.PCK" LC_ALL= ----------------------------- １、rootでLC_ALLが設定されているという事でしょうか？ ２、問題ないサーバーと同じ環境にするには何処を直せば良いのでしょうか？ ３、２がサーバー管理方針などで変更できない場合、C-Shellで unsetenv LC_ALL setenv LANG ja_JP.PCK とすれば良いのでしょうか？ 宜しくお願い致します。 |
|
>>4232 68user >コネクションが切れた場合は、connect しなおす必要があります。 コレクションが切れているか否かの検知ですが、クライアントからsendを 行ったときのタイムアウトを検知したときが一般的でしょうか （むしろこれしかない？） 宜しくお願いします。 |
|
>>4235 zsh 試しに下記を実行してみましたが、元に戻ってしまいました。。 echo内の日本語が文字化け？して「`」になっている為でしょうが 何故未だ日本語が表示できないのでしょうか？ 問題ないサーバーではダブルコーテーションで囲まれてるのに 下記結果では囲まれてないのがダメなのでしょうか？ ---------------------------------------------------- #!/usr/bin/csh -fx locale unsetenv LC_ALL setenv LANG ja_JP.PCK setenv LC_CTYPE ja_JP.PCK setenv LC_NUMERIC ja_JP.PCK setenv LC_TIME ja_JP.PCK setenv LC_COLLATE ja_JP.PCK setenv LC_MONETARY ja_JP.PCK setenv LC_MESSAGES ja_JP.PCK locale echo "ロードエラーチェックリスト作成処理($0) 開始" ---------------------------------------------------- locale LANG= LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL=JA16SJIS unsetenv LC_ALL setenv LANG ja_JP.PCK setenv LC_CTYPE ja_JP.PCK setenv LC_NUMERIC ja_JP.PCK setenv LC_TIME ja_JP.PCK setenv LC_COLLATE ja_JP.PCK setenv LC_MONETARY ja_JP.PCK setenv LC_MESSAGES ja_JP.PCK locale LANG=ja_JP.PCK LC_CTYPE=ja_JP.PCK LC_NUMERIC=ja_JP.PCK LC_TIME=ja_JP.PCK LC_COLLATE=ja_JP.PCK LC_MONETARY=ja_JP.PCK LC_MESSAGES=ja_JP.PCK LC_ALL= echo [hG[`FbNXgャ(/disk18/acua/acua01/sh/FNC07998.csh) Jn 不整合 - ` ---------------------------------------------------- |
|
>>4238 まつ 実験してみましたが、うまくいかないサーバには ja_JP.PCK の ロケールがインストールされていないようです。 >>4232 68user で「csh のバグでは」と言いましたがこれは誤りで、csh だけが 真面目にエラーチェックしているような感じです。 動かないマシン (Solaris8) の /usr/lib/locale/ja_JP.PCK/: LC_MESSAGES/ 動くマシン (Solaris2.6) の /usr/lib/locale/ja_JP.PCK/: LC_CTYPE/ LC_MESSAGES/ LC_TIME/ ja_JP.PCK.so.1 locale_description methods_ja_JP.PCK.so.1 そして ja_JP.PCK ロケールが含まれているマシンであっても、 #!/bin/csh setenv LANG ja_JP.PCK echo "ロードエラーチェックリスト作成処理($0) 開始" このスクリプトは動作しませんでした。おそらく、ja_JP.PCK にした 時点では、既にスクリプトの字句解析は終了しているからだろうと思います。 対策案は 3つ。 案1. - ja_JP.PCK ロケールをインストールする。インストール方法は知りませんが、 以前他のマシンから /usr/lib/locale/ja_JP.PCK/ をぶっこ抜いてきたことが あったっけ。 - さらに wrapper スクリプトを作る 案2. Shift_JIS の「チ」の 2バイト目が ` であることが直接の原因なわけで、 echo 'ロードエラーチェックリスト作成処理('$0') 開始' などと '' で囲んで ` を解釈させないようにする。 案3. 一番いいのは、スクリプトを EUC-JP に変えて、ロケールを混在 させないこと。 あと、 > LC_ALL=JA16SJIS というロケールは存在しないので、おそらく無効なロケール扱いされて いるでしょう。JA16SJIS って Oracle 的なロケール表記ですから。 LANG と LC_* の関係は以下の URL をどうぞ。 http://www.jp.freebsd.org/QandA/HTML/2199.html http://www.jp.freebsd.org/QandA/HTML/2200.html |
|
>>4237 しず send はローカルの mbuf にデータをコピーしたら正常終了と みなすので、エラーになりません。 recv でエラーになるか、次回の send で EPIPE が発生するかの いずれかです。 |
|
>>4239 68user /usr/lib/locale/ja_JP.PCK/:を両サーバーで比較しましたが同じでした。 そして上手く行くサーバーでは #!/bin/csh setenv LANG ja_JP.PCK echo "ロードエラーチェックリスト作成処理($0) 開始" も動作しました。 LANG と LC_* の関係、有り難うございます。勉強になります。 #!/bin/csh -fx locale unsetenv LC_ALL setenv LC_ALL ja_JP.PCK setenv LANG ja_JP.PCK unsetenv LC_ALL locale env として、うまくいくサーバーと同じlocaleに出来ましたがそれでも不整合になります。 env実行結果 --上手く行くサーバー----------------------------------------- HOME=/export/home/adm HZ=100 LANG=ja_JP.PCK LOGNAME=adm MAIL=/var/mail/adm PATH=/opt/oracle/product/8.1.7/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin: PS1=# PWD=/opt/netos/bin SHELL=/bin/csh TERM=vt100 TZ=Japan USER=adm _INIT_NET_STRATEGY=none _INIT_PREV_LEVEL=S _INIT_RUN_LEVEL=3 _INIT_RUN_NPREV=0 _INIT_UTS_ISA=sparc _INIT_UTS_MACHINE=sun4u _INIT_UTS_NODENAME=isv1dm10 _INIT_UTS_PLATFORM=SUNW,Ultra-Enterprise-10000 _INIT_UTS_RELEASE=5.8 _INIT_UTS_SYSNAME=SunOS _INIT_UTS_VERSION=Generic_108528-16 --上手く行かないサーバー----------------------------------------- HOME=/ HZ=100 LOGNAME=root PATH=/usr/sbin:/usr/bin:/opt/EMCpower/bin:/etc:/usr/ccs/bin:/usr/local/bin SHELL=/sbin/sh TERM=vt100 TZ=Japan PWD=/opt/netos5/bin USER=root LANG=ja_JP.PCK ----------------------------------------------------------------- この辺の環境が違うのがダメなのでしょうか？ 案１はja_JP.PCK ロケールはインストールされており上記でLANGの設定も 出来たので、案からは外れたと思います。 案２ですが、echoをダブルコーテーションで囲むのとシングルコーテーションで 囲むのでは解釈が異なるのですね？？ 知りませんでした。。 案３ですが、うまくいくサーバーではShift_JISで動作しているので 腑に落ちません。。envの結果に差があるのが原因でしょうか？？ 文字コードって奥が深いというか複雑というか厄介ですね。。(＾＾; |
|
>>4241 まつ > /usr/lib/locale/ja_JP.PCK/:を両サーバーで比較しましたが同じでした。 そうですか、謎ですね。 > そして上手く行くサーバーでは > #!/bin/csh > setenv LANG ja_JP.PCK > echo "ロードエラーチェックリスト作成処理($0) 開始" > も動作しました。 それは最初から LC_CTYPE が ja_JP.PCK になっているからではないですか? LANG・LC_* を全部クリアして、このスクリプトが動きますか? うちの ja_JP.PCK ロケールがインストールされている Solaris2.6 ではエラーになりました。 > 案３ですが、うまくいくサーバーではShift_JISで動作しているので > 腑に落ちません。。envの結果に差があるのが原因でしょうか？？ ロケールを統一ってのは、例えばログのエンコーディングがばらばら だったりすると grep するにも面倒でしょ、というレベルの話です。 うまくいかないサーバで、 #!/bin/csh -f echo "ロードエラーチェックリスト作成処理($0) 開始" のスクリプトを root で % env LANG=ja_JP.PCK [スクリプト名] とすると動くのですよね? あと、うまくいかないサーバで、 - root で実行するとエラー - user01 で実行するとうまく動く ということですよね? root と user01 のログイン後の env 結果を比較してみてはどうですか? |
|
>>4242 68user 上手く行くサーバーで ---------------- unsetenv LC_ALL unsetenv LANG locale env echo "ロードエラーチェックリスト作成処理($0) 開始" ---------------- としたら ----------------------------------------- LANG= LC_CTYPE="C" ・・・ _INIT_UTS_VERSION=Generic_108528-16 (/data/keisu/ffile/shell/Data_Unqget.sh) ----------------------------------------- となりました。。二バイト文字が無視されている？？ > うまくいかないサーバで、 > #!/bin/csh -f > echo "ロードエラーチェックリスト作成処理($0) 開始" > のスクリプトを root で > % env LANG=ja_JP.PCK [スクリプト名] > とすると動くのですよね? 私にはrootで実行する権限がなく、あるバッチ管理ツール経由で 起動させているのですが、そのツールに env LANG=ja_JP.PCK /disk01/hoge/hoge.csh と記述して起動させると stat: No such file or directory となってしまいました。。 > あと、うまくいかないサーバで、 > - root で実行するとエラー > - user01 で実行するとうまく動く > ということですよね? そうです。 バッチ管理ツールはそのツールプロセスを起動させた時点の 起動したユーザ環境が引き継がれるのですが、rootでその ツールを起動させています。 telnetでuser01でログインして実行すると上手く動くのです。 > root と user01 のログイン後の env 結果を比較してみてはどうですか? 以下のとおりです。 ------------root------------------------------------------------- ＃スクリプトにenvを書いてツールから実行させて吐き出した結果です HOME=/ HZ=100 LOGNAME=root PATH=/usr/sbin:/usr/bin:/opt/EMCpower/bin:/etc:/usr/ccs/bin:/usr/local/bin SHELL=/sbin/sh TERM=vt100 TZ=Japan PWD=/opt/netos5/bin USER=root LANG=ja_JP.PCK ------------user01------------------------------------------------- HOME=/export/home/user01 PATH=/opt/ora8i/app/oracle/product/8.1.7/bin:/usr/bin:/usr/ccs/bin:/usr/ucb:/bin:/usr/bin:/usr/ucb: /etc:. LOGNAME=user01 HZ=100 TERM=vt100 TZ=Japan SHELL=/bin/csh MAIL=/var/mail/user01 LANG=ja_JP.PCK _INIT_NET_STRATEGY=none _INIT_PREV_LEVEL=S _INIT_RUN_LEVEL=3 _INIT_RUN_NPREV=0 _INIT_UTS_ISA=sparc _INIT_UTS_MACHINE=sun4u _INIT_UTS_NODENAME=atras01 _INIT_UTS_PLATFORM=SUNW,Sun-Fire-480R _INIT_UTS_RELEASE=5.8 _INIT_UTS_SYSNAME=SunOS _INIT_UTS_VERSION=Generic_108528-22 PWD=/export/home/user01 USER=user02 ORACLE_BASE=/opt/ora8i/app/oracle ORACLE_HOME=/opt/ora8i/app/oracle/product/8.1.7 ORACLE_SID=SID_A NLS_LANG=Japanese_Japan.JA16SJIS ORA_NLS33=/opt/ora8i/app/oracle/product/8.1.7/ocommon/nls/admin/data LD_LIBRARY_PATH=/opt/ora8i/app/oracle/product/8.1.7/lib ----------------------------------------------------------------- 何が悪いのか分かりますか？？ |
|
>>4243 まつ わたしが言いたいのは - スクリプトの先頭で LANG を設定しても、既に字句解析は 終了しているのだから意味がないのでは。 - うまく動く環境では、元々 ja_JP.PCK が設定されていただけでは。 ということです。 > stat: No such file or directory これは別問題ですよね。 #!/bin/csh -f echo "チェック" が動くかどうかを確認すべきです。 |
|
あと、 Locale could not be set properly についてはわかりません。 こちらの環境では、ja_JP.PCK ロケールがない場合のみ このエラーが出て、ロケールがある環境ではうまく動きました。 |
|
>>4243 まつ メッセージの意味としては、選択されたロケールが使用できない状態（つまりインストールされていない） である事を示しています。 恐らく今の状態は 1./etc/profile か /.profileで LC_ALL を設定している。（且つ間違い） 2.当然 root から生成された子プロセスにも LC_ALL が設定されている（且つ間違い） 3.LANG を変更する際に（ LC_ALL が空ではないので） LC_ALL のロケールについても チェックされる →存在しないロケールなので「Locale could not be set properly」を出力 （ただし LANG は変更されている筈） だと思います。 一般ユーザで動作するのであれば、PCK ロケールはインストールされているので 文字化けの原因は、親プロセスの環境変数の違いによるのかも知れません。つまり >>4244 68user ではないかと。 （確認するためには wrapper スクリプトかますのが簡単だと思います。） |
|
>>4246 zsh > 3.LANG を変更する際に（ LC_ALL が空ではないので） LC_ALL のロケールに > ついてもチェックされる なるほど、それは気がつきませんでした。 ja_JP.PCK ロケールがインストールされている Solaris2.6 で、LC_ALL に JA16SJIS をセットして、さらに LANG に ja_JP.PCK をセットすると、 Locale could not be set properly となりました。 |
|
68user様、zsh様、返事が遅くなり大変申し訳ございません。m(_ _)m >>4246 zsh とてもよく分かりました。 .profileは / にも /etc にもありませんでしたが、子プロセス起動時に 間違ったLC_ALLを設定しているのが原因なのですね。 子プロセスを再起動すれば解決するのでしょうね。 開発依頼者へお願いしても中々動いてくれません・・(T^T) なので、このスクリプトのみをEUC-JPに変えてunsetenv LC_ALLしたところ 正常に実行できました。 ということで、wrapperスクリプトをかまして確認してませんが、お二人の 仰ることに間違いはないですから、その旨開発依頼者へ報告しておきます。 色々有り難うございました。助かりました。m(_ _)m これで心置きなくお盆休みに入れます（＾＾） |
|
スクリプトをシフトJISへ戻してwrapperスクリプトをかませて テストしてみました。 -----wrapper.sh------------------ #!/bin/sh -fx exec env LANG=ja_JP.PCK /disk01/hoge/hoge01/sh/FNC0123.csh -----FNC0123.csh------------------ #!/usr/bin/csh unsetenv LC_ALL ・・・ -----ツールから実行した結果------------------ couldn't set locale correctly + exec env LANG=ja_JP.PCK /disk01/hoge/hoge01/sh/FNC0123.csh ・・・ ----------------------- のように最初に変なメッセージが表示されますが、それ以降は 文字化けもなく理想どおりの結果が得られました。 最初の変なメッセージは間違ったLC_ALLを設定している為でしょうか？ 何はともあれ、これで子プロセスを再起動してもしなくても正常に 動作しそうです。 どうも有り難う御座いました。ｍ（．＿．）ｍ |
|
たわむれに Ajax で遊んでみました。RFC のタイトルから検索を行います。 http://X68000.q-e-d.net/~68user/rfc/ 以下のような URL も有効です。 http://X68000.q-e-d.net/~68user/rfc/?key=821 http://X68000.q-e-d.net/~68user/rfc/?key=http XMLHttpRequest をひとつしか生成しないタイプではなく、ばしばし XMLHttpRequest を 作る、富豪版です (google タイプ)。ソースはこちら。 http://X68000.q-e-d.net/~68user/cgi-bin/cvsweb.cgi/public_html/rfc/ >>4294 hagu > 最初の変なメッセージは間違ったLC_ALLを設定している為でしょうか？ unsetenv LC_ALL には意味がないので、 env LC_ALL= LANG=ja_JP.PCK ... とすれば直ると思います。 |
|
findコマンドでファイルが今日（本日）作成されたものだけを 抽出したいのですが、以下でよいのでしょうか； find . -name '*.*' -mtime -1 -print 他に別の方法がありますか。 |
|
>>4251 みのさん ・ファイル名で絞り込まないのであれば -name オプションは不要です。 ・-mtime -1 では「本日作成」ではなく、「24時間以内に変更」されたものが対象となります。 （作成日をみるようなオプションは無いと思います。） ・-print オプションは無くても出力されます。 ・ファイルに限定したいのであれば -type f が必要です。 こんなもんでしょうか。 |
|
>>4251 みのさん 追加。 - 一般的な UNIX のタイムスタンプには、厳密な意味でのファイル作成時刻は 存在しない。ctime は、例えばパーミッションを変更すると更新される。 - 「24時間以内」ではなく「本日」にしたいなら、適当なファイルを 作って、touch で mtime を前日 23:59:59 にして、 find -newer [適当なファイル] とするのが一般的。しかし手抜きするなら以下のような方法も。 % find . -type f -ls | grep "`date '+%b %d'`" >>4252 zsh BSD や GNU の find には -ctime オプションがあります。-cnewer ってのも あるようですね (基準ファイルの mtime と検索対象の ctime を比較)。 今日の発見その 1 touch(1) などが使うシステムコール utimes(2) って、ctime を更新できない んですねぇ。atime・ctime・mtime いずれも変更可能だとずっと思っていました。 今日の発見その 2 FreeBSD 5.x 以降で対応された UFS2 では本当の生成時刻 (inode 作成時刻) が 保存されていて、struct stat の st_birthtime で参照可能なようです。へぇ。 http://www.usenix.org/events/bsdcon03/tech/full_papers/mckusick/mckusick_html/ http://www.jp.freebsd.org/cgi/mroff.cgi?subdir=man&lc=1&cmd=&man=stat&dir=jpman-5.2.0%2Fman§=2 |
|
>>4250 68user RFC のタイトルだけでなく、全文検索もできるようにしました (namazu を使っているので Ajax には向かないですが)。 http://X68000.q-e-d.net/~68user/rfc/ 結構使えるかも、と思うのはわたしだけですかそうですか。 |
|
>>4254 68user JavaScript必須というのが、いきなり敷居が高いと申しますか、何と申しますか・・・ 今みたいに、帰省先でpoorな環境で使っていると、その時点で引いてしまっております。 >>4250 68user ここでポイントしている>>4294が、4294まで投稿が伸びたときに、どうなるか、気になるところです。 |