Perlについて

2008/08/04(月) 20:58:41
質問スレはあるけど、Perl自身について語るスレがないので、立てました。
2011/10/02(日) 20:59:47.99
上位互換性があると過去のバージョンとの差別化が難しいから、
キャッチコピーが使えなくなってしまうので困るってことなの
かい？
2011/10/02(日) 21:05:29.13
>>488
> disってるつもりじゃなくてな、どうしてEncodeはJcodeのインタ
> フェースをそのまま使わなかったのか素朴な疑問なんだよ。
おまｗ アホか、もしかしてJcode知らんのか？

Jcodeのインターフェースって、jcode($str)->sjisとか ->euc とか ->iso_2022_jpだぞ
お前、そんなんで世界各国の文字コード全てサポートする気かよ。

それにEncodeとかJcodeではなくてな、Perlのコアの文字コードは、
UTF8フラグが付いたUTF8文字と決まってる。
これがPerlが理解している文字。Perlが文字と理解しているものに対して
lengthしたら、（バイト数ではなく）文字数が返ってくるし、
正規表現でちゃんと一文字として扱える。

JcodeはPerlが文字と解釈してないものを返すので
あるべき姿のPerlの使い方に適合していない。
2011/10/02(日) 21:08:50.66
>>489
JcodeはJなのに世界中の
文字コードサポートするんの？

Encodeいいじゃん。なんのメリットがあるのさｗ
2011/10/02(日) 21:13:17.84
まず上半分。

>Jcodeのインターフェースって、jcode($str)->sjisとか ->euc とか ->iso_2022_jpだぞ
>お前、そんなんで世界各国の文字コード全てサポートする気かよ。

Encodeだと引数、Jcodeだとメソッドっていうだけだと思うんだけど。
この違いで何か致命的にまずいことってあるの？
2011/10/02(日) 21:15:05.96
>>492
そこは分かってるからあえてツッコまないよーに。J
2011/10/02(日) 21:16:20.70
え？Ｊはじぇんぶ(全部)のＪだろ？
2011/10/02(日) 21:23:03.32
下半分。

>それにEncodeとかJcodeではなくてな、Perlのコアの文字コードは、
>UTF8フラグが付いたUTF8文字と決まってる。

例えば (仮称)Jcode3.x にメソッドを追加して、UTF8フラグが付い
たUTF8文字を扱うのはだめなのかい？
2011/10/02(日) 21:33:15.96
>>493
文字コードを変数に入れるような場合に見にくくなる。 $j->$encode

エンコード名が間違っていてもエンコード名が間違っていますのような適切なエラーが出せない。（関数がないと言われる）

エンコード名にハイフンが使えない。

ISO-2022-JP、ISO-2022-JP-2、ISO-2022-JP-3のように、
頭がISO-2022-JPで始まるものを、すべて扱うエンコーダー（Encode::JP等）が
作りづらくなる。

エンコード名に大文字小文字を無視するように作るのが面倒

Encode::from_toのように、変数の値を、”あれ”から”これ”に変換するとき
文字コードを値で渡す方がシンプル。使い方は統一すべきだ。
2011/10/02(日) 21:34:30.49
>>496
Jcodeとは違う使い方をするのであれば、
Encodeでよい。
2011/10/02(日) 21:44:33.79
違う使い方にちょっとずつ移行できるところが利点。
2011/10/02(日) 21:48:11.88
>>499
Jcode3.0に移行してなんのメリットがあるの？
Encodeに移行してないじゃんｗ
2011/10/02(日) 21:49:03.46
Jcode.pmの中身読んで、
- 後方互換のためにどれだけ苦心してるか
- どれだけ、速度を犠牲にしてるか
見りゃいいんだよ。

議論自体吹っ飛ぶぞ
2011/10/02(日) 21:51:19.58
あ、たられば論の思考実験な。
2011/10/02(日) 21:54:30.95
じゃあEncodeはどうやってその問題を解決してるんだ？
Encodeの作りをJcodeのインタフェースで提供するって話だぞ。

