新着記事

− 野ざらし言 −

新規投稿は記事一覧のフォームからお願いします

[5297] Re^3: 一括リネームのテストと限界,結論

konno 2023/01/25(Wed) 00:05
[関連記事] [5295]へのコメント
> > これ、実行環境は VTDOS ですよね。
>
> そうです。どうやら,VTDOS 環境がどっぷり16ビットDOS のそれではないらしく,そのお陰で従来版ファインクションコール AH=56h で出力結果がロングになっても,通してくれることがわかりました。自分としてはこの辺りで満足です。一番時間のかかる連番付けさえ一瞬なら,あとは xyzzy ファイラでなんとでもなりますから。

REN だけでなくマクロでも使えるというのは発見ですね。
DOSエミュの環境はいこごちがいいわけです。

> > 試してみたら、最近の DOSエミュ3種は、同じようにロング変換できました。
>
> ここの「試し」は,マクロ? バッチのREN ?

単独の REN です。
ファンクションコールは当然対応していると思いますし。

そういえば、DOSVAXJ3 は、高橋版VZでLFN表示できますね。今気が付きました。
Win95,98系APIに準拠させているのでしょうか。
VTDOSとMSDOS Player は、WinNT系準拠ということのようです。
CF の返り値だけの違いなので、NT系にするメリットってあるのかしら?

と思ったのですが、このキャリーフラグはFATシステムかNTFSシステムかの違いだったような。
謎です。


> 長いファイル名を取得するとしたら,ファイラで #R #H によって削除バッファに格納するくらいしか方法がないですかねぇ……。
>
> 何か良い方法はありますか?

