一括表示

フォトファイルに連番を付与するマクロのテストと備忘録です。

もともとの要求というのが，メモ代わりに撮影した写真のファイルに連番を付ける
というものです。そもそも元のファイル名が英字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)
*

　すいませんが、ここだけです。

>バッチで 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ですね。

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

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

　頭から残す、つまりベースファイル名の末尾からカットすることは可能なようです。

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です。調子に乗っているのではなく、こっちのほうが
明らかに見やすいから。

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

>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

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

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では
ＬＦＮ取得もできるはずです。

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

　しつこい。

>これ、実行環境は VTDOS ですよね。
　僕もこれは確認したかった。

　でも、

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

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

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

>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　のようなＳＦＮはＮＴ環境では、動的（相対的）な
ものなので、それを固定的にとらえて、たとえばrenとかしないほうがよい、という
のは、僕のＸＰ時代の教訓です。

　僕が壮大にＬＦＮ→ＳＦＮをやったのは、ＸＰ環境かＭＥ環境だったのかもしれない
と、上の結果にもかかわらず、現在考えています。

　昼休みの合間に、しつこく。
　できちゃうの？

>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のものである。ＬＦＮを理解するはずがない。
　ren は内部コマンドだから、MS-DOS 6.2Vのcommand.comのrenが
使われるはずである。よって、ＬＦＮのリネームは失敗が予想される。

　が、現実には、ＬＦＮが有効だった。

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

　経験にてらしてみれば、別に特別なことではなかったですね。（※）
　vtdos環境で、dirしたら、どんな結果になる？　そこでcommand.com 
(ver.6.20)は使われてませんね。

C:\WK\01>dir /?
  /X          このオプションは MS-DOS 形式以外のファイル名に対する短い名前を
              表示します。長い名前の前に短い名前を表示する点を除けば、
              /N オプションと同じです。短い名前がない場合は、ブランクに
              なります。

C:\WK\01>dir /X

2023/01/28  17:57                 0 012345~1.TXT 0123456789.txt

　ほら、ちゃんとＬＦＮも両方出てる。cmd.exeですよ。で、なんのための
command.comか？　ＤＯＳアプリはcmd.exeをコマンドインタプリタとしては
動けません。
　そして、command.comの内部コマンドはcmd.exeに飛ばされる。
　で、元々の話題のＦコールは？

----------------------------------------------------------------------------

=== Macrotmp by B ===;
* M
50 ^^ "Macrotmp"

;	dx="c:\wk\01\01234567.txt",		;SFN　↓　rename success
;	di="c:\wk\01\0123456789.txt",		;LFN

	dx="c:\wk\01\0123456789.txt",		;LFN　↓　rename success
	di="c:\wk\01\0123456789000.txt",	;LFN

	ax=$5600, &i($21)		;Rename

*

　というわけで、ＬＦＮファンクのあるものは、やっぱり飛ばされる。★

-------------------------------------------------
INT 21 - DOS 2+ - "RENAME" - RENAME FILE
	AH = 56h
-------------------------------------------------

　は、下へ飛ばされる。下は上を含みますからね。

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


（※）経緯をおさらいすると、我々（konnoさんと僕）は、vtdosのＤＯＳ機能は
DOS ver いくつか？　とか、command.comのverを dos ver F_call が返すぞ、
とかやっていたものだから、>dir のいわば自然な振る舞い（cmd.exeのそれ）の
ことを忘れてしまっていたのです。

　どうでもいいことだけど、種明かしをすると、

#5293 
>dir
a0123456789.txt		; safe LFN

　はインチキだったのです。いえ、報告内容にはインチキはありません。
ただ、ここを書いたとき、>dir の結果を写してはいなかった。でも、こうなる
のを知っていた。確かめてもいた。で、さっき眺めてて、あれ？　dir も内部コマンド
なんですけど？　command.comがＬＦＮとかレポートできちゃっていいわけ？　と常識を
取り戻したという次第です。

　というわけで、あったとしたら、新たな発見は、★の発見です。


追記：これも関連事項でした。そして、こういうことがすぐ連想でできないのが、
僕、文太です。

　ren コマンドも同じ話です。vtdos環境で、ren がＬＦＮを扱えるのなら、それは
command.com の内部コマンドではないはずです。これも、cmd.exeに（と言っていい
のか分からないけど。だって、その実態はＦコールですから−−Ｆコールの実態とは
何かを追っかけてるのが、Undocumented DOS 2nd, see int 21h の正体　＝　ＤＯＳ
の「ヌード」みたいな実体。原書 p.266-, chap 6, "What is MS-DOS?"。Win32 system
でも、我々が気にする部分は同じ。というか同じように作られてる）飛ばされる。

　括弧の多い文章すいません。ふつう許されないと思います。難しい言葉でごまかすと
「意識の流れ」とか言います。

konnoさん