それとこれからやるかって話じゃなくて思考実験な。
2011/10/02(日) 21:59:20.27
>その問題
？どの問題？
2011/10/02(日) 22:01:49.32
>>503
問題を解決するために頑張ってるのはJcodeだろｗ
Perl標準の文字にあわせて作られたEncodeは凄くシンプルだ。

Perlの文字（UTF8フラグ関係）を理解できる
脳みそ程度があれば良い。
2011/10/02(日) 22:03:40.98
>>503
もしかして、JcodeはEncodeのラッパーって知らないの？

EncodeのラッパーのJcodeで、Encodeを作るって
無意味だよね？
2011/10/02(日) 22:06:45.35
>>504,505

Jcodeでは

> - 後方互換のためにどれだけ苦心してるか
> - どれだけ、速度を犠牲にしてるか

に苦労しているって読めたが、

> Perl標準の文字にあわせて作られたEncodeは凄くシンプルだ。

なわけで、その実装を使ってJcodeのインタフェースを提供する
ってことだよ。
2011/10/02(日) 22:08:25.67
> なわけで、その実装を使ってJcodeのインタフェースを提供する
> ってことだよ。

やっぱりお前Jcode知らんのか。

今のJcodeはEncodeの実装を使って作られたものだ。
2011/10/02(日) 22:09:18.20
もちろんJcodeのインターフェースであるがゆえに、
日本語にしか対応できなくなっている。

Encodeの劣化版がJcode
2011/10/02(日) 22:11:50.54
>>506,508
知ってるってば。おれ470な。
2011/10/02(日) 22:13:44.34
そして、Jcodeに新たにメソッド増やしてEncodeと
同じ事を出来るようにするぐらいなら、
普通にEncodeを使えばいい。

新しいメソッドを使う以上、使い方は全く代わるわけで
なら標準のEncodeを使えばいいからだ。
2011/10/02(日) 22:14:49.67
移行するのであれば、Jcodeを使いながら
Encodeを導入し、徐々にEncodeを使った方法に
置き換えていけば良い。

Jcode3.0なんてものを作った所で
Encodeには移行できない。
2011/10/02(日) 22:19:00.72
>>511
それは現実の世界な。

503: これからやるかって話じゃなくて思考実験な。
2011/10/02(日) 22:19:16.07
EncodeというかPerl開発者が推奨している
標準の文字の扱い方だな。

PerlがUnicode対応した時から
どのように文字を使うべきかが決まった。

外部からの出入り口で、内部文字コードに変換して
Perlコードからは文字はすべてUTF8フラグ付きのUTF8文字コードで
として扱う。それがPerl開発者が決めたルールだ。

2011/10/02(日) 22:22:38.39
>>513
思考実験って言葉の使い方間違ってるぞｗ

現実を否定するのが、思考実験ではない。
2011/10/02(日) 22:24:36.48
仕様と実装を分けて考えればいいんじゃないかと言ってる
訳なんだけど、どうしても切り離せないような話が返って
くるなあ。
2011/10/02(日) 22:24:51.08
思考実験ってｗｗｗ

単に考えるだけで作らないって言ってるだけやんｗ
2011/10/02(日) 22:26:42.93
>>517
そのとおり。なので暇なひとだけレスして欲しい。
2011/10/02(日) 22:27:46.67
>>516
なら答えは簡単だ。

機能の多いもの（全世界対応）から
機能の少ないもの（日本語専用）は作れるが、

機能の少ないもの（日本語専用）から
機能の多いもの（全世界対応）は作れない。

ならEncodeモジュールを基本とし、
Jcodeはそのラッパーという仕様が一番良い。
520488
垢版 |
2011/10/02(日) 22:35:29.35
>>disってるつもりじゃなくてな、どうしてEncodeはJcodeのインタ
>>フェースをそのまま使わなかったのか素朴な疑問なんだよ。

