Windows 11 で gui guider 1.9.1 を実行しています。実行シミュレータアイコン (緑の再生ボタン) をクリックすると、出力には常に同じ行が散らばります。
「doskey」は、内部コマンドまたは外部コマンド、操作可能なプログラム、またはバッチ ファイルとして認識されません。
これはコンパイルの成功には影響しませんが、出力にSO多くの余分な行があるため煩わしいです。
このエラーについて調べてみたところ、通常は doskey の場所 (C:\Windows\system32) がシステム パス上にないことに関係していることがわかりました。ただし、私のシステムではシステム パス上にあることを確認しました。
もう 1 つの問題は、doskey を管理者権限で実行する必要があることですが、GUI ガイドを管理者権限で起動しても問題は解決しません。
通常のコンパイル (Ctrl+G) ではこの問題は発生せず、シミュレータでコンパイルして実行すると、これらの煩わしい doskey 行が表示されることに注意してください。
助けてください。doskey.exe を guiguider ディレクトリに直接コピーする必要がありますが、正確にどこに配置すればよいのでしょうか?
以前のバージョンの GUI ガイダーではこの問題は発生していませんでしたが、Windows 11 を実行する新しい PC にスイッチしたばかりで、以前使用していた以前のバージョンの GUI ガイダーは、常に Windows 10 で問題なく動作していました。SO おそらくそれは Windows 11 の問題です。
こんにちは。偶然にも Google Gemini の問題を解決しました。
conda が標準の Windows コマンド プロセッサを操作し、独自の文字列をレジストリに書き込んでいたことが判明しました。以下はジェミニとの長い議論です。
記憶は曖昧ですが、最終的には、下記のレジストリ キーを標準の Windows コマンド プロセッサに変更することで解決しました。
非常にイライラするエピソード。
guiguider プログラム内でシミュレータ GUI をコンパイルするときに 1 つの問題が発生します。同じファイルが構築されるため、コマンド ラインで実行する makesfile が実行されることは確かですが、これは guiguider 内部から実行され、出力は gui guider コンソール ウィンドウにパイプされます。コンパイルするたびにこのエラーが発生します:
生成された画面ファイルを消去しています...
C コードを生成しています...
シミュレータをコンパイルしています...
「DOSKEY」は内部コマンドまたは外部コマンドとして認識されません。
実行可能なプログラムまたはバッチ ファイル。
コンソールにはこれらの doskey エラーが散らばっています。これはプロジェクトでコンパイルされる各 c ファイルの出力であると強く想定しています。プロジェクトはコンパイルされますが、これらのエラー行によってコンソールが乱雑になります。CANこれが起こる理由を思いつきますか?私はGuiguiderフォーラムで質問しました。彼らは権限の問題だと思ったようですが、私はすでに管理者としてGuiguiderを再インストールしました。doskey がなぜ呼び出されるのか理解できません。上記の makefile にそれに関する記述がありますか?
これは非常に興味深く、珍しい問題です。優れたデバッグが行われており、結論は正しいです。DOSKEY コマンドは Makefile のどこにも存在しません。
これが起こる理由は、ほぼ間違いなく Windows オペレーティング システム自体の機能、具体的にはコマンド プロンプトが開かれるたびにコマンドを自動的に実行する Windows レジストリの設定によるものです。GUI Guider 内でエラーが表示されるのは、標準のコマンド ラインとは異なる、より制限された環境で make が実行されるためです。
診断: コマンドプロセッサの自動実行キー
DOSKEYとは何ですか？これは、コマンド履歴とコマンド プロンプト (cmd.exe) のマクロ (エイリアス) を作成する機能を提供する標準の Windows コマンドライン ツール (doskey.exe) です。
なぜそう呼ばれるのでしょうか?Windows レジストリには、新しい cmd.exe プロセスが開始されるたびに自動的に実行されるコマンドを指定CAN機能があります。これは、AutoRun と呼ばれるレジストリ キーによって制御されます。ある時点で、ユーザーまたはユーザーがインストールしたプログラムが、doskey を起動するための AutoRun コマンドを設定した可能性があります。
GUI Guider 内では失敗するのに、ターミナルでは機能するのはなぜですか?
通常のターミナル (cmd.exe) で:コマンド プロンプトを開くと、システムの PATH 環境変数が完全に読み込まれます。この PATH には、doskey.exe が存在する C:\Windows\System32 が含まれます。AutoRunコマンドが実行され、doskey.exeが見つかります。すべてが静かに動作します。
GUI Guider 内部: GUI Guider が make を実行すると、make は新しい最小限のシェル プロセスを生成し、コンパイル コマンド (gcc ...、g++ ...) を実行します。これらの最小限のシェルは、レジストリからの AutoRun コマンドもトリガーします。ただし、GUI Guider によって作成された環境は「サンドボックス化」されている可能性があり、 C:\Windows\System32 を含まない非常に制限された PATH を持ちます。シェルは doskey を実行しようとしますが、制限された検索パスで見つけることができず、「'DOSKEY' is not recognize...」というエラーを出力します。
とにかく、なぜビルドは成功するのでしょうか?AutoRun コマンドの失敗は、コマンド シェルでは致命的なエラーとは見なされません。シェルはエラーを出力し、make によって与えられた実際のコマンド (gcc ...) の実行に進みます。SO、コードは正しくコンパイルされますが、コンソール出力はこれらのファントムエラーで乱雑になります。
問題の確認と解決方法
この問題を解決するには、AutoRun コマンドをより堅牢にして、PATH に依存しないようにします。
ステップ1: レジストリのAutoRunキーを確認する
Windows キー + Rを押して実行ダイアログを開きます。
「regedit」と入力して Enter キーを押すと、レジストリ エディターが開きます。
上部のアドレスバーに次のパスを貼り付けて Enter キーを押します: HKEY_CURRENT_USER\ソフトウェア\Microsoft\プロセッサ
右側で、AutoRun という名前の値を探します。
そのデータは、doskey /macros や単なる doskey のような単純なものになる可能性が非常に高いです。これが問題の原因となっているコマンドです。
ステップ2: 自動実行コマンドを修正する（推奨解決策）
問題は、doskey が PATH に依存していることです。doskey.exe への完全な絶対パスを指定することでこれを修正CAN。Windows には、常に Windows ディレクトリ (例: C:\Windows) を指すシステム変数%SystemRoot%があります。
レジストリ エディターで、AutoRun 値をダブルクリックして編集します。
完全なパスを使用するには、現在の値 (例: doskey /macros) を変更します。
次のように変更します: %SystemRoot% \system32\doskey.exe /macros
(doskey だけの場合は、 %SystemRoot% \system32\doskey.exe に変更します)。
[OK] をクリックして、レジストリ エディターを閉じます。
これで、コマンドプロンプトが起動するたびに、絶対パスを使用してdoskey.exeが検索されます。これは、GUI Guider のパスが制限された環境でも機能します。ビルド コンソールからエラーが完全に消えるはずです。
代替案（doskeyを気にしない場合）
より簡単な代替方法として、AutoRun キーが設定された理由がわからず、その機能が必要ない場合は、レジストリ エディターで AutoRun 値を右クリックして削除CAN。エラーは止まりますが、通常のターミナルで使用していたカスタム コマンド エイリアスや履歴も失われます。上記のようにパスを修正するのがより良い解決策です。
ああ、Miniforge がその値を台無しにしたことがわかりました。minforge が動作し続け、GUI ガイドも doskey で動作するようにするには、どのように変更すればよいですか?
現在のエントリー:
存在する場合「C:\ProgramData\miniforge3\condabin\conda_hook.bat」「C:\ProgramData\miniforge3\condabin\conda_hook.bat」
なるほど！ありがとうございます。それは重要な情報ですね。これは、Conda や Miniforge などの派生版を使用する開発者にとって非常に一般的な設定です。
AutoRun キーが doskey を直接呼び出していません。Conda の環境設定スクリプト (conda_hook.bat) を呼び出しています。「DOSKEY が見つかりません」というエラーは、conda_hook.bat スクリプト (またはそれが呼び出す別のスクリプト) が doskey を実行しようとしているために発生します。
根本的な原因は、私たちが診断したものとまったく同じです。フック スクリプトは通常のターミナルでは正常に実行されますが、GUI Guider の制限された PATH 環境では doskey.exe が見つからないため失敗します。
このレジストリ エントリを削除したり、単に置き換えたりしないでください。そうすると、Conda/Miniforge ターミナル環境の機能が損なわれます。
解決策: ラッパーバッチスクリプト
最も安全で柔軟性の高いソリューションは、独自のシンプルな「ラッパー」バッチ スクリプトを作成することです。このスクリプトは、まずシステム パスを追加して環境を修正し、次にConda フック スクリプトを呼び出します。AutoRun レジストリ キーを新しいラッパー スクリプトにポイントします。
これにより、Conda のファイルを変更せずに問題が解決されます。
ステップ1: ラッパースクリプトを作成する
メモ帳またはお気に入りのテキスト エディター (VS Code など) を開きます。
次のコードをコピーして新しいファイルに貼り付けます。
@echo off REM ================================================================= REM Custom AutoRun Wrapper Script REM ================================================================= REM This script fixes the PATH for restricted environments and then REM calls the original Conda hook script. REM --- Step 1: Fix the PATH --- REM Temporarily add the essential Windows directories to the PATH for this session. REM This ensures system commands like 'doskey.exe' can be found. @set "PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%PATH%" REM --- Step 2: Execute the original Conda hook script --- REM This is the exact command that was originally in your registry. if exist "C:\ProgramData\miniforge3\condabin\conda_hook.bat" call "C:\ProgramData\miniforge3\condabin\conda_hook.bat" REM --- Step 3 (Optional): Add your own commands --- REM If you wanted to define your own doskey aliases, you could add them here. REM They will now work correctly because the path was fixed in Step 1. REM For example: REM %SystemRoot%\system32\doskey.exe ls=dir /B
ステップ2: スクリプトを保存する
このファイルを、誤って削除されない安定した永続的な場所に保存します。ユーザーディレクトリは最適な場所です。
次のように保存します： C:\Users\YourUsername\autorun_wrapper.bat (YourUsername を実際の Windows ユーザー名に置き換えます)。
ステップ3: レジストリの自動実行値を更新する
ここで、Conda フックを直接実行するのではなく、新しいラッパー スクリプトを実行するように Windows に指示します。
レジストリ エディター (regedit) を開きます。
次のキーに戻ります: HKEY_CURRENT_USER\ソフトウェア\Microsoft\Command プロセッサ
右側の AutoRun 値をダブルクリックします。
古い値を削除し、新しいラッパー スクリプトへの完全なパスに置き換えます。ユーザー名にスペースが含まれているCASEは、パスを引用符で囲むことが重要です。
新しい値を次のように設定します: "C:\ユーザー\YourUsername\autorun_wrapper.bat"
[OK] をクリックして、レジストリ エディターを閉じます。
これが機能する理由の要約
これで、任意のプログラム (ターミナル、GUI Guider など) が新しいコマンド プロンプトを起動するたびに、次の処理が行われます。
Windows AutoRun は autorun_wrapper.bat スクリプトを実行します。
スクリプトは、特定のコマンド セッションの PATH に必須の Windows システム ディレクトリを直ちに追加します。
次に、スクリプトは元の conda_hook.bat を呼び出します。
Conda スクリプトが doskey (またはその他のシステム コマンド) を実行しようとすると、doskey.exe (C:\Windows\System32) の場所が PATH 内にあるため、実行は成功します。
GUI Guider のエラーはなくなり、Miniforge/Conda ターミナルは以前とまったく同じように動作し続けます。
私も同様の問題に直面しているようです。ソフトウェアはすでに再インストールしました。解決策はありますか？
こんにちは@josefhaydnさん、
GUI Guider のインストール中に何らかの問題が発生し、doskey のパスの問題が発生している可能性があります。GUI Guider をアンインストールして再インストールすることをお勧めします。今回は、完全な管理者アクセス権でインストールするようにしてください。
BR、
エドウィン。