>>うう、追記は読んでいませんでした。(^^;
　時間差がありました。m(__)m

> 　ren コマンドも同じ話です。vtdos環境で、ren がＬＦＮを扱えるのなら、それは
> command.com の内部コマンドではないはずです。

　これは、vtdosの話です。

>ということで、Win98Me のDOS窓でそのマクロを試してみました。
　そのマクロが#5298のことなら、

>結果は、ロングの処理は出来ませんでした。
　当然でないですか。そのために、Win95以来の。ＬＦＮ対応ファンクがあったのだから。

	ax=$5600, &i($21)		;Rename

　は、LFNを知らない、純ＤＯＳファンクですよ。

>LFN対応の DOS8.0 は、ロング処理をしないようです。

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

　での話ですか？
　だとしたら、僕はかなり混乱します。

　基本的に、vtdosのＦコールの特殊事情を主題にしています。

　混乱が解け不安も解消することを祈っています。

> >ということで、Win98Me のDOS窓でそのマクロを試してみました。
> 　そのマクロが#5298のことなら、
> 
> >結果は、ロングの処理は出来ませんでした。
> 　当然でないですか。そのために、Win95以来の。ＬＦＮ対応ファンクがあったのだから。

ファンクションコールがDOSと完全互換なら、VTDOSでもロングの処理は出来ないはずです。

> 	ax=$5600, &i($21)		;Rename
> 　は、LFNを知らない、純ＤＯＳファンクですよ。

そのファンクションがLFN処理出来るようになっているので、互換性がないことになります。
各種DOSエミュは示し合わせたようにロングの処理を拡張していますが
おそらく利便性のためだと思っています。


確認は、文太さんのマクロをちょっと変えてみました。

=== Macrotmp by B ===;
* M
50 ^^ "Macrotmp"

	dx="d:\01\01234567.txt",		;SFN　↓　rename success
	di="d:\01\01234567890.txt",		;LFN
	ax=$5600, &i($21)		;Rename
	a=r,

	dx="d:\01\0123456789.txt",		;LFN　↓　rename success
	di="d:\01\0123456789000.txt",	;LFN
	ax=$5600, &i($21)		;Rename
	b=r, c'NG',
	(a+b>0)??c'OK',
	&m("%d  %d  %c",a,b,c)

*


	d:\01\01234567.txt		;SFN　↓　rename success
	d:\01\0123456789.txt		;LFN　↓　rename success

この２つのテキストでチェックしました。
返り値 r のキャリーが立っていたら NG のつもりです。

お休み中の予定

　本物の修羅場に突入します。毎年のこと。
　ただただ事故を起こさないよう慎重に生きてゆきたいと思っています。

　お休み中、ほぼ無意味に macro.asm のハードコピーを持ち歩き、そして、
BIOS コールとはなんぞや周辺をぶらぶらしてみたいと思います。video （モノが
進化しちゃってるからねぇ）とdisk。直接Ｖｚと関係はないと思うけど。

　後者に関して、あるんだぁ、という発見。

　以下は、NU (Norton Utilities) の BE (Batch Enhancer) の doc から。

----------------------------------------------------------------------
DISKMON (DISK MONITOR)	Enable or disable disk protection features: 
			Disk Protect and Disk Park.
	DISKMON  [/PARK]
	/PARK 		Park the disk heads on all drives. 
----------------------------------------------------------------------

　こんなことできるのね。旧８でキーボードバッファの拡大とかＨＤのヘッドの
退避とかあったじゃないですか（古い資料の発掘、ありがとうございました
＞としきさま）。

　あ、つまり、今回も様々な刺激ときっかけををいただき、そして色々と勉強させて
いただきました。幸福の至りでございました。多謝でありまする。
　なんだ？　この言葉づかいは！？

>ということは、VTDOSの F コールは VTDOS がロングにしているということでしょう。
>〔F コールのばあい、コマンドラインのrenと違って〕USECMD=　の値にかかわらず
>ロングになるからです。

　なるほど！　と思ったのですが、うーん、もやもやする。

SFN Fcall -> LFN Fcall		;(1)「投げる」と僕は表現してきたと思う。

　上をVTDOSがする、というのが僕のイメージ。

　USECMD=0 の場合、(1)をVTDOSがしない、といういう言い方はどうでしょう？
　おなじことを言ってるのか？

　僕が想像しているのは、command.comの内部コマンドのrenであれ、Ｖｚマクロ
からの ax=$5600, &i($21)であれ、けっきょくそれは、command.comやＶｚがやっている
というより、ＤＯＳカーネルがやってることでしょう？　という意味なんですが。
　VTDOS環境においては、VTDOS自身がＤＯＳカーネルである。
　はい、そう認識しています。


--- usecmd=0 in VTDOS.cfg ---
C:\>dir |more

 Volume in drive C is OS         
 Volume Serial Number is 0A1E-F410
 Directory of C:\

0            <DIR>         22-12-28   23:05
001      LOG        42,436 23-01-18    1:17
00EG     TXT         1,176 23-01-21    2:07

　おほほほ。久しぶりにみたなぁ。汚いルートは見慣れておりますが。

C:\>dir /p		; 効きます！！！　た、たどり着いた！！！
iroiro
iroiro
Press any key to continue . . .

　再整理ありがとうございました。
　予想どおりの結果でした。

　【実験】ＳＦＮ用renameファンク、ax=$5600, &i($21) をＬＦＮに対して実行する。

　Win9x		NG
　WinXP		NG
　vtdos		OK

>理由はわからないけれど，VTDOS 環境ではロングの扱いが美味しい。
>…という結果オーライ。

　です。たぶん、vtdos.txtが読みこなせれば、それなりの想像ははたらくのかも。