なんか、488の回答の下地がようやく整ってきた感じがする。

>>519
その話の続きを聞かせて欲しい。
2011/10/02(日) 22:37:34.33
>>520
>488の回答であり続き。

おまｗ アホか、もしかしてJcode知らんのか？

Jcodeのインターフェースって、jcode($str)->sjisとか ->euc とか ->iso_2022_jpだぞ
お前、そんなんで世界各国の文字コード全てサポートする気かよ。

それにEncodeとかJcodeではなくてな、Perlのコアの文字コードは、
UTF8フラグが付いたUTF8文字と決まってる。
これがPerlが理解している文字。Perlが文字と理解しているものに対して
lengthしたら、（バイト数ではなく）文字数が返ってくるし、
正規表現でちゃんと一文字として扱える。

JcodeはPerlが文字と解釈してないものを返すので
あるべき姿のPerlの使い方に適合していない。
2011/10/02(日) 22:41:37.51
おれとしては521よりも519のほうが知りたかったことに近い。

うまく聞き出せなかったけど。
2011/10/02(日) 22:43:33.28
つか、JcodeがEncodeのラッパーになっている理由なんて
初心者プログラマでないなら、自然と理解できるはずなんだがｗ

逆にJcodeのインターフェースのままにしようなんて
思う奴はいないだろ。
2011/10/02(日) 22:50:03.72
519の話の続きにはとても価値があると思っている。でもそれは521
なんかじゃない。うまく質問ができるようになったら、教えて欲しい。
2011/10/02(日) 22:53:12.08
>>524
と言われてもどっちの書き込みも俺だし
>>519の続きは>>491以外のの答えなんて無いよｗ
2011/10/03(月) 01:43:37.06
おまえら熱いな
2011/10/03(月) 23:08:10.52
JcodeやEncodeを作るときに参考にした座右の銘、例えばTMTOWTDI
だとか名前重要だとかに相当するものってあるの？

オリジナルのものを作るときにはオリジナルの座右の銘があるん
じゃないかって思ってるわけで、それを知りたい。

521の情報は既知なので回答としてうれしくない。
2011/10/04(火) 01:37:52.77
>>527
> オリジナルのものを作るときにはオリジナルの座右の銘があるん
> じゃないかって思ってるわけで

何故？
2011/10/04(火) 06:35:59.00
そもそもJcodeはオリジナルじゃねーし
2011/10/04(火) 06:59:36.13
jcode.pl
- perlでnkfみたいな事したいよね
Jocde0.X
- perl4 は古い
- OOP したいよね（jcode.plの雰囲気は残した形で）
Encode.pm
- （日本語だけじゃなく）世界で使えるのって必要じゃね？
- jcode.plに何の義理もないし、インターフェースもこの際、考えなおさね？
Jcode2.X
- Encodeがあるし役目終ってると思うんだけど…
- ラッパにしたよ
jacode.pl
- 弾嫌い。
2011/10/04(火) 07:19:44.39
あ、jacode.plの方が先だ。適当に書くもんじゃない
2011/10/05(水) 23:30:33.31
そんなこといったら、jcode.plだってPerlだってもしかしたら
UNIXも、C言語もオリジナルではない。
ただ単に前世代をコピーし損ねることで、進化しただけだ。

まったくのオリジナルというこの世界と関わりのないような
ものはありえない。
2011/10/05(水) 23:40:27.53
まったくのオリジナル←おまいは何をコピーしてできたんだ？
2011/10/05(水) 23:50:45.55
>>530
互換性はあまり大事なものではない、と読み取れるんだけど、
いつの日かEncodeを自分の手でなくすときがくるのかい？

そのときは(例によって)全力で反対するからな。
2011/10/06(木) 06:15:40.07
EncodeとJcodeの互換性？
重要な訳無いじゃん。別の物なんだから。
EncodeとEncodeの後継の互換性？
（あればの話だが）重要に決まってるじゃん。

