過去の桐井戸端ＢＢＳ　（桐ver.５）

14017	「システム」コマンドでバッチが動かない	A. I.	2001/11/17-21:27
桐Ver.5の一括処理中で、システム　"a:\bat\getdrv.bat","",&実行リターン とすると、コマンドまたはファイル名が違いますとエラーメッセージが表示されます。 もちろんa:\bat\には、PATHが通してあります。 .batを.comに変換するソフトがあったので、変換すると動きました。 その他にも、システム　"getdrv.exe","" とか、 システム　"env_drv.exe","-f:"とかを実行させてもおかしい？ getdrv.exe, env_drv.exeは、環境変数に、接続されているデバイスのドライブ番号を設定するソフトなのだが、 単独で実行すると、うまく設定されるのに、桐の子プロセス(システムコマンド)だと何も設定されない。 なぜか、よく判らない？　別の質問で、折角良いアドバイスを頂いて喜んだのも、つかの間、・・・・・・・困ってます。
14018	Re:"システム"コマンドでバッチが動かない？	pokopon	2001/11/17-23:07
記事番号14017へのコメント A. I.さん こんばんは 環境変数の次はシステムコマンドですね。 ただ、桐Ｖ５ですので、ほとんど忘れてしまったから・・・・。 >桐Ver.5の一括処理中で、システム　"a:\bat\getdrv.bat","",&実行リターン システム　"commando.com","/c a:\bat\getdrv.bat",&実行リターン command.com を起動してみたら？　/c の意味は、DOSプロンプトで　command.com /? で >その他にも、システム　"getdrv.exe","" とか、 >システム　"env_drv.exe","-f:"とかを実行させてもおかしい？ >getdrv.exe, env_drv.exeは、環境変数に、接続されているデバイスの >ドライブ番号を設定するソフトなのだが、単独で実行すると、うまく >設定されるのに、桐の子プロセス(システムコマンド)だと何も設定されない。 これらもcommand.com からの起動？？ はずしていたら　m(__)m 参考：No.13946 その他、過去ログで　「システム」で検索してみるとか？
14019	Re:訂正	pokopon	2001/11/17-23:34
記事番号14018へのコメント >システム　"commando.com","/c a:\bat\getdrv.bat",&実行リターン 訂正 システム　"command.com","/c a:\bat\getdrv.bat",&実行リターン commando.com →　command.com でした。　m(__)m
14027	やはり:"システム"コマンドでバッチが動かない！	A. I.	2001/11/18-09:45
記事番号14018へのコメント pokoponさん、度々お世話になります。 >システム　"command.com","/c a:\bat\getdrv.bat",&実行リターン やはり、コマント゛あるいはファイル名がちがいます・・・・・のエラーメッセージが表示されブザーがピッと鳴ります。 ちなみにDOSは、EPSON製Ver.5.0ですが、MS-DOSの種類バージョン等も関係するでしょうか？ getdrv.batの中身は、getdrv.exeを実行し、環境変数"FD1"にセットされた"E:"というドライブ名を、 echo %FD1% > fd_drv.txt で書き出すだけのものですが、 (ここのところは、桐の一括処理内で、#GETENV関数を使用することで不要になった) この、ECHOコマンドもBATファイルだとうまくファイルに書き出してくれるけど、.BATを>COMに変換させると、 まったく書き出してくれない・・・・・とか、システムコマンドやMS-DOSのコマンドレベルをいぢりだすと、次々と、問題が起きてきそうですね！ ところで、システムコマンドの動作に関しては、管理工学に問い合わせをした方が、よいでしょうか？ どなたか、良いアドバイスをお願いします！ pokoponさん >その他、過去ログで　「システム」で検索してみるとか？ 過去ログで、検索してみましたが、検索の仕方が悪いのか"システムコマンド"の使い方の参考例は、見つかりませんでした。
14030	Re:これは、DOS側からのエラー？	pokopon	2001/11/18-10:12
記事番号14027へのコメント A. I.さん　こんにちは >>システム　"command.com","/c a:\bat\getdrv.bat",&実行リターン >やはり、コマント゛あるいはファイル名がちがいます・・・・・のエラーメッセージが >表示されブザーがピッと鳴ります。 当方で、違うコマンド（バッチ処理ですけど）で試した所、正常に動いていました。 （WindowsのDOS窓で起動した桐V5で） この、「コマント゛あるいはファイル名がちがいます」は、MS-DOS側からのエラーと思われます。 この、a:\bat\getdrv.bat は、きちんとした場所（このとおりの場所）に、本当にあるのですか？ 単に、指定された場所にバッチファイルがないだけかと思いますけど。 （パスが通っているからと、省略していませんか？） 桐を起動中に、「システム」にチャイルドとして直接落ちてみて、そこから（DOSプロンプトで）、 a:\bat\getdrv.bat とタイプして、実行されますでしょうか？ あるいは、getdrv.batの中身自体の記述にミスはないでしょうか？（ディレクトリなど）DOSのバージョン？？ あんまり関係ないと思いますけど。おかし〜な〜。
14031	Re:エプソンDOS？	pokopon	2001/11/18-10:16
記事番号14030へのコメント >ちなみにDOSは、EPSON製Ver.5.0ですが、MS-DOSの種類バージョン等も関係するでしょうか？ エプソンのMS-DOSですか？ 確か前に聞いたことがあるような、ないような。　他のアプリと互換性が保てないとかなんとか？ あまりにも古い話なので、忘れましたけど。 まずは、１ステップずつ確認していきましょう。
14032	Re:やはり:"システム"コマンドでバッチが動かない！	幅田	2001/11/18-10:31
記事番号14027へのコメント A. I.さん こんにちは。 以前に、DOS桐のシステムで、同じようなことが起こったような記憶が頭のすみにあります。 実行するファイル名にドライブ名を付け加えても反応してくれなかったと（思います。） あのときは、実行するファイルを桐のシステムがあるディレクトリに置いておくとうまくいったような（気がします。） （\kiriv5\など） その一括処理は職場にあるので今は確かめようがありません。 確かな情報でなくてすみません。明日確かめてみます。 Win版桐だと一括処理のファイルと同じところにあればそれでいいのですが。
14034	私のかこの記憶では	佐田　守弘	2001/11/18-11:21
記事番号14027へのコメント A. I.さん 桐ver.5のシステムコマンドについては、古い話なので記憶が定かでなくなっておりますが、 私は当時、このコマンドを日常茶飯事に使っておりましたし、システムコマンドでバッチファイルを起動する事も 普通に行っていた様に思っています。 なにしろ、システムからバッチが起動できなければ、仕事になりませんでしたから。 確か、桐から松を起動する時も、松を起動するバッチファイルを実行していたはずだと思います。 なお、当時のマシンは、エプソンとNECのマシンです。 （他に98シリーズとその互換機はなかったので） 佐田守弘(KS-00119) とは言え、今となっては古い記憶なので、誤っている可能性もあります。 しかも、マシン環境から確認する事も困難です。 管理工学のサポートに聞いてみるのも１つの方法でしょう。 今でも動作確認ができる環境を持っていると思います。
14036	結果を報告します！	A. I.	2001/11/18-12:05
記事番号14027へのコメント pokoponさん、幅田さん、アドバイスありがとうございます。 pokoponさんのアドバイスで桐表から、システムで　"a:\utl\getdrv.exe"を登録し、 実行しても駄目でした。 幅田さんのアドバイスで桐のシステムと同じディレクトリにgetdrv.exeやenv_drv.exeを移し、 一括処理を実行すると、環境変数へのセットは、やはり出来なかったのですが、 バッチファイルの行まで実行してもエラーが出なくなりました。 どうやら、コマント゛あるいはファイル名がちがいます・・・・・のエラーメッセージは、 何行か前に実行した　システム　"a:\utl\getdrv.exe","",&実行リターン (あるいは、システム　"a:\command.com","/c a:\kiriv5\getdrv.exe",&実行リターン) が、何らかの原因になっていたものらしいのです。 （しかし、合点がいかないのは、バッチファイルの中では、getdrv.exeが、まともに働き、 ちゃんと環境変数にドライブ番号をセットしてくれたことです。） とりあえず、バッチファイルはシステムコマンドで動くことが確認できましたので、 当分は、getdrv.batでテキストファイルに環境変数の中身を書き出し、 ファイル入力で読み込むというやり方でやってみます。 折角、pokoponさんには、桐の一括処理内で、#GETENV関数を使用する方法を教えて頂いたのに 今回は、getdrv.exeと桐Ver.5の相性の問題？で使えなくなりました。 今後とも、お二人のご先輩には、多々お世話になると思いますが、よろしくお願いします。
14037	バッチのせいではなかった	A. I.	2001/11/18-12:15
記事番号14034へのコメント 佐田　守弘さん、返事を入力していたので、失礼しました。 >私は当時、このコマンドを日常茶飯事に使っておりましたし、システムコマンドでバッチファイルを >起動する事も普通に行っていた様に思っています。 >なにしろ、システムからバッチが起動できなければ、仕事になりませんでしたから。 >確か、桐から松を起動する時も、松を起動するバッチファイルを実行していたはずだと思います。 トレースで動かしていて、バッチファイルを実行させた途端にエラーが出たもので、 てっきり、バッチファイルの問題だと思い込んでいました。
14038	Re:結果を報告します！	pokopon	2001/11/18-14:13
記事番号14036へのコメント A. I.さん　こんにちは >pokoponさんのアドバイスで桐表から、システムで　"a:\utl\getdrv.exe"を登録し、 ではなくて、SHIFT+f・８で、システムに移ってから、 直接、バッチファイル名をタイプして、正常に実行できるかどうか、同様のエラーが返って来るかどうか、を確かめてほしいのです。 >どうやら、コマント゛あるいはファイル名がちがいます・・・・・のエラーメッセージは、 >何行か前に実行した　システム　"a:\utl\getdrv.exe","",&実行リターン >(あるいは、システム　"a:\command.com","/c a:\kiriv5\getdrv.exe",&実行リターン) >が、何らかの原因になっていたものらしいのです。 ちなみに、このバッチファイル内では、上記のソフトで「環境変数をセットしていること」を前提として、 ドライブ名などが記述されていませんでしょうか？ チャイルドプロセスで設定した環境変数は、親のプロセスには反映されません（他の方からの情報で）。 ですので、１つ前のシステムコマンドで設定した環境変数は、 次の行で実行したシステムコマンドでは「見えない」と思います。 >コマント゛あるいはファイル名がちがいます・・・・・のエラーメッセージは、 あくまでcommand.com が通常出す「ファイルがありませんせんよ、認識できませんよ」のエラーですので、 桐コマンドが原因ではありません。 完全な解決策として、（どうしてもドライブ設定を桐でやらなければなりませんか？） １．autoexec.bat のなかで、これらの環境設定アプリを動かし、最初にドライブ等を設定しておく。 ２．桐側では、#GETENV関数で環境変数の値を得る。 だと思いますが。 >今回は、getdrv.exeと桐Ver.5の相性の問題？で使えなくなりました。 ということで、これは違うと思います。
14043	Re:環境変数の基本	Ogo	2001/11/18-15:32
記事番号14038へのコメント >チャイルドプロセスで設定した環境変数は、親のプロセスには >反映されません（他の方からの情報で）。 環境変数を使うための基本は守られていますか？ １．CONFIG.SYS で充分な容量を確保していますか？ 　　Shell=A:\command.com /p /e:1024 とか。 ２．上の文でも出ていますが、チャイルドプロセスで設定された 　　環境変数は親プロセスには反映されません（親プロセスでの 　　環境変数は参照できる――上記のアドバイスはそれを簡単に 　　実現するための方法）。 　　もちろん、別途新たに起こされたチャイルドプロセスには、 　　前回のチャイルドプロセスで設定された環境変数などは反映されません。 　　※　ここで「チャイルドプロセス」とは桐５の「システム」 　　　　コマンド１回を１チャイルドプロセスだと思えばよい。 ３． BATCP で .BAT を .COM 化する時は、オプションの指定によって、 　　強制的に環境変数を残すことができるのです。 　　これは極めて特殊な条件です。 先日もフロッピーのドライブ名を GET するような方法を議論したばかりですが、 変に環境変数を取得しようとするよりも （しかも全く一般性がない外部プログラムを利用して始めて得られるような環境変数を）、 素直に必要なドライブ名を得る（何ならば初期環境設定として TBL ファイルや 変数ファイル に保存しておけばよい） 方法を考えた方が、前向きで汎用性があって有益ではないのでしょうか？
14044	Re:環境変数の基本	pokopon	2001/11/18-16:04
記事番号14043へのコメント Ogoさん こんにちは いつも貴重なご意見をいただきありがとうございます。 >先日もフロッピーのドライブ名を GET するような方法を議論した >ばかりですが、変に環境変数を取得しようとするよりも（しかも >全く一般性がない外部プログラムを利用して始めて得られるよう >な環境変数を）、素直に必要なドライブ名を得る（何ならば初期 >環境設定として TBL ファイルや 変数ファイル に保存しておけば >よい）方法を考えた方が、前向きで汎用性があって有益ではない >のでしょうか？ ごもっともです。すいません。勉強になりました。
14051	環境変数の基本多少理解が？	A. I.	2001/11/18-20:14
記事番号14043へのコメント Ogoさんが、Re:環境変数の基本」で書かれた文を読んで やっとバッチファイルでは、反映されるものが、 システムコマンド＋#GETENV関数では、取り込めないかの 基本がわかりました。 >先日もフロッピーのドライブ名を GET するような方法を議論した >ばかりですが、変に環境変数を取得しようとするよりも（しかも >全く一般性がない外部プログラムを利用して始めて得られるよう >な環境変数を）、素直に必要なドライブ名を得る（何ならば初期 >環境設定として TBL ファイルや 変数ファイル に保存しておけば >よい）方法を考えた方が、前向きで汎用性があって有益ではない >のでしょうか？ > 言い訳をするようですが、実は、MS-DOSVer.5で動く中古パソコンを 店舗内に２台、事務所に１台、自宅に１台と置いて、事務所や自宅で 一括処理の手直しなどやったものを店舗の２台にコピーして使用しています。 中古なので、HDDやFDDの構成がばらばらです。 最初は、環境設定用の表をそれぞれに用意していましたが、 中古なので結構パソコンがハングアップしたりします。 その場合、即予備のものと入れ替えて使えるように設定をするわけですが、 急いで設定をした時に限って、設定ミスをしてしまいます。 ある時、データが、どのディレクトリにあっても#ファイル検索で &パスに設定するよう一括処理を修正したら、緊急時に随分楽に パソコンの入れ替えが出来たので、 この際、何も考えずに桐のデータさえコピーすれば、 動くようにならないかと考えた訳です。
14052	Re:環境変数の基本多少理解が？	Ogo	2001/11/18-20:52
記事番号14051へのコメント >ある時、データが、どのディレクトリにあっても#ファイル検索で >&パスに設定するよう一括処理を修正したら、緊急時に随分楽に >パソコンの入れ替えが出来たので、この際、何も考えずに桐の >データさえコピーすれば、動くようにならないかと考えた訳です。 この様な場合は #データパス名() #桐パス名() #環境設定() などを使い、ドライブ名が必要ならそこから冒頭の数文字を抜き出すと言う方法が有効です。
14054	Re:環境変数の基本多少理解が？	pokopon	2001/11/18-21:35
記事番号14051へのコメント A. I.さん　こんにちは >システムコマンド＋#GETENV関数では、取り込めないかの ということではありません。 細かい事をいうと、 システムコマンドで実行したアプリによって設定した環境変数は、そのプロセス （すなわちそのシステムコマンドで実行中のＤＯＳ内）だけで有効で、 次のシステムコマンドでは「無効」になっており、#GETENV関数が 取り込みたくとも取り込めない（だって、無効となり設定されていないのだから）というのが正解です。 どのシステムコマンドからの実行でも参照できる環境変数を設定するには、 ＤＯＳの起動時（親プロセス）だけなので（できないこともないけど）、 autoexec.bat に記述する必要があるという事です。 あるいは、桐の起動をバッチファイル化し、そこに記述するとか。 であれば、#GETENV関数でも、取り込めます。 >環境設定用の表をそれぞれに用意していましたが、中古なので >結構パソコンがハングアッブしたりします。 中古だからハング？？？　パソコンの設定がまずい（メモリ設定など）だけかと　(^^ゞ >パソコンの入れ替えが出来たので、この際、何も考えずに桐の >データさえコピーすれば、動くようにならないかと考えた訳です。 DOSコマンドの「subst.exe」をご存知ですか？ c:>\ subst /? パスをドライブ名に割り当てます. 　　SUBST [ドライブ1:　[ドライブ2:]パス] 　　SUBST ドライブ1:　　/D 　　ドライブ1:　　　　　パスを割り当てる仮想ドライブを指定します. 　　 [ドライブ2:]パス　　仮想ドライブを割り当てる論理ドライブとパスを指定します. 　　/D　　　　　　　　SUBST された仮想ドライブを削除します. パラメータの指定がなければ, 現在の仮想ドライブの一覧を表示します. 例えば、あるパソコンのd:\dataに桐のデータを置く場合、 subst x: d:\data とすれば、d:\data　をドライブ「x:\」で参照できます。 すなわち、一括を「x:」から起動したと仮定して、ドライブ名全てをx:にしておきます。 桐から、「x:」を参照すれば「d:\data」の中が見える・実行できるという事になります。 全てのパソコンのautoexec.batにこのsubust をそのパソコンの環境に合わせて記述しておけば、 どのパソコンからでもドライブ「x:」で動く事になります。 パソコンを変えた段階で、たった１行だけautoexec.batに追加記述すれば、 今までと同じ環境で使えることになりませんか？どっちが楽でしょう。 面倒な他のアプリを使って環境変数を設定したり、桐で環境変数を取り込まなくとも、 同じ環境で桐のデータにアクセスできます。 お試し下さい。
14061	Re:Subst (茶々)	Ogo	2001/11/19-04:49
記事番号14054へのコメント >例えば、あるパソコンのd:\dataに桐のデータを置く場合、 >subst x: d:\data >とすれば、d:\data　をドライブ「x:\」で参照できます。 私も重宝しているんだが…… MS-DOS と　Win 95 以降では挙動が違うんですよねぇ〜 上記の場合、 Win 95 以降では、 X: にも d:\data にもアクセスできるんだが、 MS-DOS では d:\data にはアクセスできなくなってしまう…… 私自身は、それ故に、 MS-DOS では Subst を使ってない。 (^^;;
14062	Re:Subst (茶々)	hidetake	2001/11/19-07:07
記事番号14061へのコメント SUBST は私も Windows9x までは常用していました。 と言うか、ノートは未だに Windows98 だから使用しています。 自分の場合は、遠い昔から作業ドライブは L: として設定していて 昔は RAM ドライブを割り当てていましたが、 RAM ドライブを使わない時代になっても SUBST で L: を割り当て使っております。 何せ体がそれに慣れていますので・・・ ただ、SUBST を使う上で注意すべき事がありまして SUBST でドライブを割り振って、そこを環境変数 TMP(TEMP) で設定する作業ドライブとして使用する場合、 そのドライブがルートドライブであると、 桐のインストーラは正常に動作しません。 桐のインストーラだけが不具合を起こすのですが、 桐のインストーラを起動する場面のみ SUBST を 外す必要があります。 これはお月見バージョン以来、現在も改善されておりません。 例 SUBST L: D:\TMP SET TMP=L:\
14063	Re:Subst (茶々)	Ogo	2001/11/19-11:30
記事番号14062へのコメント >SUBST は私も Windows9x までは常用していました。 > >と言うか、ノートは未だに Windows98 だから使用 >しています。 私は NT4 でも \WINNT\system32\Repl\Import\Scripts\ に Subst_NT.BAT を作ってログオン時に利用しています。 (^^)
14065	Re:Subst (茶々)	hidetake	2001/11/19-12:02
記事番号14063へのコメント >私は NT4 でも \WINNT\system32\Repl\Import\Scripts\ >に Subst_NT.BAT を作ってログオン時に利用しています。 (^^) さすがに私は NT系(2000) では使いませんねえ〜 NT系だとドライブが自由にマップできるし・・・　(^_^;
14066	Re:Subst (茶々)	Ogo	2001/11/19-13:25
記事番号14065へのコメント >さすがに私は NT系(2000) では使いませんねえ〜 >NT系だとドライブが自由にマップできるし・・・　(^_^; マルチ OS ブートマシンなので、ドライブ構成を Win 98 と同一にするために…… です。 (^^)
14070	Re:Subst (茶々)	hidetake	2001/11/19-14:04
記事番号14066へのコメント >マルチ OS ブートマシンなので、ドライブ構成を Win 98 >と同一にするために…… です。 (^^) 別に回答が１つである必要はないけど ディスクアドミニストレ ータでドライブを任意に割り当てたり、 NT系であればネットワークドライブとして 自分自身のドライブを割り当てる事でも可能なのでは？

戻る