8
Mklink und sein Nutzen
Moin,
mklink macht mich noch verrückt.
Ich würde gerne bei Win-R ein Programmnamen oder eine Datei eingeben und das Programm/Datei wird aufgerufen. Wenn ich den Pfad mit angebe, klappt alles ziemlich gut, aber wehe, man lässt den weg.
Frage 1: Wo sucht Win-R, wenn man da etwas eingibt?
Ansatz: Ich hoffe, dass Win-R in allen Verzeichnissen sucht, die unter %path definiert sind, also sagte ich mir: Was ich aufrufen will, sich davon die EXE aber (logischerweise) nicht in einem Verzeichnis befindet, das in %path enthalten ist, lege einfach im Verzeichnis "D:\DOS" mit mklink sowas wie
mklink D:\DOS\RegJump.exe F:\Tools\RegJump\RegJump_x64.exe
an. (Info: Das Verzeichnis D:\DOS ist bei mir historisch bedingt seit DOS 2.1 auf allen Privat-Blechen mit in %path eingebunden)
Unter W10 lässt sich der 'mklink' erst gar nicht gar setzen (vermutlich werde ich dort das privilegiert machen müssen), aber unter Win7 wird der sauber link angelegt. Aber:
Frage 2: Warum klappt der Aufruf des links mal und mal nicht?
Denn seltsames passiert bei der Ausführung:
- Wenn ich in einer CMD-Umgebung 'D:\DOS\RegJump.exe' aufrufe, wird sauber 'F:\Tools\RegJump\RegJump_x64.exe' ausgeführt. Läuft, wie es soll. Auch wenn das laufende Programm glaubt, eigentlich 'D:\DOS\RegJump.exe' zu hießen und daher auch seine INI nicht findet.
- Wenn ich 'D:\DOS\RegJump.exe' per Win-R aufrufe oder die Datei direkt doppelklikcke, wirft er einen Fehler: "Der angegebene Pfad ist nicht vorhanden". Natürlich sind beide Pfade vorhanden, Quelle als auch Ziel. Trotzdem: s. Bild
Daher nochmal beide Fragen:
Frage 1: Wo sucht Win-R, wenn man da etwas eingibt?
Frage 2: Warum klappt der Aufruf des links mal und mal nicht?
mklink macht mich noch verrückt.
Ich würde gerne bei Win-R ein Programmnamen oder eine Datei eingeben und das Programm/Datei wird aufgerufen. Wenn ich den Pfad mit angebe, klappt alles ziemlich gut, aber wehe, man lässt den weg.
Frage 1: Wo sucht Win-R, wenn man da etwas eingibt?
Ansatz: Ich hoffe, dass Win-R in allen Verzeichnissen sucht, die unter %path definiert sind, also sagte ich mir: Was ich aufrufen will, sich davon die EXE aber (logischerweise) nicht in einem Verzeichnis befindet, das in %path enthalten ist, lege einfach im Verzeichnis "D:\DOS" mit mklink sowas wie
mklink D:\DOS\RegJump.exe F:\Tools\RegJump\RegJump_x64.exe
an. (Info: Das Verzeichnis D:\DOS ist bei mir historisch bedingt seit DOS 2.1 auf allen Privat-Blechen mit in %path eingebunden)
Unter W10 lässt sich der 'mklink' erst gar nicht gar setzen (vermutlich werde ich dort das privilegiert machen müssen), aber unter Win7 wird der sauber link angelegt. Aber:
Frage 2: Warum klappt der Aufruf des links mal und mal nicht?
Denn seltsames passiert bei der Ausführung:
- Wenn ich in einer CMD-Umgebung 'D:\DOS\RegJump.exe' aufrufe, wird sauber 'F:\Tools\RegJump\RegJump_x64.exe' ausgeführt. Läuft, wie es soll. Auch wenn das laufende Programm glaubt, eigentlich 'D:\DOS\RegJump.exe' zu hießen und daher auch seine INI nicht findet.
- Wenn ich 'D:\DOS\RegJump.exe' per Win-R aufrufe oder die Datei direkt doppelklikcke, wirft er einen Fehler: "Der angegebene Pfad ist nicht vorhanden". Natürlich sind beide Pfade vorhanden, Quelle als auch Ziel. Trotzdem: s. Bild
Daher nochmal beide Fragen:
Frage 1: Wo sucht Win-R, wenn man da etwas eingibt?
Frage 2: Warum klappt der Aufruf des links mal und mal nicht?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 53299645886
Url: https://administrator.de/forum/mklink-und-sein-nutzen-53299645886.html
Ausgedruckt am: 22.12.2024 um 02:12 Uhr
8 Kommentare
Neuester Kommentar
Moin,
Du musst den Pfad zu deinem Programm in die %PATH%-Variable hinzufügen (und nicht mit dem Pfad überschreiben).
Danach kannst du dein Programm mit
Du musst den Pfad zu deinem Programm in die %PATH%-Variable hinzufügen (und nicht mit dem Pfad überschreiben).
Danach kannst du dein Programm mit
RegJump.exe ausführen.
Zwar danke ich dir für deine Antwort, aber sie passt nicht zu den beschriebenen Problemen. Und ich weiß, wie man path korrekt nutzt, da ich ich das seit DOS 2.1 nutze, wie beschrieben, daher "überschreibe" ich auch nichts in path. Außerdem ist ja "D:\DOS\" in path enthalten, seit Jahrzehnten und wird auch gefunden, daher verstehe ich ja den
Fehler nicht.
Lies gerne nochmal Frage 2. Da geht es um Win-R- und um Doppelklick-Aufruf. DAS geht schief!
Fehler nicht.
Lies gerne nochmal Frage 2. Da geht es um Win-R- und um Doppelklick-Aufruf. DAS geht schief!
Hallo,
Gruß,
Peter
Zitat von @-webu-:
Lies gerne nochmal Frage 2. Da geht es um Win-R- und um Doppelklick-Aufruf. DAS geht schief!
Mal gehts, mal gehts nicht. Was wurde dazwischen tatsächlich gemacht/Verändert? Was steht im Ereignissprotokoll?Lies gerne nochmal Frage 2. Da geht es um Win-R- und um Doppelklick-Aufruf. DAS geht schief!
Gruß,
Peter
Mal gehts, mal gehts nicht. Was wurde dazwischen tatsächlich gemacht/Verändert? Was steht im Ereignissprotokoll?
Bei Doppelklick- und über Win-R-Aktion geht's nicht, siehe Fehler-Meldung im Eröffnungspost. Aber bei Aufruf in der CMD-Umgebung klappt es wie erwartet. Steht auch alles im Eröffnungspost.
Ähm DOS? Unter Windows 7 bzw. Windows 10?
Seit NT4 gibt es kein DOS (command.com) mehr. Sondern das ist die CMD.EXE! Und das ist KEIN DOS!
Gruss Penny.
Seit NT4 gibt es kein DOS (command.com) mehr. Sondern das ist die CMD.EXE! Und das ist KEIN DOS!
Gruss Penny.
Moin,
Hab das hier gerade mal nachgestellt, Doppelklick ging auf Anhieb, nach setzen der Systemvariable PATH auch WIN+R -> Eingabe 'regjump'
Und ebenfalls korrekt: unter Win10 kann man nur als Admin mit erhöhten Rechten mit mklink den Link setzen. Beim Aufruf werden dann die erhöhten Rechte auch angefordert.
Gruß und guten Rutsch
cykes
P.S. Unter Win7 kann ich gerade nicht testen, da nicht vorhanden, sollte aber eigentlich auch dort so passen.
Zitat von @-webu-:
Außerdem ist ja "D:\DOS\" in path enthalten, seit Jahrzehnten und wird auch gefunden, daher verstehe ich ja den
Fehler nicht.
Vermutlich liegt genau da einer der Fehler, zum einen schreibst Du nicht, in welcher PATH-Variable Du den Pfad eingetragen hast - Benutzer oder System -> es braucht nur in der Systemvariable PATH zu stehen, damit WIN+R klappt, damit genügt dann in WIN+R auch die Eingabe von (nur) "regjump"; zum anderen ist die Schreibweise der Pfadangabe "D:\DOS\" falsch, es darf kein \ am Ende stehen -> korrekt wäre also "D:\DOS".Außerdem ist ja "D:\DOS\" in path enthalten, seit Jahrzehnten und wird auch gefunden, daher verstehe ich ja den
Fehler nicht.
Lies gerne nochmal Frage 2. Da geht es um Win-R- und um Doppelklick-Aufruf. DAS geht schief!
Der Doppelklick-Aufruf sollte eigentlich auch ohne PATH-Variable immer funktionieren.Hab das hier gerade mal nachgestellt, Doppelklick ging auf Anhieb, nach setzen der Systemvariable PATH auch WIN+R -> Eingabe 'regjump'
Und ebenfalls korrekt: unter Win10 kann man nur als Admin mit erhöhten Rechten mit mklink den Link setzen. Beim Aufruf werden dann die erhöhten Rechte auch angefordert.
Gruß und guten Rutsch
cykes
P.S. Unter Win7 kann ich gerade nicht testen, da nicht vorhanden, sollte aber eigentlich auch dort so passen.
Wie @cykes schon sagt den Unterschied zwischen den Variablen-Arten beachten. Ggf. auch mal abmelden oder Maschine durchstarten. Bei der Konsolen ist sonst ein beliebter Fehler, dass die Einstellungen in neuer Sitzun nicht wirken.
Wie auch immer. INI nicht gefunden? mklink kennt auch hard links. Ich habs nur überflogen, aber hard links würden auch nicht vorhandene INI Dateien verhindern. Man gaukelt der Software vor, dass z.B. alles noch unter C: liegt. Dabei sind wir auf D:, E: oder F: unterwegs.
mklink unter Windows 7 und 10 kein Problem! Elevated Konsole beachten. Wir hatten Windows 7 POS Systeme. Die Scripte ließen sich teils 1:1 auf Windows 10 übertragen. Auch die Erstellung von Hard Links hat sich hier nicht geändert.
Unter Windows 10 nimmt man mitunter gar nicht mehr Win + R. Windows Taste und tippen reicht. Die Suche schlägt Treffer vor und das war es. Diese Suche ist aber nur bedingt mit Win + R vergleichbar.
https://learn.microsoft.com/de-de/windows/powertoys/run
PowerToys gibt es schon lange. Bei Windos 7 hat ich die übersprungen ^^ Ggf. kann das die Lücken hier noch füllen und für ein gleiches Verhalten auf beiden Systemen sorgen.
Wie auch immer. INI nicht gefunden? mklink kennt auch hard links. Ich habs nur überflogen, aber hard links würden auch nicht vorhandene INI Dateien verhindern. Man gaukelt der Software vor, dass z.B. alles noch unter C: liegt. Dabei sind wir auf D:, E: oder F: unterwegs.
mklink unter Windows 7 und 10 kein Problem! Elevated Konsole beachten. Wir hatten Windows 7 POS Systeme. Die Scripte ließen sich teils 1:1 auf Windows 10 übertragen. Auch die Erstellung von Hard Links hat sich hier nicht geändert.
Unter Windows 10 nimmt man mitunter gar nicht mehr Win + R. Windows Taste und tippen reicht. Die Suche schlägt Treffer vor und das war es. Diese Suche ist aber nur bedingt mit Win + R vergleichbar.
https://learn.microsoft.com/de-de/windows/powertoys/run
PowerToys gibt es schon lange. Bei Windos 7 hat ich die übersprungen ^^ Ggf. kann das die Lücken hier noch füllen und für ein gleiches Verhalten auf beiden Systemen sorgen.
Zitat von @Penny.Cilin:
Ähm DOS? Unter Windows 7 bzw. Windows 10?
Seit NT4 gibt es kein DOS (command.com) mehr. Sondern das ist die CMD.EXE! Und das ist KEIN DOS!
Du liebe Zeit, Penny, echt jetzt? Darum geht es dir, ernsthaft? Ähm DOS? Unter Windows 7 bzw. Windows 10?
Seit NT4 gibt es kein DOS (command.com) mehr. Sondern das ist die CMD.EXE! Und das ist KEIN DOS!
Außerdem schrieb ich von der "CMD-Umgebung". Und warum der Ordner D:\DOS heißt, ist einerseits völlig egal und andererseits auch erläutert. Dieser Ordner ist absichtlich schon in %path enthalten, weil dadurch eben vieles dort auch gefunden wird. Ich könnte ihn aber auch E:\EinPennyMachtNochkeinCilin nennen und in %path einbinden.
Zitat von @cykes:
Klar, danke für den Hinweis. Habe extra eben nochmal geguckt, aber ich trage schon immer absichtlich alles, was unter allen Usern funktionieren sollte, in %path des Systems ein und natürlich ohne den '\' am Ende. Auch schon immer! Zitat von @-webu-:
Außerdem ist ja "D:\DOS\" in path enthalten, seit Jahrzehnten und wird auch gefunden, daher verstehe ich ja den Fehler nicht.
Vermutlich liegt genau da einer der Fehler, zum einen schreibst Du nicht, in welcher PATH-Variable Du den Pfad eingetragen hast - Benutzer oder System -> es braucht nur in der Systemvariable PATH zu stehen, ...Außerdem ist ja "D:\DOS\" in path enthalten, seit Jahrzehnten und wird auch gefunden, daher verstehe ich ja den Fehler nicht.
Der Doppelklick-Aufruf sollte eigentlich auch ohne PATH-Variable immer funktionieren.
Eben. DAS isses ja, was ich unter W7 nicht verstehe. Und die Fehlermeldung passt nicht zum Problem, weil ja diese Pfade da sind. Vermutlich hängt das tatsächlichen mit den Rechten zusammen, die der link (nur) hat. Das ist wieder dieses "Wir nehmen mal irgendeinen fuzzy-Fehlertext, er muss ja nicht zum Fehler passen." MS halt. 
Hab das hier gerade mal nachgestellt, Doppelklick ging auf Anhieb, nach setzen der Systemvariable PATH auch WIN+R -> Eingabe 'regjump'
Unter W10 habe ich den link schnell mal als Admin mit erhöhten Rechten gesetzt und jetzt klappt da alles wie bei dir.Zitat von @Crusher79:
INI nicht gefunden? mklink kennt auch hard links. Ich habs nur überflogen, aber hard links würden auch nicht vorhandene INI Dateien verhindern. Man gaukelt der Software vor, dass z.B. alles noch unter C: liegt. Dabei sind wir auf D:, E: oder F: unterwegs.
Dass das link-Verzeichnis das aktuelle Verzeichnis ist, ist ja konzeptionell so gedacht, daher könnte mein Ansatz, alle möglichen installierten Programme mit dem tippen des Programmnamens zu starten, indem ich die alle in einem Verzeichnis per mklink verlinke, entweder kein guter Ansatz oder ich muss über echte links mittels .LNK nachdenken. Dann passt alles auch am Ziel.INI nicht gefunden? mklink kennt auch hard links. Ich habs nur überflogen, aber hard links würden auch nicht vorhandene INI Dateien verhindern. Man gaukelt der Software vor, dass z.B. alles noch unter C: liegt. Dabei sind wir auf D:, E: oder F: unterwegs.
Spannend dabei ist für mich aber trotzdem, dass wir als Programmierer ja eigentlich an den Pfad und Namen der eigenen Anwendung rankommen und das ist dann etwas konfus, was man da bekommt. Da muss ich nochmal dran, vielleicht nehme ich auch die falschen Objekte zum ermitteln. Wenn ich einen link hinz.exe auf kunz.exe anlege, ist es interessant, was die Anwendung darüber sagt, wie sie tätsächlich/angeblich heißt
Unter Windows 10 nimmt man mitunter gar nicht mehr Win + R. Windows Taste und tippen reicht. Die Suche schlägt Treffer vor und das war es. Diese Suche ist aber nur bedingt mit Win + R vergleichbar.
Die W10-Suche ist tatsächlich nicht so gut vergleichbar, weil sie ab W1x auch Internet-Ergebnisse berücksichtigt. Wenn man schnelles Arbeiten gewohnt ist und z. B auf einem System ein bestimmtes Programm noch gar nicht installiert ist, kann man trotzdem was mit der passenden Eingabe "finden", was man aber gar nicht will.https://learn.microsoft.com/de-de/windows/powertoys/run
PowerToys gibt es schon lange. Bei Windos 7 hat ich die übersprungen ^^ Ggf. kann das die Lücken hier noch füllen und für ein gleiches Verhalten auf beiden Systemen sorgen.
Ja, der Vorteil dieser third-partys ist, dass sie unter unterschiedlichen Systemen trotzdem gleich bedient werden.PowerToys gibt es schon lange. Bei Windos 7 hat ich die übersprungen ^^ Ggf. kann das die Lücken hier noch füllen und für ein gleiches Verhalten auf beiden Systemen sorgen.
Grundsätzlich ist es meist so, dass "ordentlich installierte" Programme auch per Win-R etc. zu finden sind. Schwierig wird es erst, wenn man kleine nützliche Tools in einem eigenen kleinen Ordner unter einem Haupt-Ordner D:\Tools anlegt. Um die schnell key-driven erreichen zu können, habe ich kein Interesse daran, jeden dieser kleinen Mini-Ordner ebenfalls in %path einzutragen, daher all diese obigen "Überlegungen" nach einer Alternative.
Ich fände es spannend, dass eben die Eingabe von 'RegJump' eben RegJump dort startet, wo es liegt ('RegJump' nur als Beispiel). Dabei sei es egal, ob ich das unter einer CMD, in einem CMD-Batch. PowerShell oder in der Windows-Leisten-Suche eingebe.
Frohes neues Jahr euch allen!