但し、Perl6のE
2011/10/06(木) 19:18:09.21
そもそも 6 がｗ
2011/10/06(木) 20:06:06.34
>>535
今のJcodeはEncodeの機能限定版
2011/10/06(木) 20:30:38.65
ラッパと機能限定版を混同するなよ
2011/10/06(木) 21:04:14.27
warpperの末尾の音引きを取ると楽器になっちゃうのを発見。今更だけど。
2011/10/07(金) 02:04:02.33
機能限定によってUTF8フラグがないのがうれしい。
さらにメソッド方式は失敗で引数方式に回帰なら
jacode.pl 最強？
2011/10/07(金) 03:49:31.51
UTF8フラグがないことを
喜ぶのがよくわからん。

馬鹿だから理解出来ないのか？
普通に考えて、文字数数えるときとか面倒だろ。
2011/10/07(金) 08:28:29.98
１回関数作っちゃえばカウント出来ますやん
2011/10/07(金) 08:39:06.76
まだEncodeを使っていないジジイがいるのか
2011/10/07(金) 09:25:24.34
てかこのスレの住人だってcpanmとかperlbrew使ってるの5人もいないだろ
2011/10/07(金) 23:50:23.05
>>544
知らなかったけど、知った今でもそれらは使わないよ。

cpanm ・・・ cpanみたいにモジュールをインストールする奴
perlbrew・・・Perのバージョンを切り替える奴

ざっと見た感じこういうものだと思うけど、
俺にかぎらず、ウェブアプリを作っている会社なら安定性重視だから
Perlを単体で入れることはまず無い。ディストリ標準のを使うだろう。
逆にどうしても特定のバージョンが仕えたいのなら、それに合わせてディストリを選ぶとかね。

Perlモジュールもディストリ標準のと言いたいところだけどそれじゃ足りない場合も多いね。
そういう場合は、パッケージを作ってインストールはもちろんアンインストールも簡単にできるようにするんじゃない？

うちはdebianを使ってるけどdh-make-perlを使ってcpanモジュールからdebianパッケージを作っている。一行で簡単に作れるし。
どこになにが入るのか把握しづらいcpan（cpanm）は使わない。

cpanmやperlbrewはフリー・シェアウェアのCGIアプリを作っているというのなら便利なんだろうけど、
そんなのプロならあまり使わないだろうし、ぶっちゃけ、その名前を出した時点で
あぁ、あんたは自社サーバーでシステムを動かしてサービス提供している側じゃないんだねと思った。
2011/10/07(金) 23:54:31.16
うわぁ
2011/10/07(金) 23:59:38.41
>>546
何か言い返したほうがいいぞｗ
2011/10/08(土) 00:04:01.85
cpanmはインストールしたけど、ほとんど使ってない。
perlbrewは使ってない。
local::libは使ってる。無いと死ねる。
2011/10/08(土) 08:38:09.06
うちはcpanmは使ってるな。リソース少なめの非力マシンなんで。
cpanと併用だけど。
2011/10/08(土) 13:46:20.74
>>530
オリジナルじゃないし座右の銘でもないな。
しかも最後、万人の感情論まで入っているぞw
2011/10/10(月) 00:10:54.13
cpanmやperlbrewの作者たちは僕の中でプロと思える存在だったんだけど世の中には兵がたくさんいるんだな
2011/10/10(月) 01:22:29.43
> cpanmやperlbrewの作者たちは僕の中でプロと思える存在だったんだけど
え？

cpanmやperlbrewが無益なものだとは言わないけど、
自分で好きなサーバーを選べないrootも持ってないそういう
ニッチな需要に対応するもので、
プロの間では使うことはまずない道具だろ。

技術的には、ネットからダウンロードして
パッケージに付いてるコマンド実行するのと
パスとディレクトリ変更するだけのものだし。

