21
Windows 10 (1703) - Powershell und Eingabeaufforderung im Kontextmenü
Hallo,
mit dem Creators-Update für Windows 10 verschwindet die Eingabeaufforderung aus dem Kontextmenü des Explorers ([Shift]+Rechtsklick) und statt dessen erscheint dort Powershell.
Nichts gegen PowerShell, aber die Eingabeaufforderung möchte ich dort nicht missen.
Ich möchte dort Beides zur Auswahl haben:
Da Windows 10 für die Bedienung per Touchscreen optimiert ist, lässt sich das ganz einfach einstellen.
(Der Satz ist irgendwo zwischen Ironie und Sarkasmus einzuordnen.)
Diese Einstellung muss, wie so viele andere auch, über die Registry vorgenommen werden.
Im Netz finden sich reichlich Seiten, die beschreiben welche Reg-Werte wie zu setzen sind, um das Kontextmenü diesbezüglich wuschgemäß einzustellen.
Ich weiß nicht mehr wo ich fündig wurde, ich wollte nur erwähnen, dass ich die Schlüssel nicht selbst erkundet habe.
Auf die relevanten Schlüssel haben Administratoren zunächst nur lesenden Zugriff und können das auch nicht ändern, da der Besitzer dieser Schlüssel "TrustedInstaller" ist.
Man muss daher zunächst den Besitz übernehmen, dann die Zugriffsrechte auf Vollzugriff für Administratoren erweitern und kann anschließend den Besitz an "TrustedInstaller" zurückgeben.
Danach ist man berechtigt die Werte als Administrator zu ändern.
Da es sich um sechs Schlüssel handelt ist diese Rechteänderung manuell eine elende Klickerei.
Um das zu vereinfachen machte ich mich auf die Suche und fand das Tool SetACL.exe. (Vielen Dank an Helge Klein)
Syntaktisch ist das Tool nicht intuitiv und mit nur wenigen Beispielen ausgestattet, was dazu führte, dass ich zunächst ein paar Fehler machte und ein paar unbeabsichtigte Ergebnisse erzielte, was der Anlass war, diesen Tipp zu verfassen.
Beispielsweise kann für die Besitzübername "Administratoren" als neuer Besitzer angegeben werden, aber auf englischen Systemen gibts diese Gruppe nicht, dort heißt sie "Administrators".
Um SetACL sprachunabhängig zu verwenden kann die Gruppe der lokalen Administratoren mit dem "Namen" "S-1-5-32-544" bezeichnet werden.
Benötigt wird
Vorgehensweise
Einschränkung
Anmerkungen
Erweiterung
Rechtsklick / [Shift]-Rechtsklick
PowerShell_und_CMD.cmd
PowerShell_und_CMD.reg
Zu Risiken und Nebenwirkungen fragen Sie Ihren Administrator.
Gruß Frank
mit dem Creators-Update für Windows 10 verschwindet die Eingabeaufforderung aus dem Kontextmenü des Explorers ([Shift]+Rechtsklick) und statt dessen erscheint dort Powershell.
Nichts gegen PowerShell, aber die Eingabeaufforderung möchte ich dort nicht missen.
Ich möchte dort Beides zur Auswahl haben:
- PowerShell-Fenster hier öffnen
- Eingabeaufforderung hier öffnen
Da Windows 10 für die Bedienung per Touchscreen optimiert ist, lässt sich das ganz einfach einstellen.
(Der Satz ist irgendwo zwischen Ironie und Sarkasmus einzuordnen.)
Diese Einstellung muss, wie so viele andere auch, über die Registry vorgenommen werden.
Im Netz finden sich reichlich Seiten, die beschreiben welche Reg-Werte wie zu setzen sind, um das Kontextmenü diesbezüglich wuschgemäß einzustellen.
Ich weiß nicht mehr wo ich fündig wurde, ich wollte nur erwähnen, dass ich die Schlüssel nicht selbst erkundet habe.
Auf die relevanten Schlüssel haben Administratoren zunächst nur lesenden Zugriff und können das auch nicht ändern, da der Besitzer dieser Schlüssel "TrustedInstaller" ist.
Man muss daher zunächst den Besitz übernehmen, dann die Zugriffsrechte auf Vollzugriff für Administratoren erweitern und kann anschließend den Besitz an "TrustedInstaller" zurückgeben.
Danach ist man berechtigt die Werte als Administrator zu ändern.
Da es sich um sechs Schlüssel handelt ist diese Rechteänderung manuell eine elende Klickerei.
Um das zu vereinfachen machte ich mich auf die Suche und fand das Tool SetACL.exe. (Vielen Dank an Helge Klein)
Syntaktisch ist das Tool nicht intuitiv und mit nur wenigen Beispielen ausgestattet, was dazu führte, dass ich zunächst ein paar Fehler machte und ein paar unbeabsichtigte Ergebnisse erzielte, was der Anlass war, diesen Tipp zu verfassen.
Beispielsweise kann für die Besitzübername "Administratoren" als neuer Besitzer angegeben werden, aber auf englischen Systemen gibts diese Gruppe nicht, dort heißt sie "Administrators".
Um SetACL sprachunabhängig zu verwenden kann die Gruppe der lokalen Administratoren mit dem "Namen" "S-1-5-32-544" bezeichnet werden.
Benötigt wird
- SetACL.exe (Download)
- PowerShell_und_CMD.cmd (Copy/Paste)
- PowerShell_und_CMD.reg (Copy/Paste)
Vorgehensweise
- SetACL.exe, PowerShell_und_CMD.cmd und PowerShell_und_CMD.reg in einen Ordner kopieren
- PowerShell_und_CMD.reg anpassen, falls man PowerShell und CMD nicht in jeweils allen drei "Situationen" haben möchte
- PowerShell_und_CMD.cmd ausführen
- Fertig
Einschränkung
- Ob diese Methode auch bei Domänenmitglied-Rechnern funktioniert sollte vorab geprüft werden.
- Getestet und in Benutzung habe ich es nur mit Arbeitsgruppenrechnern.
- Nach Ausführung der CMD bleibt der Vollzugriff auf die Schlüssel für (lokale) Administratoren erhalten. Wenn man den urprünglichen Zustand (nur Lesen) wiederherstellen möchte, muss man in der CMD die vierte SetACL.exe-Zeile einkommentieren (REM entfernen).
Anmerkungen
- Die Umleitungen nach null und con sind nur Kosmetik und nicht funktionell relevant, sie können also entfernt oder angepasst werden.
- Der Import der Reg-Datei mittels "regedit /s" (s für silent) gibt keine eventuellen Fehler aus, auch nicht über errorlevel. Um eine Kontrolle zu erhalten kann man das /s entfernen, muss aber dann den Import per Mausklick bestätigen oder man strickt die CMD komplett auf reg.exe um, was mir aber in der Relation zum Nutzen zu mühselig war.
Erweiterung
- Die CMD kann mit weiteren Regschlüssel und weiteren Regdateien ergänzt werden, um weitere Einstellungen/Änderungen vornehmenzulassen.
Rechtsklick / [Shift]-Rechtsklick
- das Vorhandensein oder Nichtvorhandensein der leeren Zeichenfolge namens "Extended" entscheidet darüber ob der zugehörige Eintrag nur mit zusätzlicher [Shift]-Taste oder auch ohne angezeigt wird.
PowerShell_und_CMD.cmd
@echo off
:: Berechtigungen setzen
echo Berechtigungen setzen...
set gruppe=S-1-5-32-544
set vorbesitzer=NT SERVICE\TrustedInstaller
set regkey=HKCR\Directory\Background\shell\cmd
call :aendern
set regkey=HKCR\Directory\Background\shell\Powershell
call :aendern
set regkey=HKCR\Directory\shell\cmd
call :aendern
set regkey=HKCR\Directory\shell\Powershell
call :aendern
set regkey=HKCR\Drive\shell\cmd
call :aendern
set regkey=HKCR\Drive\shell\Powershell
call :aendern
:: Regdatei importieren
echo Regdatei importieren...
regedit /s "PowerShell_und_CMD.reg"
exit /b
REM **********************************************
:: Subroutine
:aendern
SetACL.exe -on "%regkey%" -ot reg -actn setowner -ownr "n:%gruppe%" 1>nul 2>con
SetACL.exe -on "%regkey%" -ot reg -actn ace -ace "n:%gruppe%;p:full" 1>nul 2>con
SetACL.exe -on "%regkey%" -ot reg -actn setowner -ownr "n:%vorbesitzer%" 1>nul 2>con
REM SetACL.exe -on "%regkey%" -ot reg -actn ace -ace "n:%gruppe%;p:read" 1>nul 2>con
goto :eof
REM **********************************************PowerShell_und_CMD.reg
Windows Registry Editor Version 5.00
; ----------------------------------
; Eingabeaufforderung im Kontextmenü
; ----------------------------------
; Bei Rechtsklick auf Ordner
[HKEY_CLASSES_ROOT\Directory\shell\cmd]
; anzeigen
"HideBasedOnVelocityId"=-
"ShowBasedOnVelocityId"=dword:00639bc8
; nicht anzeigen
;"HideBasedOnVelocityId"=dword:00639bc8
;"ShowBasedOnVelocityId"=-
; nur mit Shift anzeigen (default)
"Extended"=""
; auch ohne Shift anzeigen
;"Extended"=-
; Bei Rechtsklick auf freien Bereich
[HKEY_CLASSES_ROOT\Directory\Background\shell\cmd]
; anzeigen
"HideBasedOnVelocityId"=-
"ShowBasedOnVelocityId"=dword:00639bc8
; nicht anzeigen
;"HideBasedOnVelocityId"=dword:00639bc8
;"ShowBasedOnVelocityId"=-
; nur mit Shift anzeigen (default)
"Extended"=""
; auch ohne Shift anzeigen
;"Extended"=-
; Bei Rechtsklick auf Laufwerk
[HKEY_CLASSES_ROOT\Drive\shell\cmd]
; anzeigen
"HideBasedOnVelocityId"=-
"ShowBasedOnVelocityId"=dword:00639bc8
; nicht anzeigen
;"HideBasedOnVelocityId"=dword:00639bc8
;"ShowBasedOnVelocityId"=-
; nur mit Shift anzeigen (default)
"Extended"=""
; auch ohne Shift anzeigen
;"Extended"=-
; -------------------------
; Powershell im Kontextmenü
; -------------------------
; Bei Rechtsklick auf Ordner
[HKEY_CLASSES_ROOT\Directory\shell\Powershell]
; anzeigen
"HideBasedOnVelocityId"=-
"ShowBasedOnVelocityId"=dword:006698a6
; nicht anzeigen
;"HideBasedOnVelocityId"=dword:006698a6
;"ShowBasedOnVelocityId"=-
; nur mit Shift anzeigen (default)
"Extended"=""
; auch ohne Shift anzeigen
;"Extended"=-
; Bei Rechtsklick auf freien Bereich
[HKEY_CLASSES_ROOT\Directory\Background\shell\Powershell]
; anzeigen
"HideBasedOnVelocityId"=-
"ShowBasedOnVelocityId"=dword:00639bc8
; nicht anzeigen
;"HideBasedOnVelocityId"=dword:00639bc8
;"ShowBasedOnVelocityId"=-
; nur mit Shift anzeigen (default)
"Extended"=""
; auch ohne Shift anzeigen
;"Extended"=-
; Bei Rechtsklick auf Laufwerk
[HKEY_CLASSES_ROOT\Drive\shell\Powershell]
; anzeigen
"HideBasedOnVelocityId"=-
"ShowBasedOnVelocityId"=dword:006698a6
; nicht anzeigen
;"HideBasedOnVelocityId"=dword:006698a6
;"ShowBasedOnVelocityId"=-
; nur mit Shift anzeigen (default)
"Extended"=""
; auch ohne Shift anzeigen
;"Extended"=- Zu Risiken und Nebenwirkungen fragen Sie Ihren Administrator.
Gruß Frank
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: 339530
Url: https://administrator.de/tutorial/windows-10-1703-powershell-und-eingabeaufforderung-im-kontextmenue-339530.html
Ausgedruckt am: 22.12.2024 um 08:12 Uhr
21 Kommentare
Neuester Kommentar
Hi,
das hast du zwar sehr schön gemacht, aber ginge das nicht auch einfacher mit dem Erstellen einer Verknüpfung auf %COMSPEC%?
Das ist eine Frage, keine Kritik!
Gruß
das hast du zwar sehr schön gemacht, aber ginge das nicht auch einfacher mit dem Erstellen einer Verknüpfung auf %COMSPEC%?
Das ist eine Frage, keine Kritik!
Gruß
Hallo hugonatter,
die Methode wie Bill das eine oder andere ins Kontextmenü bringt, habe ich mir nicht ausgedacht. Mir ging es lediglich darum aufgezeigt wie man sie mit möglichst wenig manuellem Aufwand anwendet.
Zu Deiner Frage:
Hä, wie meinst Du das?
Wo sollte diese Verknüpfung erstellt werden und wie käme sie dann einfach (ohne Registry) ins Kontextmenü?
Gruß Frank
die Methode wie Bill das eine oder andere ins Kontextmenü bringt, habe ich mir nicht ausgedacht. Mir ging es lediglich darum aufgezeigt wie man sie mit möglichst wenig manuellem Aufwand anwendet.
Zu Deiner Frage:
Zitat von @114685:
...ginge das nicht auch einfacher mit dem Erstellen einer Verknüpfung auf %COMSPEC%?
...ginge das nicht auch einfacher mit dem Erstellen einer Verknüpfung auf %COMSPEC%?
%COMSPEC% == C:\WINDOWS\system32\cmd.exeHä, wie meinst Du das?
Wo sollte diese Verknüpfung erstellt werden und wie käme sie dann einfach (ohne Registry) ins Kontextmenü?
Gruß Frank
Hi, Pedant,
dir ist ja bekannt, dass ich mit Windows 10 nichts am Hut habe. Ich glaube aber gelesen zu haben, dass man da was hinzufügen kann. Vielleicht gibt's im Kontextmenu sowas wie Senden an ?
BTW: Hat Windows 10 keinen Desktop mehr? Die Verknüpfung könntest du doch dort ablegen, dann hast du gleichzeitig die Möglichkeit, sie als User oder als Administrator zu starten.
Gruß
dir ist ja bekannt, dass ich mit Windows 10 nichts am Hut habe. Ich glaube aber gelesen zu haben, dass man da was hinzufügen kann. Vielleicht gibt's im Kontextmenu sowas wie Senden an ?
BTW: Hat Windows 10 keinen Desktop mehr? Die Verknüpfung könntest du doch dort ablegen, dann hast du gleichzeitig die Möglichkeit, sie als User oder als Administrator zu starten.
Gruß
Hallo hogonatter,
"Senden an" gibt es zwar, aber nur im Kontext von Dateien und Ordnern und nicht im Kontext von Laufwerken und "Background".
Klar hat Windows 10 einen Desktop, aber dort eine statische Verknüpfung zur cmd abzulegen erfüllt nicht im Ansatz den Zweck, die Eingabeaufforderung oder eine PowerShell kontextabhängig zu öffnen.
Die Diskussion über Alternativen geht auch am Ziel meiner Anleitung komplett vorbei.
Hier ist beschrieben, wie Bills Weg funktioniert und wie man auf ihm wandelt.
Um es nochmal zu verdeutlichen:
Die beschriebenen Reg-Schlüssel sind bei Windows 10 per default vorhanden, es hat sich lediglich geändert, dass mit dem Creators-Update der CMD-Eintrag ausgeblendet und der PowerShell-Eintrag eingeblendet wurde.
Anhand der geschriebenen Anleitung kann man das wieder umkehren oder besser noch beide einblenden oder was auch immer einem lieb ist.
Wer ausschließlich Alternativen haben möchte, braucht die Anleitung auch, um beide Einträge entfernen zu können.
Gruß Frank
"Senden an" gibt es zwar, aber nur im Kontext von Dateien und Ordnern und nicht im Kontext von Laufwerken und "Background".
Klar hat Windows 10 einen Desktop, aber dort eine statische Verknüpfung zur cmd abzulegen erfüllt nicht im Ansatz den Zweck, die Eingabeaufforderung oder eine PowerShell kontextabhängig zu öffnen.
Die Diskussion über Alternativen geht auch am Ziel meiner Anleitung komplett vorbei.
Hier ist beschrieben, wie Bills Weg funktioniert und wie man auf ihm wandelt.
Um es nochmal zu verdeutlichen:
Die beschriebenen Reg-Schlüssel sind bei Windows 10 per default vorhanden, es hat sich lediglich geändert, dass mit dem Creators-Update der CMD-Eintrag ausgeblendet und der PowerShell-Eintrag eingeblendet wurde.
Anhand der geschriebenen Anleitung kann man das wieder umkehren oder besser noch beide einblenden oder was auch immer einem lieb ist.
Wer ausschließlich Alternativen haben möchte, braucht die Anleitung auch, um beide Einträge entfernen zu können.
Gruß Frank
Hi,
ok, danke fürs Feedback.
Gruß
ok, danke fürs Feedback.
Gruß
Hallo,
Hugonatters Alternative den "SentTo"-Ordner zu nutzen, um dort eine passende Batch abzulegen oder zu verknüpfen und diese dann über den Kontext-Eintrag "SentTo"/"Senden an" nutzen zu können, ist mir persönlich zu indirekt, weil "SendTo"/"Senden an" eine Kaskade tiefer liegt, was zugegebenermaßen auch nicht so weit weg ist.
Er hat mir inzwischen auch eine Batchdatei gezeigt, die die Kontextabhängigkeit des Aufrufs ermöglicht.
Ich hab sie getestet und für gut befunden, insofern wäre das durchaus eine Alternative, die ohne Registry auskommt.
Der "SendTo"-Ordner bei Windows 10 liegt hier:
C:\Users\BENUTZERNAME\AppData\Roaming\Microsoft\Windows\SendTo\
Für Windows 10-Nutzer habe ich meine Reg-Datei (siehe Ausgangspost) ergänzt mit der Zeichenfolge "Extended" und deren Bedeutung.
So kann man (optional) die Eingabeaufforderung und/oder PowerShell auch ohne die [Shift]-Taste erreichen.
Für alle die kein Windows 10 haben, kann man zumindest die Eingabeaufforderung ins Kontextmenü per Registry aufnehmen und analog vermutlich auch PowerShell (falls vorhanden).
Die entsprechende Datei für 9x, NT3.x, NT4, 2000, XP und 7 sieht so aus:
Eingabeaufforderung.reg (für < Win 10)
Anmerkung:
Diese Reg würde auch unter Windows 10 funktionieren, aber dort existieren schon "ab Werk" ähnliche Einträge, die man dann auch verwenden sollte, statt zusätzliche anzulegen (siehe Ausgangsbeitrag).
Gruß Frank
Hugonatters Alternative den "SentTo"-Ordner zu nutzen, um dort eine passende Batch abzulegen oder zu verknüpfen und diese dann über den Kontext-Eintrag "SentTo"/"Senden an" nutzen zu können, ist mir persönlich zu indirekt, weil "SendTo"/"Senden an" eine Kaskade tiefer liegt, was zugegebenermaßen auch nicht so weit weg ist.
Er hat mir inzwischen auch eine Batchdatei gezeigt, die die Kontextabhängigkeit des Aufrufs ermöglicht.
Ich hab sie getestet und für gut befunden, insofern wäre das durchaus eine Alternative, die ohne Registry auskommt.
Der "SendTo"-Ordner bei Windows 10 liegt hier:
C:\Users\BENUTZERNAME\AppData\Roaming\Microsoft\Windows\SendTo\
Für Windows 10-Nutzer habe ich meine Reg-Datei (siehe Ausgangspost) ergänzt mit der Zeichenfolge "Extended" und deren Bedeutung.
So kann man (optional) die Eingabeaufforderung und/oder PowerShell auch ohne die [Shift]-Taste erreichen.
Für alle die kein Windows 10 haben, kann man zumindest die Eingabeaufforderung ins Kontextmenü per Registry aufnehmen und analog vermutlich auch PowerShell (falls vorhanden).
Die entsprechende Datei für 9x, NT3.x, NT4, 2000, XP und 7 sieht so aus:
Eingabeaufforderung.reg (für < Win 10)
REGEDIT4
; Der Wert von @="Command Prompt" ist wahlfrei
; Er hat keinen Einfluss auf die eigentliche Funktion.
; Der Wert der Zeichenfolge wird im Kontextmenü als Eintrag angezeigt.
; Bei Rechtsklick auf Ordner
[HKEY_CLASSES_ROOT\Directory\shell\OpenNew]
@="Command Prompt"
[HKEY_CLASSES_ROOT\Directory\shell\OpenNew\Command]
; Windows NT, XP höher
@="cmd.exe /k cd %1"
; Windows 9x
;@="command.exe /k cd %1"
; Bei Rechtsklick auf Laufwerk
[HKEY_CLASSES_ROOT\Drive\shell\OpenNew]
@="Command Prompt"
[HKEY_CLASSES_ROOT\Drive\shell\OpenNew\Command]
; Windows NT, XP höher
@="cmd.exe /k cd %1"
; Windows 9x
;@="command.exe /k cd %1"
; Uninstall
;[-HKEY_CLASSES_ROOT\Directory\shell\OpenNew]
;[-HKEY_CLASSES_ROOT\Drive\shell\OpenNew]Anmerkung:
Diese Reg würde auch unter Windows 10 funktionieren, aber dort existieren schon "ab Werk" ähnliche Einträge, die man dann auch verwenden sollte, statt zusätzliche anzulegen (siehe Ausgangsbeitrag).
Gruß Frank
Möglicherweise bin ich jetzt neben der Spur ... bitte um Nach(t)sicht.
Creators Update
Windows-Taste + i / Personalisierung / Taskleiste / "Bei Rechtsklick ..."
Da kann ich doch einstellen, ob Powershell oder Eingabeaufforderung.
Wo ist mein Verständnis-Problem?
tgif!
Creators Update
Windows-Taste + i / Personalisierung / Taskleiste / "Bei Rechtsklick ..."
Da kann ich doch einstellen, ob Powershell oder Eingabeaufforderung.
Wo ist mein Verständnis-Problem?
tgif!
Wo ist mein Verständnis-Problem?
Das gilt nur für das Kontextmenü des Startmenüs, nicht für die Kontextmenüs des Explorers.Gruß bibersbaum
@133417
Aha!
Im Eröffnungs-Beitrag steht leider nur "Kontextmenü" ...
Danke für den Hinweis.
Gruß und weiter viel Spaß beim heutigen Freitg
Ankh
Aha!
Im Eröffnungs-Beitrag steht leider nur "Kontextmenü" ...
Danke für den Hinweis.
Gruß und weiter viel Spaß beim heutigen Freitg
Ankh
Hallo BibersBaum,
ich hab den Text im Eröffnungs-Beitrag jetzt ergänzt.
Zuvor
Gruß Frank
ich hab den Text im Eröffnungs-Beitrag jetzt ergänzt.
Zuvor
...mit dem Creators-Update für Windows 10 verschwindet die Eingabeaufforderung aus dem Kontextmenü...
Jetzt...mit dem Creators-Update für Windows 10 verschwindet die Eingabeaufforderung aus dem Kontextmenü des Explorers...
Gruß Frank
Hi.
Hat seine Anwendungsfälle, ja, aber dennoch sollte man immer fragen "warum mach MS das?". Den meisten macht ja nun vermutlich gar nichts aus, dort einfach auf der Powershell die alten Kommandos der Shell auszuführen.
Hat seine Anwendungsfälle, ja, aber dennoch sollte man immer fragen "warum mach MS das?". Den meisten macht ja nun vermutlich gar nichts aus, dort einfach auf der Powershell die alten Kommandos der Shell auszuführen.
Hallo DerWoWusste,
Gruß Frank
PS: Wenn ich nach einem Rechnerneustart die PS aufrufen benötigt sie gut 10 Sekunden bis zum Prompt.
Zitat von @DerWoWusste:
Den meisten macht ja nun vermutlich gar nichts aus, dort einfach auf der Powershell die alten Kommandos der Shell auszuführen.
Wie meinst Du das?Den meisten macht ja nun vermutlich gar nichts aus, dort einfach auf der Powershell die alten Kommandos der Shell auszuführen.
C:\>dir /bLogsPerfLogsProgram FilesProgram Files (x86)TempUsersWindowsPS C:\>dir /bdir : Der Pfad "C:\b" kann nicht gefunden werden, da er nicht vorhanden ist.Gruß Frank
PS: Wenn ich nach einem Rechnerneustart die PS aufrufen benötigt sie gut 10 Sekunden bis zum Prompt.
Zitat von @Pedant:
Logisch weil dir ein Alias für Get-ChildItem ist welches diesen Parameter nicht besitzt.C:\>dir /bLogsPerfLogsProgram FilesProgram Files (x86)TempUsersWindowsPS C:\>dir /bdir : Der Pfad "C:\b" kann nicht gefunden werden, da er nicht vorhanden ist.Einfach vorher mal "cmd" eingeben :-P oder "Start cmd"
Gruß Frank
PS: Wenn ich nach einem Rechnerneustart die PS aufrufen benötigt sie gut 10 Sekunden bis zum Prompt.
Wow hier ist das innerhalb von 1-2 Sekunden betriebsbereit, was hast du denn für ne lahme Kiste PS: Wenn ich nach einem Rechnerneustart die PS aufrufen benötigt sie gut 10 Sekunden bis zum Prompt.
?!Batch is so langsam aber sicher tot ... Irgendwann muss man mal loslassen und sich neuen Dingen stellen
Hallo BibersBaum
DerWoWusste schrieb:
einfach auf der Powershell die alten Kommandos der Shell auszuführen.
und das funktioniert einfach nicht,
daher meine Rückfrage wie er das meinte.
Start cmd öffnet mir eine echte Eingabeaufforderung in einem neuen Fenster.
Da könnte ich aber genauso gut "start notepad" eingeben und dann behaupten PS hätte eine GUI zum Textetippen.
Zuhause: Intel Core2 Duo E8400 (3GHz), 4 GB Ram und HDD@7200upm
Im Büro habe ich mich deutlich besser ausgerüstet.
Gruß Frank
DerWoWusste schrieb:
einfach auf der Powershell die alten Kommandos der Shell auszuführen.
und das funktioniert einfach nicht,
daher meine Rückfrage wie er das meinte.
Zitat von @133417:
Einfach vorher mal "cmd" eingeben :-P oder "Start cmd"
Gebe ich cmd ein, wechsel ich den Kommandointerpreter und mit PS hat das dann nichts zu tun, wäre aber ein schneller Weg wenn ansonsten keine Eingabeaufforderung erreichbar wäre.Einfach vorher mal "cmd" eingeben :-P oder "Start cmd"
Start cmd öffnet mir eine echte Eingabeaufforderung in einem neuen Fenster.
Da könnte ich aber genauso gut "start notepad" eingeben und dann behaupten PS hätte eine GUI zum Textetippen.
Zitat von @133417:
Batch is so langsam aber sicher tot ... Irgendwann muss man mal loslassen und sich neuen Dingen stellen
Ja, aber nicht heute ... vielleicht nächste Woche.Batch is so langsam aber sicher tot ... Irgendwann muss man mal loslassen und sich neuen Dingen stellen
Zitat von @133417:
Wow hier ist das innerhalb von 1-2 Sekunden betriebsbereit, was hast du denn für ne lahme Kiste?!
Beim zweiten Aufruf von PS ist es auch auf meiner Kiste nach 1-2 Sekunden betriebsbereit, aber nach einem Rechnerneustart dauert es zuhause seine Zeit.Wow hier ist das innerhalb von 1-2 Sekunden betriebsbereit, was hast du denn für ne lahme Kiste
?!Zuhause: Intel Core2 Duo E8400 (3GHz), 4 GB Ram und HDD@7200upm
Im Büro habe ich mich deutlich besser ausgerüstet.
Gruß Frank
Hi. Du hast das mit dem Alias nicht verstanden. Der dir-Befehl ist ein seltener Sonderfall, da dir ein alias in der Powershell ist.
Hallo DerWoWusste,
Du meinst das hier?:
Dass ich mich mit PS nicht auskenne ist mein Fehler oder zumindest mein Versäumnis, aber darum geht's hier doch nicht.
Es geht um Deine, von mir so interpretierte These, dass cmd-Befehle einfach, also ohne weitere PS-Kenntnisse in PS nutzbar wären.
Ich hab mal einige (und lange nicht alle) weitere Befehle ausprobiert.
Einige wurden von PS identisch zu cmd ausgeführt, aber die These "dir ist ein seltener Sonderfall", kann ich nicht bestätigen, zumindest ist es leicht weitere Sonderfälle zu finden, wie beispielsweise diese hier:
Ich stelle mal die Behauptung auf, wer cmd-Befehle nutzen möchte und sich mit PS nicht auskennt, der sollte das mit cmd machen und nicht mit PS.
Diese Behauptung sagt nichts über den Sinn oder Nichtsinn der Nutzung von cmd aus und auch nichts über unbestrittene Vorteile von PS.
Dann will ich das mal ändern...
Ein bisschen Google sagt mir, dass ich statt "dir" (von cmd) unter PS "Get-ChildItem" nutzen kann, wobei ich auch "dir" (als Alias) eintippen kann, aber damit nicht "dir" aufrufe, sondern "Get-ChildItem" und das ist ein PS-Befehl, der seine eigene Syntax hat und eigene Parameter kennt und nicht die von "dir" von cmd.
entsprich
ist gleich
ist ungleich
Weitere Aliase:
Gruß Frank
Du meinst das hier?:
Zitat von @DerWoWusste:
Logisch weil dir ein Alias für Get-ChildItem ist welches diesen Parameter nicht besitzt.
Das mit dem Alias habe ich in dem Kontext tatsächlich nicht verstanden, insofern, dass ich die Logik nicht erkenne, wenn ich, wie aufgefordert, einfach auf der Powershell die alten Kommandos der Shell eingebe, dass es dann folgerichtig sei eine Fehlermeldung zu erhalten, statt der eingeforderten Ausgabe.Logisch weil dir ein Alias für Get-ChildItem ist welches diesen Parameter nicht besitzt.
Dass ich mich mit PS nicht auskenne ist mein Fehler oder zumindest mein Versäumnis, aber darum geht's hier doch nicht.
Es geht um Deine, von mir so interpretierte These, dass cmd-Befehle einfach, also ohne weitere PS-Kenntnisse in PS nutzbar wären.
Ich hab mal einige (und lange nicht alle) weitere Befehle ausprobiert.
Einige wurden von PS identisch zu cmd ausgeführt, aber die These "dir ist ein seltener Sonderfall", kann ich nicht bestätigen, zumindest ist es leicht weitere Sonderfälle zu finden, wie beispielsweise diese hier:
assoc .txtcall notepadcd /d D:\Tempcolor 3Eftype txtfileprompt $d$b$p$gsort Liste.txtverIch stelle mal die Behauptung auf, wer cmd-Befehle nutzen möchte und sich mit PS nicht auskennt, der sollte das mit cmd machen und nicht mit PS.
Diese Behauptung sagt nichts über den Sinn oder Nichtsinn der Nutzung von cmd aus und auch nichts über unbestrittene Vorteile von PS.
Dann will ich das mal ändern...
Ein bisschen Google sagt mir, dass ich statt "dir" (von cmd) unter PS "Get-ChildItem" nutzen kann, wobei ich auch "dir" (als Alias) eintippen kann, aber damit nicht "dir" aufrufe, sondern "Get-ChildItem" und das ist ein PS-Befehl, der seine eigene Syntax hat und eigene Parameter kennt und nicht die von "dir" von cmd.
C:\>dir /sentsprich
PS C:\> Get-ChildItem -recurseist gleich
PS C:\> dir -recurseist ungleich
PS C:\> dir /sWeitere Aliase:
PS C:\> Get-AliasGruß Frank
1
Moin Frank.
Alles richtig, was Du da schreibst. Es ist ja auch für manchen äußerst sinnvoll, eine cmd dort aufmachen zu können per Kontextmenüeintrag. Und ob dass nun wenige cmd-Kommandos sind, die der Powershell fehlen, oder viele, dass entscheidet wohl auch das Nutzerverhalten, da muss ich dir Recht geben.
Der Zweck meines Hinweises sollte sein, keine Brücken zum Alten hin zu bauen, bevor man sich nicht mit dem Neuen auseinandergesetzt hat.
Das hast Du nun getan - get-alias kann man vergleichen mit dem, was in der cmd von help ausgespuckt wird und kann somit sogar programmatisch auflisten, was auf der Powershell nicht/nicht in der gleichen Weise gehen wird. Die Executables, die Admins nun auch hin und wieder nutzen, wie ping.exe, net.exe, manage-bde.exe, netsh.exe, findstr.exe, icacls.exe, fsutil.exe... funktionieren natürlich ebenso auf der Powershell in der gleichen Weise.
Für deinen Tipp (um ihn simpler zu halten) würde ich folgendes Regfile empfehlen, das schon seit Jahren dazu im Netz kursiert:
Alles richtig, was Du da schreibst. Es ist ja auch für manchen äußerst sinnvoll, eine cmd dort aufmachen zu können per Kontextmenüeintrag. Und ob dass nun wenige cmd-Kommandos sind, die der Powershell fehlen, oder viele, dass entscheidet wohl auch das Nutzerverhalten, da muss ich dir Recht geben.
Der Zweck meines Hinweises sollte sein, keine Brücken zum Alten hin zu bauen, bevor man sich nicht mit dem Neuen auseinandergesetzt hat.
Das hast Du nun getan - get-alias kann man vergleichen mit dem, was in der cmd von help ausgespuckt wird und kann somit sogar programmatisch auflisten, was auf der Powershell nicht/nicht in der gleichen Weise gehen wird. Die Executables, die Admins nun auch hin und wieder nutzen, wie ping.exe, net.exe, manage-bde.exe, netsh.exe, findstr.exe, icacls.exe, fsutil.exe... funktionieren natürlich ebenso auf der Powershell in der gleichen Weise.
Für deinen Tipp (um ihn simpler zu halten) würde ich folgendes Regfile empfehlen, das schon seit Jahren dazu im Netz kursiert:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Directory\shell\OpenNew]
@="Command Prompt"
[HKEY_CLASSES_ROOT\Directory\shell\OpenNew\Command]
@="cmd.exe /k cd %1"
[HKEY_CLASSES_ROOT\Drive\shell\OpenNew]
@="Command Prompt"
[HKEY_CLASSES_ROOT\Drive\shell\OpenNew\Command]
@="cmd.exe /k cd %1"
Moin,
gelöscht, hatte den Nachtrag im Eingangsbeitrag nicht gelesen.
Gruß
gelöscht, hatte den Nachtrag im Eingangsbeitrag nicht gelesen.
Gruß
Hallo DerWoWusste,
im Eingangspost bin ich zunächst nur auf die Ausgangssituation bei Windows 10 eingegangen, also auf den Umstand, dass Windows 10 mit dem Cratorsupdate "cmd" auf hide setzt und "PS" auf show.
Die aufgezeigten Schlüssel sind zwar etwas "komplizierter als die "Deinen", aber es sind die, die Microsoft von sich aus anlegt/verändert, deswegen halte ich es bei Windows 10 für sinnvoller die vorgegebenen Schlüssel bei Bedarf anzupassen, statt zusätzlich welche anzulegen.
Das musste doch auch in Deinem Sinne sein, siehe:
Im Verlauf der Threads hatte ich noch eine Reg-Datei nachgereicht, die "Deine" etwas simplere Form hatte, allerdings mit leichten Abweichungen
Da Du jetzt schriebst, "Deine" Variante würde seit Jahren im Netz kursieren, hatte ich keinen Kummer damit, diese kleine Änderungen einzupflegen, zumal sie auch kleine Vorteile gegenüber meiner Variante hat, aber wie gesagt, würde ich diese simplere Reg nur für Systeme vor Windows 10 empfehlen, da es ab Windows 10 zu einer Verdoppelung führen und von Bills Weg unnötig abweichen würde.
Den Beitrag mit der Reg für "vor Windows 10" habe ich jetzt entsprechend geändert.
Gruß Frank
Zitat von @DerWoWusste:
Für deinen Tipp (um ihn simpler zu halten) würde ich folgendes Regfile empfehlen, das schon seit Jahren dazu im Netz kursiert:
Für deinen Tipp (um ihn simpler zu halten) würde ich folgendes Regfile empfehlen, das schon seit Jahren dazu im Netz kursiert:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Directory\shell\OpenNew]
@="Command Prompt"
... im Eingangspost bin ich zunächst nur auf die Ausgangssituation bei Windows 10 eingegangen, also auf den Umstand, dass Windows 10 mit dem Cratorsupdate "cmd" auf hide setzt und "PS" auf show.
Die aufgezeigten Schlüssel sind zwar etwas "komplizierter als die "Deinen", aber es sind die, die Microsoft von sich aus anlegt/verändert, deswegen halte ich es bei Windows 10 für sinnvoller die vorgegebenen Schlüssel bei Bedarf anzupassen, statt zusätzlich welche anzulegen.
Das musste doch auch in Deinem Sinne sein, siehe:
Im Verlauf der Threads hatte ich noch eine Reg-Datei nachgereicht, die "Deine" etwas simplere Form hatte, allerdings mit leichten Abweichungen
Da Du jetzt schriebst, "Deine" Variante würde seit Jahren im Netz kursieren, hatte ich keinen Kummer damit, diese kleine Änderungen einzupflegen, zumal sie auch kleine Vorteile gegenüber meiner Variante hat, aber wie gesagt, würde ich diese simplere Reg nur für Systeme vor Windows 10 empfehlen, da es ab Windows 10 zu einer Verdoppelung führen und von Bills Weg unnötig abweichen würde.
Den Beitrag mit der Reg für "vor Windows 10" habe ich jetzt entsprechend geändert.
Gruß Frank
Hallo,
wo in der Registry kann ich dies für Dateien einstellen?
Gruß
wo in der Registry kann ich dies für Dateien einstellen?
Gruß
Hallo MikeWend,
Auf was mag sich "dies" beziehen?
Was möchtest Du erreichen?
Gruß Frank
Auf was mag sich "dies" beziehen?
Was möchtest Du erreichen?
Gruß Frank