う、私も基礎からやり直している最中なので、すぐには思いつきません。(^^;

[5296] Re^3: 一括リネームのテストと限界,結論

konno 2023/01/24(Tue) 23:48
[関連記事] [5291]へのコメント
> >REN コマンドは、command.com の内部コマンドなので、ロング名には対応していません。
>
>  REN コマンドの話は、僕がしています。
>  めざらさんのマクロはRENAME の func callしています。でも、古い、LFN対応でない奴。たぶん。

#5288 で先に同じような話をされていたんですね、気が付きませんでした。
#5289 の私の書き込みの6分前だったとは。(^^;

> INT 21 - Windows95 - LONG FILENAME - RENAME FILE
> AX = 7156h

やっぱり合っていたんですね、正確な情報ありがとうございます。

[5295] Re^2: 一括リネームのテストと限界,結論

めざら 2023/01/24(Tue) 20:58
[関連記事] [5289]へのコメント
http://mezala.la.coocan.jp/
> これ、実行環境は VTDOS ですよね。

そうです。どうやら,VTDOS 環境がどっぷり16ビットDOS のそれではないらしく,そのお陰で従来版ファインクションコール AH=56h で出力結果がロングになっても,通してくれることがわかりました。自分としてはこの辺りで満足です。一番時間のかかる連番付けさえ一瞬なら,あとは xyzzy ファイラでなんとでもなりますから。

> 試してみたら、最近の DOSエミュ3種は、同じようにロング変換できました。

ここの「試し」は,マクロ? バッチのREN ?

> ロング対応するなら、ax=$7156 だったかな。未確認。(^^;

&Fg() での取得がショートのみなので,例のマクロでは対応できないです。
そもそも,ロングを正しくファイラでソートできないので,番号付の順序が変わってしまい,順序が重要な場合は使い物にならないですね。

長いファイル名を取得するとしたら,ファイラで #R #H によって削除バッファに格納するくらいしか方法がないですかねぇ……。

何か良い方法はありますか?

[5294] Re^2: 一括リネームのテストと限界,結論

めざら 2023/01/24(Tue) 20:06
[関連記事] [5288]へのコメント
http://mezala.la.coocan.jp/
> INT 21 - Windows95 - LONG FILENAME - RENAME FILE
> AX = 7156h
> DS:DX -> ASCIZ old file or directory name (long names allowed)
> ES:DI -> ASCIZ new name (long names allowed)

拡張ファンクションコールは,こっちでしたね。ありがとうございます。

ただ,VZ の &Fg() 関数を使うと,取得できるファイル名がショートなので,$7156 を使っても結果は同じになってしまうことを確認しました。

いずれにしても,出力が結果的にロングになっても通るので,目的はほぼ達成できました。とてつもなく時間の節約ができましたので結果オーライです!

[5293] Re: LFN @ vtdos

文太 2023/01/24(Tue) 14:53
[関連記事] [5292]へのコメント
 昼休みの合間に、しつこく。
 できちゃうの?

>dir
a0123456789.txt		; safe LFN
b0123456789.txt		; if b0123456789 is 0123456789b ???
c0123456789.txt
d0123456789.txt
e0123456789.txt
f0123456789.txt
g0123456789.txt
h0123456789.txt
i0123456789.txt
j0123456789.txt

>type test.bat
ren a0123456789.txt	A.txt
ren b0123456789.txt	B.txt
ren c0123456789.txt	C.txt
ren d0123456789.txt	D.txt
ren e0123456789.txt	E.txt
ren f0123456789.txt	F.txt
ren g0123456789.txt	G.txt
ren h0123456789.txt	H.txt
ren i0123456789.txt	I.txt
ren j0123456789.txt	J.txt

>test.bat

>dir
A.txt
B.txt
C.txt
D.txt
E.txt
F.txt
G.txt
H.txt
I.txt
J.txt

then?

>type test2.bat
ren A.txt	a0123456789.txt
ren B.txt	b0123456789.txt
ren C.txt	c0123456789.txt
ren D.txt	d0123456789.txt
ren E.txt	e0123456789.txt
ren F.txt	f0123456789.txt
ren G.txt	g0123456789.txt
ren H.txt	h0123456789.txt
ren I.txt	i0123456789.txt
ren J.txt	j0123456789.txt

>test2.bat

>dir
a0123456789.txt
b0123456789.txt
c0123456789.txt
d0123456789.txt
e0123456789.txt
f0123456789.txt
g0123456789.txt
h0123456789.txt
i0123456789.txt
j0123456789.txt


 いちおう整理します。

 vtdosのコマンド・インタープリタはcommand.comである。
 これは、ここでは、MS-DOS 6.2Vのものである。LFNを理解するはずがない。
 ren は内部コマンドだから、MS-DOS 6.2Vのcommand.comのrenが
使われるはずである。よって、LFNのリネームは失敗が予想される。

 が、現実には、LFNが有効だった。

 はて、その心は?
 仮説:vtdosでは、command.comの内部コマンドは使われず、cmd.exeのそれが
使われる。
 ほんと?

[5292] LFN @ vtdos

文太 2023/01/24(Tue) 07:28
[関連記事] [5289]へのコメント
>dir

0123456789.txt			;SFNでは、012345~1.txtと示される(注)
test.bat

>type test.bat

ren 0123456789.txt 0.txt

>test.bat

>dir

0.txt

 という結果になり、自信はないけど、DOS6 のcommand.comが仕事をしているよう
には、見えませんでした。

(注)に示した。012345~1.txt のようなSFNはNT環境では、動的(相対的)な
ものなので、それを固定的にとらえて、たとえばrenとかしないほうがよい、という
のは、僕のXP時代の教訓です。

 僕が壮大にLFN→SFNをやったのは、XP環境かME環境だったのかもしれない
と、上の結果にもかかわらず、現在考えています。

[5291] Re^2: 一括リネームのテストと限界,結論

文太 2023/01/24(Tue) 00:06
[関連記事] [5289]へのコメント
>これ、実行環境は VTDOS ですよね。
 僕もこれは確認したかった。

 でも、

>REN コマンドは、command.com の内部コマンドなので、ロング名には対応していません。

 REN コマンドの話は、僕がしています。
 めざらさんのマクロはRENAME の func callしています。でも、古い、LFN対応でない奴。たぶん。

 心も体もぐちゃぐちゃな文太が、話をぐちゃぐちゃにしてる、、、。

[5290] renコマンドとワイルドカード

文太 2023/01/23(Mon) 22:37
[関連記事] [5279]へのコメント
 頭から残す、つまりベースファイル名の末尾からカットすることは可能なようです。

C:\WK\01>blt

0764DIMG.JPG
0765DIMG.JPG
0766DIMG.JPG

C:\WK\01>ren ????DIMG.JPG ????.JPG

C:\WK\01>blt

0764.JPG
0765.JPG
0766.JPG

 bltはゴミなしdirです。調子に乗っているのではなく、こっちのほうが
明らかに見やすいから。

 ただねぇ、こんな風に処理して短くして、有意味な情報が残ることがあるだろうか?
 やっぱ1個ずつのバッチ処理だなぁ。
 LFNをSFNに無理やりしてしまう。これは、僕はよくやります。邪魔だから。

>ren *.htm *.txt

 みたいなのは、ren + wildcard の定番です。

追記:少し意味ある? 使える? はやり削れるのは後ろから。行頭から再現されて
しまう。

C:\WK\01>blt

0764DIMG.JPG
0765DIMG.JPG
0766DIMG.JPG

C:\WK\01>ren ????????.JPG ????.JPG	;ここで、\1, \2 みたいなのが指定
					;できず、常に頭からになって
C:\WK\01>blt				;しまう。

0764.JPG
0765.JPG
0766.JPG

 使えません、と思う。こんなレアな場合があるか!

[5289] Re: 一括リネームのテストと限界,結論

konno 2023/01/23(Mon) 22:08
[関連記事] [5286]へのコメント
> 結局,元がショートに収まっていないと,渡される元ファイル名がショート形式であるため,例えば【ABCD00~1.IMG】が【ABCD00~1_01.IMG】になるだけ。

これ、実行環境は VTDOS ですよね。
REN コマンドは、command.com の内部コマンドなので、ロング名には対応していません。
VTDOS がうまい具合にロングに変換してくれているのでしょうね。
試してみたら、最近の DOSエミュ3種は、同じようにロング変換できました。
おそらく Win95以降のDOS窓でも同じ動作だと思います。

VZマクロでは、ax=$5600 を使っているので、元がショート名しか対応しないのは当然ですね。
ロング対応するなら、ax=$7156 だったかな。未確認。(^^;

> なので,最初にショートに納まっているファイル名に当マクロで連番を付け,その後 xyzzy ファイラで追加の定型識別子を付与するというという手順。

xyzzy は非常に高機能で使いこなせれば便利そうですね。
私は全く触れていませんが。(^^;

[5288] Re: 一括リネームのテストと限界,結論

文太 2023/01/23(Mon) 22:02
[関連記事] [5286]へのコメント
INT 21 - DOS 2+ - "RENAME" - RENAME FILE	★
	AH = 56h
	DS:DX -> ASCIZ filename of existing file (no wildcards, but see below)
	ES:DI -> ASCIZ new filename (no wildcards)

 上ではなくて、下では?

INT 21 - Windows95 - LONG FILENAME - RENAME FILE
	AX = 7156h
	DS:DX -> ASCIZ old file or directory name (long names allowed)
	ES:DI -> ASCIZ new name (long names allowed)


 元々少し勘違いしていましたが、rename func ではないですが、Win32では
LFN取得もできるはずです。

E:\0PROG\BOOKS\IBM>bll
IBM_Macro_Assembler_100.pdf
IBM_PC_BASIC_110_1982-05-BW.pdf
IBM_PC_DOS_200_1983-01.pdf

 しつこい。

[5287] Re^4: 一括リネームのテスト

めざら 2023/01/23(Mon) 11:57
[関連記事] [5285]へのコメント
http://mezala.la.coocan.jp/
>  この形ならcols.defですね。

その形式にするのに,取得したリストを加工しなければならないから,やっぱり手間かな。対応表を作る(dirのリストからファイル名以外を除去し,ファイル名を行内で二重化)→ 桁位置指定のゼロパディング連番付与マクロで番号振り → コマンド文字列付与後バッチファイルとして保存 → 実行

すごくたくさんのファイルがある時は,かなり時間の節約になるのは確かなので,ケースバイケースですかね。

>  かえるとかでなくて、めざらさん、アセンブラをやろう!
> 一緒にゆっくり生きてくださいよ。最低あと10年はあるでしょう?

いつも共に居るとは思ってますけど,アセンブラは高橋さんのJOANNE.com&def に渡すくらいのサイズが限界かなと思います。

だって,だって,とてつもなくめんどくさいんだもん!

[5286] 一括リネームのテストと限界,結論

めざら 2023/01/23(Mon) 11:37
[関連記事] [5278]へのコメント
http://mezala.la.coocan.jp/
> 結果がロングになってしまう場合はどうなるのかいな…と思って実行したら,

ちょっとだけ複数のケースを確認したところ,条件つきと判明。
DOSのファンクションコールは,中途半端に長いファイル名対応であること。

入力ファイル名 → 出力ファイル名 → 変換結果・成否
ショート → ロング → 元ファイル名+付加文字列 成功
ロング → ロング → ショート形式ファイル名+付加文字列 失敗

結局,元がショートに収まっていないと,渡される元ファイル名がショート形式であるため,例えば【ABCD00~1.IMG】が【ABCD00~1_01.IMG】になるだけ。

なので,最初にショートに納まっているファイル名に当マクロで連番を付け,その後 xyzzy ファイラで追加の定型識別子を付与するというという手順。

手作業だと96%(体感*1)の時間を占める連番付与さえマクロで自動化できれば,圧倒的な時間の節約になるから,こんなところであろうか。

*1 メモファイルのグループは最大30程度のため,100の工程が3〜4になる計算。

[5285] Re^3: 一括リネームのテスト

文太 2023/01/23(Mon) 01:07
[関連記事] [5281]へのコメント
 すいませんが、ここだけです。

>バッチで ren するって,なかなか根性が要りますよね。
>リスト取ってゴミを除いて整形して対応表を作ってブロックペースト……気が遠くなる。
>それでも正規表現が使えそうだからまだしも,ですが。

c:\vzlog\pk14>bltwr

ren PK14_924.LOG	PK14_924.LOG
ren PK14_92C.LOG	PK14_92C.LOG
ren PK14_932.LOG	PK14_932.LOG
ren PK14_939.LOG	PK14_939.LOG
ren PK14_944.LOG	PK14_944.LOG
ren PK14_94C.LOG	PK14_94C.LOG
ren PK14_953.LOG	PK14_953.LOG
ren PK14_959.LOG	PK14_959.LOG
ren PK14_961.LOG	PK14_961.LOG
ren PK14_965.LOG	PK14_965.LOG

 この形ならcols.defですね。

 かえるとかでなくて、めざらさん、アセンブラをやろう! 一緒にゆっくり生きて
くださいよ。最低あと10年はあるでしょう?

 xyzzy、おお、すげえ。とりあず導入します! その機能のためだけでも。

[5284] Re^4: 一括リネームのテスト

めざら 2023/01/22(Sun) 18:20
[関連記事] [5282]へのコメント
http://mezala.la.coocan.jp/
バッチ一択ですか……。さすが根性の人だった。

> バッチだと何がいいって、変換前と変換後が一覧で見れるところ。

まぁ,そうですね。でも,変換はしちゃいますよね。

xyzzy ファイラのどこがいいって,変換結果を事前表示してくれて,これで実行するかどうか確認してくれるところです。そもそも変換前の正規表現にマッチしないファイルは対象にならないので,おかしなことも起こらない。

日々使っていると履歴も使えるので,定型ならその都度考える必要もなし。

radiko を録音したファイルとか,制作側の都合でやたら長いファイル名なんかになっていたりするわけですが,一括で処理できるのでとても便利。

また,動画なんかをエンコードするために ffmpeg にバッチでファイル名を渡したいとき,全角スペースなんて使ってあると(たぶんWindowsのバグで)バッチの構文が割れちゃったりするのを予防するため半角スペースに直すなんてのも,
【\(.+\) \(.+\)】 → 【\1 \2】の履歴使い。楽ちん。

わたしの一択です。

[5283] Re^6: 自分で限界を作るなかれ…(いやいや)

めざら 2023/01/22(Sun) 18:10
[関連記事] [5280]へのコメント
http://mezala.la.coocan.jp/
うちでも,ああいうのは初めてですよ。
二股の色っぽいやつはときどきお目にかかりますけどね。
スカスカの垣根の向こう側が,砂利を敷いた通路になっていて,配達系バイクとかが小石を飛ばしてくるので,小石は避けられません。そもそもどんな小さな塵芥が原因になりうるかもわかりませんから諦めています。

大根菜は,細かくきざんでいろいろなものに混ぜて食っちゃいます。
菜っ葉に比べれば少々ちくちくえぐい感じもありますが,慣れですね。
おすすめの食べ方ってのはちょっと思いつかないです。好みだから。
おかかと和えてご飯のお伴ってのはよく聞きますけど,うちはあまりやらない。

>  今晩、ふくよか2号を大根おろしで食べてみよう! 正統派。

この時期になれば成長しきって,先っぽも丸くなってそう辛くないでしょうね。
例の指つきは先っぽからおろしましたが,ほとんど辛味はありませんでした。

正月に施肥かぁ……そりゃ大変だよ,寒くて……

[5282] Re^3: 一括リネームのテスト

としき 2023/01/22(Sun) 17:52
[関連記事] [5281]へのコメント
http://toshiki.la.coocan.jp/
> バッチで ren するって,なかなか根性が要りますよね。

この手の案件だと、私はバッチ一択ですね。
dirコマンドの結果をキーボードマクロで処理。
cols.defを使うこともある。
バッチだと何がいいって、変換前と変換後が一覧で見れるところ。
何か気がつかないミスをやらかして変換結果がおかしくても、もう一度バッチを見れば、自分が一体何をやらかしたのかがすぐわかるというのは、私にとってはわりと大きなメリット。

[5281] Re^2: 一括リネームのテスト

めざら 2023/01/22(Sun) 16:53
[関連記事] [5279]へのコメント
http://mezala.la.coocan.jp/
わ…ワイルドカードですって?! そういうの,dir か copy でしか使ったことないですよ…… ren で通用するとは夢にも思いませんでした。でも,通らなかったわけですよね。DOS のワイルドカードで何かできるなんて思えないけれど,再履修の必要があるでしょうか。(そんな時間はない)

バッチで ren するって,なかなか根性が要りますよね。リスト取ってゴミを除いて整形して対応表を作ってブロックペースト……気が遠くなる。それでも正規表現が使えそうだからまだしも,ですが。

実際に,何かできる「はず」なのかなぁ……


現実的には,ファイル名の共通する一部を削除してリネームするなんてのは,Emacs 風ウィンドウズエディタの xyzzy ファイラーでやっています。これは正規表現が使えるので毎日使っています。その流れで,大抵のファイル操作は xyzzy を使っていますね。VZ …と言うか実際には VZ のファイラーで使っている RCP32 なんですけど…の出番はバックアップリネームコピーとか小文字化/大文字化コピーくらいかな。現時点での用途はそういう感じです。

[5280] Re^5: 自分で限界を作るなかれ…(いやいや)

文太 2023/01/21(Sat) 16:09
[関連記事] [5277]へのコメント
>リンクを貼り直したので,ご面倒でなければ見てください。

 色っぽかったですよ!
 申し訳ありません、なぜか、うちではああいうの見たことがない。
 たぶん、根菜をやるところの畝を一度徹底的に石除去してるからかな? 一夏かけて。
 その後、ほぼ耕していませんが。

>葉っぱはおそらく使えなくなっちゃいますけどね。

 僕は、大根の葉っぱはほぼ食べなくなりました。とりわけこの時期は、青臭さがどうも、、、。湯通ししてもダメだと思う。
 ふりかけも作るのが面倒、食べるのも大変、と感じてしまってますねぇ。
 「こう食べなさい!」とかありますか?

>>あ、それはダイソーの種だからでは、きっとないと思う。"
>自分が下手だからです(笑)。ほんとにプランタやポットで育てるの苦手なので。

 偉そうに言うことは何もないですが、もっと大ざっぱにやってしまうというのは?
 つまりプラグトレイとかって、夏の終わりとかだと1日に2回とか見てやらなくちゃいけない。
 育苗トレイ(50X30X8センチ)みたいなのにどかっと土を入れると、5日くらい見なくても死んではいません。もちろん、そろそろその時期になりますが、夏野菜の苗作りでは、何せ屋内なので、12センチポットとかで芽出しとかもしてますけれど。8粒くらいでスタート。
 しかし、これは居間なので、2日に1回は見るし、外に出したら夜はぜったいしまってますが。

>日陰がいいのかな…と思うけれど,
 タマネギの発芽では、これが推奨されていると思います。

>ちゃんと「来年は代わりのものを紹介させていただきます」と伝えられていますよ。

 さすが。ものすごくちゃんとした園芸店みたいですね。
 最初、ニュージーランドの種取りは、小さな業者一店だけではやれないだろうと思ったのだけど、あのやる気では、じゅうぶんあり得るな、と。賞とか狙っちゃってますもんね。

>ダイソーで「おでん大根」種を買ったのに,

 F1(交配種)のものと固定種のものがあったような。試してみてください。
 僕は、トーホクの「おでん大根」(F1)が一番だと思っていたけど(初期成功体験の記憶、おそらく)、最近、自分の味覚にまったく自信がありません。おいしいよ、みんな、とか。
 今晩、ふくよか2号を大根おろしで食べてみよう! 正統派。

>楽しくて仕方がない。ダイソーさんにもお世話になりますわ。

 うん、分かります。100円だとどうでもいいものまで買ってしまう、、、。
 それでも、中国の中間業者には、「日本の人は品質にうるさくて」と言われているらしい。ニッポン、まだ、大丈夫だ!

[5279] Re: 一括リネームのテスト

文太 2023/01/21(Sat) 15:41
[関連記事] [5278]へのコメント
 僕も同じような課題にのぞんだことがあります。
 もうちょっと話が複雑だったので、>ren コマンドを連発するバッチファイルでしのぎました。

 で、真っ先に

>それならデジカメの機種等を示す英字4文字は消してしまっておいて
>連番を付ければいいかも…ということで試作し,

 が気になり、renのワイルドカードを使って、8.3のファイル名を4.3にしてから、、、と考えたら、どうもワイルドカードを使ったrenコマンドでは、文字数を減らせないみたい、という結論に。

>ren DIMG0764.JPG 0764.JPG
 という1個ずつの処理はもちろんできる。
 ところが、

>ren DIMG????.JPG ????.JPG
 はダメ。みたい。ワイルドカードのヒット箇所が変みたいだ。

 本題からずれて申し訳ないのですが、どうもそんな結果になってます。
 何かこのワイルドカード変だと思う。不思議な仕様、という意味ですが。
 内部的には、findfirst/nextですよねぇ? ???
 僕がどっか間違ってるのかなぁ?

[5278] 一括リネームのテスト

めざら 2023/01/20(Fri) 15:12
[関連記事]
http://mezala.la.coocan.jp/
フォトファイルに連番を付与するマクロのテストと備忘録です。

もともとの要求というのが,メモ代わりに撮影した写真のファイルに連番を付ける
というものです。そもそも元のファイル名が英字4文字と数字4文字なので,さらに
連番を付けるとロングファイルネームになってしまうわけで,通常の
ファンクションコールでリネームするのは危険かと思い込んでいたわけです。
それならデジカメの機種等を示す英字4文字は消してしまっておいて
連番を付ければいいかも…ということで試作し,
結果がロングになってしまう場合はどうなるのかいな…と思って実行したら,
ロングファイルネームでいけちゃったという……。

DOSのファンクションコールも長いファイル名対応なんすね……ってことで良いのか
悪いのかよくわからないんだけれど,まぁ結果オーライってことで。

ファイラーで選択したファイルを次のようにリネームします。
DIMG0764.JPG → DIMG0764_01.JPG
DIMG0765.JPG → DIMG0765_02.JPG
DIMG0766.JPG → DIMG0764_03.JPG
 … 以下,略。 …

= RnBnname.def   v0.10 = by H.ear
連番を振ったファイル名にリネーム(複数選択対応版)
ロングファイルネームでも可能なので,結果がショートに収まらなくてよい.
* mad for vz!
1 ^\ "" (s!=3)?.			;ファイラーのみ
	e=i-,				;<i>:マークファイル処理数
	(fl..5)??{			;マークしていなければ
		FM[-, ' ' FM],		;カーソル位置のファイルを選択
	}
	&Fi (r)??.			;選択ファイルの先頭へ
 :a	&Fg(pq..137,1)			;ファイル名を取得
	fv^=4, #V			;再表示
	&Sy(pq..137)			;パス名取得・解析
	(si>cx)?{ &Sc(pu,cx) }?pu.0-,	;拡張子抽出
	&Sc(pa,bx) pa.(cx-bx)-,		;ファイル名複写と拡張子切除
	&Sp(pq..134,"%s_%02d%s",pa,i+1,pu)
	dx=pq..137,			;old path / pathbuf
	di=pq..134,			;new path / tmpbuf
	ax=$5600, &i($21)		;Rename
	(r)?e++, ?i++,
	&Fn (r)?>a
	#U
	&m("success: %d file(s). / failure: %d file(s).",i,e)
*

↑ このページの先頭