2011/10/10(月) 01:40:11.10
プロハープロハー
2011/10/10(月) 02:29:19.58
>>551
別にcpanmやperlbrewやその作者をdisっている訳ではなくて、
必要があれば使うしなければ使わないってだけの話でしょ。
すごいプロダクトならとにかく使わなきゃいけないって考えは変だろ。
>>552
> プロの間では使うことはまずない道具だろ。
んなこたあない。お前の「プロ」定義、歪んでるぞ。ものすごくシロウト臭い。
2011/10/10(月) 06:01:08.40
そもそも
> 自分で好きなサーバーを選べないrootも持ってないそういう
> ニッチな需要に対応するもので、
ここの認識から違う。
どっかの記事みてそう思っちゃったんだろうけど
2011/10/10(月) 06:46:36.59
>>555
なにが違うん？

普通にインストールすればいいだけじゃん。
2011/10/10(月) 07:58:34.12
>> 自分で好きなサーバーを選べないrootも持ってないそういう
>> ニッチな需要に対応するもので、
>ここの認識から違う。
1. cpanmは、コマンドcpanの代替であって、上記のニッチもへったくれも
　無いだろ。local::lib使えばroot云々無関係だし。perlbrewと切り分けろよ
2. 自分で鯖を選べてrootも持ってるが、perlの他バージョンの挙動を調べたい。
　冷やかしのガキを除けば、そっちの用途の方が多いだろ、perlbrewは。
3. perlbrew及び、それでインストールされるperlは、
　必ずしも$HOMEにインストールしなければならない物ではない。
　/usr/local以下に突っ込んで運用出来る

さて、どの意図でレスされたんだろう？それとも上述以外？


545氏に突っ込むのは徒労だと思うが、そもそも
>>544
> てかこのスレの住人だってcpanmとかperlbrew使ってるの5人もいないだろ
Encodeの使用者も少ないって言いたいなら、例が悪すぎる
core moduleと比較すんのにCPAN moduleを例に出すなよw
需要も重要度も全く次元が違う
おまけにJcode.pmの使用者は間接的にEncodeの使用者だ
2011/10/10(月) 13:42:54.40
>>557
cpanm（cpan）はアンインストールできないので
パッケージを作ったほうが優れている。

また他のperlのバージョンの挙動を調べたいのなら仮想マシン使う。
そんな環境がごちゃごちゃするようなやり方はしない。
2011/10/10(月) 13:51:15.34
プロ様お疲れ様っす！
2011/10/10(月) 14:31:27.78
>>558
> cpanm（cpan）はアンインストールできないので
ん? できるでしょ? ちょっと手間はかかるけど。
インストール時にパッケージ作る手間とどっちを取るか、って感じ?
2011/10/10(月) 14:46:10.85
パッケージを作るのは1行〜数行で終わる。

cpanのアンインストールは、モジュールによって
やり方が違い、make uninstallを備えていないのも多い。
2011/10/10(月) 15:35:57.38
そうか。
まあ基本的にアンインストールしないから関係ないや。
Perlのモジュールなんてインストールされてて困ったなんてことないしなあ。
2011/10/10(月) 16:34:22.42
>>562
そこがプロとアマの違いね。
今どのモジュールがどうやってはいったか把握してないでしょ？

アマなら動いていればいいじゃんで終わるんだろうけど、プロだとちゃんと環境を把握している。
（覚えているのではなく簡単に調べられるということ）
環境を把握しているから、なにかトラブルが起きた時その原因の切り分けが簡単にできる。

cpanモジュールをパッケージにしていれば、パッケージのバージョンアップで
なにか動作がおかしくなった時、今のバージョンを完全に綺麗な状態に消して古いバージョンを入れられる。

もしそうなっていなければ、今モジュール入っているんだっけ？ 全部ちゃんと消したっけ？
あれ？ なんか古いモジュールと新しいモジュールがごっちゃになってる。
インストールが途中でエラー終了したんだけど、今どういう状態になってるんだ？みたいな混乱が起きることになる。
2011/10/10(月) 16:43:47.58
データ解析系の人間からすれば、
debianでアプリ開発して移植先がSolarisだったらどうすんの？とか、
仕様書に「野良パッケージが便利だからdh-make-perl入れます」と書くのか？とか。
もうね、、、

その上で、自分はプロ！だからなあ。
2011/10/10(月) 16:45:08.96
ああ、「実際の運用時にはcpan使うだろJK」か。
2011/10/10(月) 17:08:01.67
納品先の鯖の保守契約自体は、他の会社（例えば、HPだの）にあった場合に、
そちらに依頼してモジュールのインストールしてもらわなきゃならない、
もしくは仕様書を渡してこちらでインストールなりをする。
鯖のrootにはそれだけの重みと柵がある、例えweb鯖でも。
それのに、気軽にプロなら、とか言ってくれるなよ。
どれだけ軽いrootだよ、お前様の鯖は。

perlbrewもcpanmもどうでも良くて、あんまりのレスについ書いちまった。
2011/10/10(月) 17:11:08.43
>>563
いやいや、むしろ"プロ"ならcpanで入れた分だってちょっと調べりゃ綺麗にアンインストールできるでしょ。
make uninstall なんか使えなくってもさ。
パッケージ作るかどうかなんてのは好みだから別に好きにすればいいと思うけど、
基本的にはアンインストールが必要になることなんて滅多にない場合は、
必要が生じた時だけちょっと手をかけてアンインストールすることにして、
インストール自体はcpanで済ませても問題ないじゃない。時間の節約にもなる訳だし。

まあ別に"プロ"じゃないけどね。あ、昔仕事でスクリプト書いたことはあったんでその時だけは"プロ"だったか。
2011/10/10(月) 17:43:24.97
> ちょっと調べりゃ

はい、その調べる手間が無駄です。
2011/10/10(月) 17:56:21.01
>>564
> 仕様書に「野良パッケージが便利だからdh-make-perl入れます」と書くのか？とか。
「野良パッケージが便利だからcpanで入れます」と書くのか？
お前の意見はどっちなんだ？ 野良パッケージのインストールをするなってことなのか？
それはそれで有りだと思うよ。だが今の話とは関係ない。

今は野良パッケージを入れることが前提の話。
野良パッケージを入れる場合、cpanで入れてOSの安定性ぶち壊すのか、
それともパッケージにして管理された状態でモジュールを使うのか。
どっちが優れてるかなんて言うまでもない。
SolarisならSolarisのやり方でパッケージ管理するだけの話。


>>556
お前のほうが軽くね？
だって、モジュールのインストールは他の会社に頼む。
うちはモジュールのインストールはしない。そう言ってるわけでしょ？

つまり、お前の場合は、モジュールのインストールしない側の話であって
今話してるのは、モジュールインストールする側の話だよ。

わかりやすく言えば、root持ってないお前が頼むのがroot持ってる俺の会社ってわけだ。
モジュールのインストールという責任あることをcpan使って気軽にやるかよｗ

ちゃんとパッケージ作ってちゃんと管理する。これはディストリがやってるのと同じ方法だ。
なぜディストリはパッケージを使っているかその理由ぐらい分かるだろう。
2011/10/10(月) 18:05:05.09
厚顔無知
2011/10/10(月) 18:50:17.18
>>569
> 今は野良パッケージを入れることが前提の話。
えっ？いつからそんな前提の話に変わってたの？

> 野良パッケージを入れる場合、cpanで入れてOSの安定性ぶち壊すのか、
えっ？cpanで入れるとOSの安定性がぶち壊れるの？
コワ〜イ（＞＜）
2011/10/10(月) 18:55:09.29
この手の「なにがなんでも自分が最後に勝ちたい」“プロ”とは絶対一緒に仕事したくないってことだけは確かだなｗ
2011/10/10(月) 19:04:11.84
>>571
> えっ？いつからそんな前提の話に変わってたの？

元は、cpanm使う　→　そんなの使わねーよ、パッケージ作れよ。が発端。

ちゃんとスレ読んでから出直し。
2011/10/10(月) 19:06:51.87
>>571
> えっ？cpanで入れるとOSの安定性がぶち壊れるの？
そうだよ。

cpanで入れるとモジュールの整合性がおかしくなる。
モジュールをパッケージで入れた（ディストリがパッケージで提供してる奴）
同じモジュールをcpanで入れた。さてどうなるか。
削除するとき、本当にちゃんと削除できたか、何かが残っていて
予期せぬことが起きる可能性だってある。
2011/10/10(月) 19:23:10.53
モジュールをパッケージで入れないから問題ない。
2011/10/10(月) 19:25:59.06
そういうときこそlocal::libだな
2011/10/10(月) 19:34:20.56
入れないじゃなくて、
入れられないの間違いでしょｗ
自分専用のマシン用意してもらえないとかで。
2011/10/10(月) 20:33:05.15
パッケージ管理の方こそ信用ならん。
インストールは全部makeで、Perlのモジュールはcpan。
2011/10/10(月) 20:41:09.84
>>570
なんで信用ならんの？
2011/10/10(月) 21:16:17.19
debianの場合だと
往々にして妙にバージョンが古くて
それがトラブルの元になったりするから
とか?
2011/10/10(月) 21:34:07.52
それはパッケージの問題じゃねーよｗ
2011/10/16(日) 21:52:24.92
プロでもアマでもインストールは手動で行ってこそ、把握や管理が楽になる
2011/10/16(日) 22:18:05.00
Encodeの使用者って少ないって本当？
ネットにも本にも紹介されてるんだけど、実際に現場で使われてる
のは確かに見たことないんだよね。
2011/10/16(日) 23:23:37.06
「プロ」の次は「現場」ｋｔｋｒ

じゃあ現場でEncodeの代わりに何使ってるんだよｗ
2011/10/17(月) 00:25:08.22
変換しないから何も使ってないｋｔｋｒ
2011/10/17(月) 03:28:14.22
文字コードが混在してるわけじゃないので使用してませんが？
2011/10/17(月) 04:57:36.37
それは
Encodeの使用者が少ない
んじゃなくて
Encodeが必要になるような局面が少ない
っていうことか。
それならわかる。
2011/10/18(火) 05:02:53.39
有用か無用の判断はともかく、ファイルハンドルからファイル名って取得出来ないのかしら？
Devel::Peek::Dump($filehandle) みたいに渡すとファイル名が表示されるから、ファイルハンドルから
ファイル名が取れるはずなんだけど Devel::Peek を読んでもまったく意味が分からないｗ

ファイルハンドルからファイル名を取得する方法またはサンプルとか知ってるからいらっしゃいますか？
589デフォルトの名無しさん
垢版 |
2011/10/18(火) 06:33:09.89
自分の環境（Win7 64bit、ActivePerl5.8）ではファイル名が出ませんが、出力例を貼っていただけます？
SV = RV(0x30ea08) at 0x3621bb8
REFCNT = 1
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x26b548
SV = PVGV(0x36a0e38) at 0x26b548
REFCNT = 1
FLAGS = (GMG,SMG)
IV = 0
NV = 0
PV = 0
MAGIC = 0x2c6b68
MG_VIRTUAL = &PL_vtbl_glob
MG_TYPE = PERL_MAGIC_glob(*)
MG_OBJ = 0x26b548
NAME = "$filehandle"
NAMELEN = 11
GvSTASH = 0x26b428 "main"
GP = 0x36e33b8
SV = 0x26b638
REFCNT = 1
IO = 0x26b688
FORM = 0x0
AV = 0x0
HV = 0x0
CV = 0x0
CVGEN = 0x0
GPFLAGS = 0x0
LINE = 3
FILE = "a.pl"
FLAGS = 0x0
EGV = 0x26b548 "$filehandle"
新着レスの表示
レスを投稿する

5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。