Microsoft-manager: opdrachtprompt had niet zo lang bestaan moeten hebben

Volgens Rich Turner, senior program manager bij Microsoft, had zijn bedrijf de opdrachtprompt, oftewel cmd.exe, niet zo lang in leven moeten houden als is gebeurd. Cmd.exe zou volgens hem niet meer gebruikt moeten worden.

Rich Turner, die bij Microsoft senior program manager Windows Console & Command-Line is, doet op Twitter de oproep om de opdrachtprompt niet meer te gebruiken. "Cmd zit in de onderhoudsmodus. Zijn functie is om compatibiliteit te behouden voor verouderde en onaanpasbare scripts en dat is het. Het zou niet gebruikt moeten worden voor interactief shellwerk." Hij verwijst gebruikers door naar PowerShell, dat volgens hem de toekomst is.

In een toelichting op een gebruiker die meldt dat hij dan liever een uitgebreide versie van cmd zou willen, voegt hij daar aan toe dat de enige reden voor het bestaan van cmd was om MS-DOS-scripts en commands te draaien voor mensen die van DOS en de Windows 9x-versies overstapten naar Windows NT. "Het zou niet zo lang bestaan moeten hebben."

Microsoft verving de commandprompt in 2016 door PowerShell bij Windows 10, maar de commandlinetool zit nog altijd in het besturingssysteem en heeft vermoedelijk nog altijd een grote schare gebruikers.

Opdrachtprompt en PowerShell

Reacties (284)

[swhnld]

Wat heb je aan functionaliteit die je niet nodig hebt. Voor de meeste mensen is CMD het enige wat ze aan commando's nodig hebben, en die wil je dan naar een halve programmeer omgeving overhevelen, waarom?
En anders, zet een filter voor Powershell dat er uitziet als CMD, en als iemand dat aanroept regel je de rest onderwater. Heeft de gebruiker er geen last van en heeft de ontwikkelaar toch zijn speeltje.

[Harm_H]

Dit is een goede reactie die meteen kan naar deze man. Onderwater overgaan. Same look, feel en functionaliteiten terwijl je de nieuwe opties ook kan gebruiken.

Ik zou me kapot ergeren als ik bijvoorbeeld in het 'Control Panel' team zou zitten.
A ) Eerst duidelijke icoontjes in 1 oogopslag
B ) Categorizatie toevoegen
C ) Categorizatie opleggen

Het originele control panel had de minste kliks nodig en had de hoogste duidelijkheid. Of is dat mijn nostalgie...

For the rest:
GIT Bash

[Reactie gewijzigd door Harm_H op 23 juli 2024 01:36]

[locke960]

Herkenbaar. Ik ben er nog steeds niet aan gewend dat het windows control panel zijn icoontjes tegenwoordig alfabetisch in regels sorteert ipv in kolommen, zoals vroeger

30 jaar in de IT, continue nieuwe dingen geleerd, maar ik zit me nog steeds het apezuur te zoeken naar een control paneltje...

[Gumball3000]

Meestal sla ik de 'settings' app over. Sommige instellingen kan je daar doen, maar als je geavanceerde instellingen wil aanpassen beland je toch altijd terug in het oude control panel.
Dus via start typ ik meestal 'Control Panel' om zo direct juist te zitten.
Jammer dat dit volledig versplintert is, hadden ze wel van de eerste keer volledig mogen vernieuwen of de oude vertrouwde versie niet zo ver weg stoppen.

[Wakoz]

Heb control panel zelf in de start balk gepind in W10, zodat ik er altijd snel bij kan. Kan gewoon niet wennen aan Settings, voor mijn gevoel totaal niet logisch en kan er dan ook bijna nooit snel vinden wat ik zoek.

[Reactie gewijzigd door Wakoz op 23 juli 2024 01:36]

[freaky]

Veel is er ook niet te vinden. Maar goed, wie wil dat nou ook... De toekomst is blijkbaar alles touch volgens de team leads aldaar en screw de rest. Het oude control panel was gewoon niet touch vriendelijk en deze bagger wel.

[GekkePrutser]

Het probleem met het control panel team is bovendien dat er 2 teams zijn. Die van het control panel en die van de windows settings. Het is al sinds Windows 8 een raar allegaartje van 2 verschillende systemen en dat dat 8 jaar later nog steeds zo is, kan echt niet. Er is steeds meer verplaatst naar het settings menu maar het is nog lang niet klaar.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 01:36]

[lonewolf2nd]

En die van windows settings, daar kan je helft niet mee als control panel of ik kan het niet vinden natuurlijk. Maar als het er wel in zit betekend dat het niet goed in elkaar zit.

[ari3]

Het is al sinds Windows 95 een allegaartje... Fijne benamingen als "Printers en andere apparaten...". Hoewel de naam anders suggereert kon ik geen muis instellingen vinden in die categorie.

En dan de interface voor het instellen van omgevingsvariabelen. Ook al twintig jaar niet gewijzigd: een invoerveld van 64 tekens in plaats van gewoon een teksteditor.

Ook zo irritant dat om input focus te krijgen, je moet klikken in plaats van gewoon je muisaanwijzer er op zetten. Nog irritanter is dat een applicatie met inputfocus altijd zijn scherm op de voorgrond zet.

Of dat geselecteerde tekst eerst met een toetscombinatie of menu naar een klembord gekopieerd moet worden. In de meeste Linux Window Managers wordt geselecteerde tekst automatisch in de plakbuffer gezet.

Nee, UX is niet Microsoft's sterkste kant...

[Squixx]

Laat git bash maar links liggen. Wsl 2 bash is de way forward.

Powershell en bash vanuit je Linux terminal. Helemaal top

[PolarBear]

Dat kan al in Powershell heel veel commando's hebben zowel een 'oude' cmd alias als een Linux alias.

get-childitem, dir en ls doen in PowerShell allemaal hetzelfde.

[[Jules]]

Niet helemaal. Zodra je de oude vertrouwde parameters wilt gebruiken (zoals bv dir /s) dan gebeurt er iets anders dan je verwacht.

Op zich is het wel een interessant idee. Powershell is oa gebaseerd op Tcl, en ik heb in Tcl wel eens een asm -emulator gezien. Dus min of meer asm draaien in Tcl. (okee, niet helemaal asm, maar toch)
https://en.wikibooks.org/...xamples#Playing_Assembler

[boe2]

Niet helemaal. Zodra je de oude vertrouwde parameters wilt gebruiken (zoals bv dir /s) dan gebeurt er iets anders dan je verwacht.

Akkoord, maar nu ben je aan het vasthouden aan een syntax die al 30 jaar obsolete is.

[klakkie.57th]

Obsolete ?? Ik gebruik dat nog constant, het doet wat het moet doen.

[GeroldM]

Ook hier. Het maken van software builds gaat prima, volledig geautomatiseerd. Genereer er zelf mailberichten mee over de status, waar het gedownloaded kan worden, transfer naar de interne en externe build repositories, het automatisch doorlopen van regressietests enz.

Allemaal geen probleem met batch. Is het ideaal voor deze taken? Niet echt, maar dat maakt het niet onbruikbaar of zelfs obsolete. Verre van zelfs.

Daarnaast is Powershell ook niet al te prettig in de omgang. Krachtiger? Zeer zeker! Toekomstbestendig? Zeer zeker! Bash in Linux (en soortgelijke shells) zijn wat dat betreft beter te doen dan Powershell.

[enver63]

Ik begrijp dat syntax af en toe verandert, maar de Tcl syntax is ook ruim 30 jaar oud, en veel verboser dan de syntax in cmd of (ba|c|z)?sh.
Dat is een van mijn grootste ergernissen van Powershell; je typt je helemaal te pletter.

Edit:
Een andere ergernis in Powershell is dat je niet eenvoudig een proces in de achtergrond kunt zetten, zoals met '&' in Unix.

[Reactie gewijzigd door enver63 op 23 juli 2024 01:36]

[Killah_Priest]

Tip om je niet te pletter te typen:
Tab voor autocomplete en aliassen aanmaken.
En hoezo kun je geen proces in de achtergrond starten? Gewoon start-process zonder de -wait parameter gebruiken.

[wiseger]

30 jaar obsolete? Hoe kom je daar nou weer bij. 30 jaar geleden draaide we op Windows 98. Zakelijk was Windows 2000 net uit. Windows 98 maakte nog gewoon gebruik van de command line o.a. bij problemen of bij het partitioneren van je disk.

[boe2]

Windows 98 maakte nog gewoon gebruik van de command line o.a. bij problemen of bij het partitioneren van je disk.

En wat hebben vendor specifieke tools te maken met je smaak van command line parser? Cmd specifieke commandos werden obsolete zodra windows 98 uitkwam en de onderliggende afhankelijkheid van msdos verdween.

30 jaar obsolete? Hoe kom je daar nou weer bij. 30 jaar geleden draaide we op Windows 98.

Precies.

[Reactie gewijzigd door boe2 op 23 juli 2024 01:36]

[Peetz0r]

30 jaar obsolete? Hoe kom je daar nou weer bij. 30 jaar geleden draaide we op Windows 98.

Precies.

Nee niet precies. Nieteens ongeveer eigenlijk. Windows 98 kwam 22 jaar geleden uit

[jeroen79]

Misschien zat @wiseger in een early access groep.

[synoniem]

De command line interface werd pas na Windows 98 Second Edition minder gebruikt en bij Windows Millennium Edition kon je pas Windows installeren zonder de command line te zien te krijgen.

[Andros]

U leeft in 2030?

[Simyager]

Door de quarantine weet ik soms de dagen ook niet meer, maar blijkbaar gaat de tijd veel sneller voor sommige mensen.

[groteboktor]

In 2030 inderdaad

[Timoo.vanEsch]

Sorry, ben ik al zo oud?
Windows 98 kwam uit in 1998, toch?
Dat is 22 jaar geleden.
30 jaar geleden (1990) draaiden "we" Windows 3.0, volgens mij. Ik draaide op dat moment zelf nog alles in DOS, omdat Windows 3.0 te zwaar was voor mijn 386SX met 1MB intern geheugen en 40MB HD.

Wat later kreeg ik Windows 3.1 -met moeite- aan de praat, op een Cyrix 486SLC met 4MB intern. Dat was leuk, maar veel meer dan Solitaire kon ik er destijds niet mee. Ik gebruikte WP5.1 in DOS; totdat ik een fatsoenlijke PC had die windows 3.1 kon draaien en WP5.1 in Windows.

//nostalgie

[Reactie gewijzigd door Timoo.vanEsch op 23 juli 2024 01:36]

[LollieStick]

30 jaar geleden was Windows 3.0 net uit. Windows 98 is iets een een kleine 10 jaar jonger.

[marcovtjetje]

Het is 2020. Dus 30 jaar geleden was 1990. De windows du jour was toen Windows 3.0, die dat jaar was uitgekomen.

[Hoopje]

30 jaar obsolete? Hoe kom je daar nou weer bij. 30 jaar geleden draaide we op Windows 98. Zakelijk was Windows 2000 net uit.

Eehm, nee. 30 jaar geleden was Windows 3.0 nog geen week oud.

Maar inderdaad, Windows 3.0 was nog een schilletje bovenop DOS, dus toen was die syntax nog erg in leven.

[akooijman]

30 jaar geleden was Windows 2000 nog lang niet in beeld. Windows 98 ook niet. Windows 3.0 was het nieuwste van het nieuwste en werd al dan niet via autoexec.bat opgestart vanuit 'cmd' (msdos).

[Anoniem: 1322]

Zoals @[Jules] aangeeft is dat enkel leuk voor dat enkele 'dir' of 'ls' commando dat je geeft in een powershell sessie maar is er geen echte commando emulatie of compatibiliteit.

[field33P]

Precies, ik zie niet echt een reden om cmd.exe te gaan dumpen ter faveure van PowerShell wanneer cmd precies doet wat ik nodig heb en ik niet de boel opnieuw moet gaan leren. Op Windows heb je de command line toch nauwelijks nodig, in tegenstelling tot Linux (in de praktijk dan)

[Mellow Jack]

Ik doe veel met zowel Windows en Linux in een relatief grote omgeving en in beide is het toch vooral bash, PowerShell (en op linux vlak steeds vaker python of Ansible). Vind beide wel iets hebben en verder is cmd vooral nostalgie. Zo gebruikt ik nog steeds ping en telnet, niet omdat het beter is, gewoon omdat het een stomme gewoonte is

[Pietervs]

Stomme gewoonte? Nou, nee.
Het is gewoon beremakkelijk om even een testje te doen: Windows key, CMD <enter>, pings x.x.x.x of telnet y.y.y.y <poortnummer>.
Dat doe ik 10x sneller dan wanneer ik moet bedenken welk tooltje MS nu weer voor me bedacht heeft en al 3x heeft aangepast voor ik er überhaupt aan kon wennen.

Zelfde met ip-adres opvragen: vanaf de command line 1 commando. Vanuit de GUI: zeker 4x klikken. Tot je weer één of andere update krijgt, want dan blijkt het zomaar weer eens ergens anders te zitten: 1 bron van ergernis.

en het is zooo leuk om stagiaires uit te laten zoeken wat er in de autoexec.bat staat...

Powershell is heel mooi, maar voor veel mensen komt het neer op een pak melk gaan halen met een vrachtwagen. Ja, je kan gruwelijk veel met Powershell (dat is het mooie er aan), maar voor de thuisgebruiker is het voor de meeste mensen veel te groot in vergelijking met cmd.

[Reactie gewijzigd door Pietervs op 23 juli 2024 01:36]

[L0g0ff]

Ping werkt ook met powershell.

En als je test-netconnection x.x.x.x -port <poortnummer> gebruikt dan hoef je niet eerst telnet-client te installeren.

Stop die powershell commando's in een invoke-command en je kunt zelfs zonder in te hoeven loggen op andere servers remote commando's afvuren.

En toen ik daar achter kwam begon ik met het omarmen van powershell

Het gebeurt nu zelfs geregeld dat ik (ook vanwege automatisme) cmd start. En als je in cmd powershell typt dan schakel je gewoon over.

Ook die latancy van het starten van powershell is sinds server 2016 / windows 10 zo goed als weg.

[johnbetonschaar]

Op Windows heb je de command line toch nauwelijks nodig, in tegenstelling tot Linux (in de praktijk dan)

Dit snap ik niet, waarom zou je in Windows de command-line minder nodig hebben? Heel veel taken zijn gewoon veel handiger via scripting op te lossen en te automatiseren dan met GUI tools, waarom zou windows daarin anders zijn dan Linux? Als ik zit te devven en ik wil een CSV file lezen, splitten, alle elementen door een python script halen en vervolgens de resultaten in een een archief inpakken, waarom zou ik daar op Windows iets anders voor willen gebruiken dan de command line?

[Houten klomp]

dir /s /p veel gemakkelijker dan klikken, klikken, klikken

[TheVivaldi]

Niet in mijn praktijk. Ik heb op Linux de opdrachtregel nauwelijks nodig, alleen voor een paar dingen die *ik* prettiger vind, zoals git-opdrachten en zo, maar dat zou ik onder Windows ook doen in cmd. Ik doe 99,9% van de taken in Linux gewoon in de GUI.

[akooijman]

Ik doe 99% van de taken gewoon in bash. 😉

[Rinzwind]

De ellende is dat ps allerlei rare fratsen heeft die zelfs programmeurs verassen. Het is zowel vervreemdend voor programmeurs als klassieke shell gebruikers. Dat object geneuzel en de rare teruggave van objecten. PowerShell was nooit simpel zoals cmd dat was. Niet eens zoals de vele Linux shells dat waren. Daar is alles tekst. Als je tekst kunt manipuleren kun je de commando's naar je hand zetten. De overhead van ps is ook van je het. Het is dat t van ms afkomt, anders zou niemand ernaar omkijken. Sowieso is het alweer ps of niets. Ja, je mag bepaalde software automatiseren, maar dat kan alleen via ps objecten.

En dan de afgunst richting vbscript bijv. puur omdat ms ps ophemeld. Juist via wsh kon je zowel jscript als vbscript combineren en t was te begrijpen voor de niet programmeur. Je kon herbruikbare objecten aanmaken voor de gevorderde. Je kon zelfs een html gui eromheen bouwen. Heck je kon t uitbreiden met andere scripttalen zoals Perl. Gek genoeg waren er maar weinig die alle ins en outs gebruikten. WSH is een erg krachtige scripting omgeving.

Linux gebruikers lachen om ps. De onnodige complexiteit. De moeite om een programma benaderbaar te maken vanuit ps. Het is een omslachtige schil om. Net. Alles wat cmd niet is.

[Reactie gewijzigd door Rinzwind op 23 juli 2024 01:36]

[GekkePrutser]

Nou, het pipen van gestructureerde objecten vind ik juist DE meerwaarde van Powershell.

Het idee van piping komt uit Unix maar daar moest je altijd text gaan lopen parsen als je meer dan een simpele lijst van gelijkwaardige regels wilde hebben. Nu met powershell kan je een hele object tree pipen en gewoon subelementen daarin opvragen. Ik vind juist dat Linux dit mist.

Wat ik wel een beetje jammer vind is aan powershell dat er een aantal zeer ouderwetse constructies in zitten zoals de unix 'test' vergelijkingen (zoals "-eq", "-lt" enzovoorts). Dat hoort niet echt in een moderne taal thuis vind ik, ik had veel liever gewoon == en < enzo gezien. Het voelt alsof ze de overstap voor bash programmeurs makkelijker wilden maken, maar voor de rest is alles totaal anders dus dat doel heeft het ook niet bereikt.

[MSalters]

Waarom zou je een filter voor Powershell zetten om het op CMD.EXE te laten lijken? Dat heb je nu al, daar is geen filter voor nodig. "Dir" is een alias voor Get-ChildItem. "Copy" is een alias voor "Copy-Item" etcetera.

Powershell is wel krachtiger: "Dir HKCU:" werkt op de HKEY_CURRENT_USER registry. Gratis functionaliteit; registry keys hebben child items dus Get-ChildItem werkt, dus de "Dir" alias ook.

[Gomez12]

Omdat ik geen dir wil hebben, ik wil een dir /b > test.txt hebben.
En dat kent powershell dus niet op hetzelfde nivo.

Het hele idee van powershell aliassen is waardeloos aangezien het echt alleen de absolute basis pakt en voor de rest niets.

Op internet kan ik 100.000'en voorbeelden van curl/wget command lines die of gewoon werken of melden dat je geen curl/wget hebt. Alleen PS die klaagt over van alles en nog wat omdat het een brakke alias is.

Het hele probleem is dat je met die aliassen niets kan.

[erix4me]

dir | select name > test.txt

[LOTG]

Volgens mij is de enige reden dat powershell er anders uit ziet om visueel duidelijk te maken dat het niet CMD is. Wat is er zo anders aan powershell qua look & feel? De blauwe achtergrond?

Kun je gewoon aanpassen.

En je hebt ook nog Microsoft Terminal, heeft alles meteen dezelfde zwarte look, en kun je meerdere naast elkaar in tabs open hebben (en ook Bash als je de nieuwe versie van het linux subsystem hebt meen ik).

[GekkePrutser]

Je kan bovendien ook Powershell in een cmd window draaien. Gewoon 'powershell' typen

[erix4me]

je kan bovendien ook cmd in een Powershell window draaien. Gewoon 'cmd' typen

[Gomez12]

Wat is er zo anders aan powershell qua look & feel?

Standaard zo ongeveer alles, natuurlijk kan je het aanpassen. Maar dat is een aparte manier van werken, een opvolger introduceren en dan maar zeggen dat iedereen het maar terug moet aanpassen.

Maar wat er anders aan is :
- path bevat niet meer de huidige directory
- scripts zijn niet bij default uit te voeren ook al heb je ze net gemaakt.

[erix4me]

Ach een opvolger introduceren en dan maar zeggen dat iedereen het maar terug moet aanpassen

Alsof het allemaal als een enorme verrassing is.. Powershell is er al sinds 2006.. Ik denk dat een overgangsperiode van 14 jaar genoeg mogelijkheden heeft gegeven om je voor te bereiden.. Denk dat je de meeste scripts die je nu gebruikt ruim na 2006 geschreven hebt.

[kaghy2]

CMD is het enige wat ik nodig heb, waarom PowerShell opnieuw leren. (overigens voor school moeten doen, maar snapte geen zak ervan...).

Dat zal wel aan mij liggen.

[Room42]

Omdat je in de toekomst PowerShell nodig hebt voor algemeen beheer op Windows-systemen. Met alle automation die eraan komt (en er eigenlijk al is), zul je steeds meer op basis van scripts doen (Desired State) en minder met wizards.

Ik weet niet hoe oud je bent, maar als je nog 10 jaar Windows-beheerder wilt zijn, zou ik toch maar langzaam eens wat probeersels oppakken. Er zijn best goede Youtube-tutorials voor PowerShell-beginners. Als je eenmaal de kracht van objecten ontdekt hebt, wil je geen cmd.exe meer aanraken.

[kaghy2]

Dan zal ik maar eens beginnen met die tutorials

Want ik verwacht nog zeker 40 jaar mee te moeten gaan

[Frerk]

Ik zou me er zeker in verdiepen, al is het maar de basis. Het is eigenlijk een vereiste in enterprises en ik zou niemand aannemen die niet op zijn minst de basis begrijpt. De integratie met overige Microsoft producten wordt iedere versie weer beter, en het is eigenlijk de enige manier om eenvoudig te automatiseren tegen Azure aan (ja of je moet met de graph API gaan praten, maar dat is nog een stap verder).

Een goede tip is Powershell in a month of lunches, lekker toegankelijk en de PDF van een eerdere versie is geloof ik gratis. Powershell is tegenwoordig ook een substantieel onderdeel van Microsoft certificeringen, hoewel dat vaak niet veel verder gaat dan cmdlets uit je hoofd leren.

[kaghy2]

Hey thanks!
Dat is interessant om eens door te nemen.

Hier ga ik me zeker in verdiepen!

[JackBol]

Ik heb in 2003 afscheid genomen van Windows ten faveure van Linux en Macos, maar ik moet zeggen dat sinds Windows 10 het OS juist weer een heel stuk beter begint te worden.

Het zal voorlopig niet mijn primaire OS worden, maar als je bergen aan werk wilt verzetten zit je in ieder geval niet meer aan Cygwin vast.

[GekkePrutser]

Zelfde vind ik ook hier. Ik ben in 2004 overgestapt naar macOS omdat Linux gewoon niet klaar was voor de desktop en ik Windows zat was. Tegenwoordig gebruik ik alle 3 door elkaar, al is de Mac nog altijd mijn "hoofd" platform.

Maar wat me enorm irriteert is dat Apple alles steeds meer aan het beperken is. Je kan nu zelfs niet meer zomaar software installeren als die niet 'genotariseerd' is door Apple. Krachtige functies zoals de POSIX compatibiliteit worden beperkt enzovoorts. Het voelt alsof ze er een "iPad Plus" van aan het maken zijn, en dat is bepaald niet interessant meer.

Windows begint daarentegen juist steeds krachtiger te worden. Je hebt nu zelfs openssh standaard in Windows zitten, en met WSL en dergelijke zijn ze goed bezig. Alleen van beiden (Windows en Mac) stoort het me immens dat je steeds minder onder hun cloud diensten uitkomt en ze dingen als telemetrie gebruiken. Dus uiteindelijk denk ik dat ik wel op Linux uit ga komen als "daily driver".

[DCDarkling]

Als je omgeving Windows is moet je eigenlijk gewoon powershell gebruiken.
Het gros van de tools werkt prima in powershell. Ok, parameters doen wat meer moeilijk. Kwestie van gewenning. En bij elke PS versie worden er weer dingen toegevoegd.

Powershell is nu net niet moeilijk en complex. Ja het is anders, ze hebben het echter logisch opgezet dan menig persoon die hier gereageert heeft lijkt te denken.

Het is niet de bedoeling dat je 100.000 commando's gaat onthouden. Bij elk fatsoenlijk enterprise pakket komen daar weer een bulk extra aan bij.
Je behoort de syntax te kennen. Set, new, get, wat is een parameter, dat soort moois.
Wanneer dat doordringt zal het gebruik van Powershell een stuk makkelijker gaan. (MS heeft op hun training site mooie gratis video trainingen hiervoor. (channel9))

Je kan niet alles in UIs zetten. Die worden idioot groot en traag. Dus veel opties in je Windows en pakketten zijn 'verborgen' achter commandline opties. Daar ga je niet komen zonder een fatsoenlijke shell.

Dus je moet meer en meer via shell managen. Daarom is er nu net die nieuwe uniforme syntax. Die ken je, dus zoeken naar nieuwe commando's van pakketten die je nog nooit eerder gebruikt hebt is prima te doen. Je collega geeft je een script en je hebt het pakket nooit gezien. Goede kans dat je enigsinds doorhebt wat er staat omdat de syntax zo uniform is.
Extra voordeel is dat al die pakketten omdat ze ook PS ondersteunen hebben allemaal te managen zijn op automatische processen.

Je start die shell 1x op en houd hm gewoon open. Dat die dan aan het begin van de dag iets langer nodig had, ach. Je was toch niet alleen met die ping bezig?

Powershell geeft je de optie voor de simpele commando's maar kan zoveel meer. En hoe meer je ervan leert hoe meer je doorhebt dat het wel degelijk fijn is om te gebruiken.

Het duurt wat langer met opstarten afhankelijk welke commandos powershell inlaad. Hoe meer je tegelijk inlaad hoe langer het duurt. Denk aan de commandos van je 365 omgeving.
Je kan het echter prima instellen dat je ze niet lokaal inlaad maar dat je gewoon sessies naar de server in kwestie opent.
Niks meer workstations bijhouden, ow.. had je daar de juiste versie van je tools geinstalleerd of dat zoort fratsen. Gewoon connectie maken naar de server waar het pakket op staat via PS en je kan wat je moet doen.

Ik houd niemand tegen om CMD te blijven gebruiken, maar het is echt niet meer van deze tijd. Als je niet verder komt dan ping en ipconfig, prima.
Maar als je meer te managen hebt, pak gewoon PS erbij. Steeds grotere en meer bulk UI is niet houdbaar en gaat hm echt niet meer worden.

[rko4u]

Simpele opdrachten als “dotnet build” of npm install functioneren prima op cmd. Als developer gebruik ik dus meestal cmd. Alleen PS als er iets geautomatiseerd moet worden.

[SPee]

Mijn problemen met PS tov CMD:

• Laat je PS wat langer openstaan en hij reageert niet meer
• Simpele commando's zijn niet simpel meer
• Zelfs basis dingen moet ik weer opzoeken
• Syntax wijkt af van alle andere shells, dus moet je opnieuw leren

Ik schrijf liever en sneller een script in bash, javascript of groovy dan in powershell. Dus ik blijf liever bij het oude CMD.

[nst6ldr]

Laat je PS wat langer openstaan en hij reageert niet meer

Werkelijk nog nooit last van gehad, of ik 'm nou een dag of een maand open laat staan.

Simpele commando's zijn niet simpel meer

Dat is niet waar. Subjectief gezien vind je dat cmd simpele commando's heeft omdat ze bij je zijn ingesleten. Objectief gezien zijn powershell commando's veel simpeler (lees: minder complex) omdat ze allemaal dezelfde naamgeving hebben en de parameters hebben gelijkwaardige naamgeving. Tevens zit er in tegenstelling tot cmd commando's netjes foutafhandeling in waardoor ook de leek kan zien welke vereiste parameters hij niet of verkeerd heeft ingevuld.

Zelfs basis dingen moet ik weer opzoeken

Dat schijnt inderdaad een ding te zijn met nieuwe technologie.

Syntax wijkt af van alle andere shells, dus moet je opnieuw leren

Ik heb dat wel eens met programmeertalen, oervervelend inderdaad.

Ik schrijf liever en sneller een script in bash, javascript of groovy dan in powershell. Dus ik blijf liever bij het oude CMD.

Als je voor je werk Windows beheer doet zit er niet veel anders op. Ik zat wat minder vastgeroest dus heb mezelf powershell eigen gemaakt door trial & error (en mijn .NET achtergrond), ik moet er niet aan denken om 60.000 werkstations en 2000 servers te beheren met cmd en GUI.

[aikebah]

Als je voor je werk Windows beheer doet zit er niet veel anders op. Ik zat wat minder vastgeroest dus heb mezelf powershell eigen gemaakt door trial & error (en mijn .NET achtergrond), ik moet er niet aan denken om 60.000 werkstations en 2000 servers te beheren met cmd en GUI.

Daar is powershell dan ook een prima schroevendraaier voor, dat moet je niet meer met de CMD-hamer willen proberen.

Maar voor MIJN simpele CMD-spijkers is een schroevendraaier het totaal verkeerde stuk gereedschap.

[beerse]

Daar kan ik maar 1 ding aan toevoegen: de handleiding:

Daar waar de unix/linux command-line de handleiding in 'man ' pages heeft zitten biedt powershell de hulp aan in 'get-help' Zie bijvoorbeeld 'get-help get-help'.

[nagasy]

je kan zelf gewoon help + cmdlet typen.

[beerse]

Met de manual pages onder unix/linux en met de 'get-help' constructie van powershell is in het systeem een basis neergelegd die net zo eenvoudig is in te vullen als de commando's zelf. Bij powershell scripts is er zelfs een standaard neergezet dat als je commentaar in het script op de juiste manier formatteert, dat het automatisch als get-help tekst boven komt.

Onder cmd is er ook wel een help commando maar dat geeft voornamelijk "This command is not supported by the help utility. Try..." Dat is niet echt handig. Er is voor zover ik weet ook geen standaard om ergens helpteksten neer te zetten dat het help commando die oppakt.

Onder powershell is de help een alias naar get-help.
PS C:\> help help
NAME
Get-Help

[rob12424]

Vraagje. Ik ben een Linux gebruiker en gebruik alleen voor email op het werk Windows. Wat is het verschil tussen powershell en cmd?

Ik snap er namelijk niet veel van: vroeger bashte Windows gebruikers nog wel eens Linux . Met de melding dat Windows alles met een GUi kon en Linux veel dingen nog in terminal moeten. En vervolgens was iedereen zeer enthousiast over Powershell?

En wat kun je in Powershell wel wat je in Linux niet kan?

[boe2]

Het grote/meest interessante verschil tussen powershell en de meeste andere textbased shells (en waarom ik zelfs op linux powershell gebruik) is dat commando's geen tekst teruggeven maar objecten:

Wanneer je in linux iets wil doen met de uitvoer van je commando's moet je bijna gegarandeerd met grep aan de slag, want wat je terugkrijgt is een hoop tekst die hopelijk niet te complex geformatteerd is. In powershell krijg je effectief een reeks .NET objecten terug waarvan je standaard de string representatie te zien krijgt in je console als je het niet doorlust naar iets anders. Dit is ENORM handig voor scripting:
Bijvoorbeeld bij een linux grep of curl moet je met grep aan de slag om de tekstuitvoer van je bestand te parsen. Bij powershell kan je bijvoorbeeld een Invoke-RestMethod doen, en je krijgt een compeet object terug met je response headers, body, cookies, alles. Of je print gewoon puur de body naar console als je er niets mee doet: Die response body kan je dan meteen ook teruggeven als json/xml object en daar queries op doen.

[rob12424]

Maar onder Linux zijn daar toch ook gewoon plugins voor met Perl bijvoorbeeld? Of heb ik iets gemist (wist niet dat het op Linux draaide)

[Joolee]

Perl, net als bijv. PHP en Python kun je interactief gebruiken al zullen er weinig mensen zijn die dat doen, anders dan soms even als simpele command-line calculator. Perl is echter een script-interpreter/taal en geen shell. Het belangrijkste verschil is dat je er niet zomaar andere programma's mee kunt uitvoeren (zonder functies aan te roepen) en dat je er niet eenvoudig mee door een directorystructuur navigeert.

Powershell is een volwaardige shell en, zoals @boe2 aangeeft, werkt het met objecten in plaats van tekst- en binaire datastreams. Dat is onwijs krachtig maar doordat je continue text aan het parsen ben, wel onwijs gevoelig voor allerlei fouten. Iets dat in Powershell bijna fool-proof en eenvoudig te scripten valt is in Bash soms letterlijk niet bug-vrij te schrijven. Dat komt omdat een specifieke onverwachte combinatie van tekens in de output van een commando heel anders kan reageren dan je rekening mee hebt gehouden.

Om een eenvoudig voorbeeldje te pakken, dat bijna iedereen verkeerd doet in Bash, het kopieren van een lijst bestanden:
cp *.mp3 /home/user/Music

Omdat de bestandsnamen hier als één lange string gevoerd worden aan het cp commando, zal een bestand genaamd '-blaat.mp3' dit eenvoudige voorbeeld als slopen omdat door het eerste streepje het cp commando het zal interpreteren als lijst met switches. Ja, dat kun je oplossen, maar met Powershell heb je zulke problemen niet omdat je zult werken met een array bestandsnamen en niet een lange string.

[Reactie gewijzigd door Joolee op 23 juli 2024 01:36]

[Mellow Jack]

Uiteindelijk kan je alles voor elkaar krijgen maar PowerShell is vanaf het fundament opgebouwd op objecten en dat werkt echt heel goed.

Op Linux lijkt python beetje de standaard te worden

[geoffrey.vl]

Op Linux lijkt python beetje de standaard te worden

Voor scripting is het wel handig, maar niet de standard, voor een traditionele terminal is dat niet echt praktisch en is het eerder bash en aanverwanten.
Het voordeel van python is dat het cross-platform een heel eind komt

[Reactie gewijzigd door geoffrey.vl op 23 juli 2024 01:36]

[beerse]

Als je altijd eerst met grep aan de gang gaat, dan heb je de kracht van awk en perl nooit leren kennen. Heb je wel eens een grep of awk script geschreven? dus 1 die begon met #!/bin/awk of #!/bin/grep in plaats van #!/bin/sh? Dan zie je de kracht van scripting onder unix/linux.

Toegegeven, de script-baar-heid van unix/linux is nogal tekst georiënteerd. Dat is ze immers al ruim 50 jaar, daar is het allemaal mee begonnen. Onder unix/linux geen .net objecten. Want geen .net. Wel het /proc filesysteem met daarin een hiërarchisch overzicht van het hele systeem. Onder unix/linux is immers alles te zien als een bestand, zo niet dan toch.

Eerlijk is eerlijk, ik ben een beetje te veel en te lang van unix scripting af voor de details maar ik kan mij niet voorstellen dat er geen module in perl is die netjes json, xml, html, en wat dan ook kan oppakken en verwerken. En er zijn onder unix/linux vast andere talen en omgevingen die er goed mee overweg kunnen. Tegenwoordig ook powershell heb ik begrepen, al is daar de .net koppeling voor zover ik weet nog vermist.

Ik wil hiermee alleen maar aangeven dat er verschillende inzichten zijn en daarmee verschillende tools om daar mee om te gaan.

[boe2]

Als je altijd eerst met grep aan de gang gaat, dan heb je de kracht van awk en perl nooit leren kennen. Heb je wel eens een grep of awk script geschreven? dus 1 die begon met #!/bin/awk of #!/bin/grep in plaats van #!/bin/sh? Dan zie je de kracht van scripting onder unix/linux.

Toegegeven: nee, ik heb awk en perl nooit effectief zelf gebruikt. Maar als je ziet hoeveel mensen hier al klagen dat ze powershell te complex vinden, dan zijn awk en perl toch een nog een paar bruggen verder als ik zo die scripts bekijk

[beerse]

Met sed, de stream-editor kan je heel aardig de pipeline tekst editen. Daarvoor kan je veel commando's gebruiken die ook in vi (vim) gebruikt worden. met name de 'ed' commando's. die zijn in vi te herkennen aan de : waarmee ze beginnen.

awk (onder linux meestal gawk, de gnu versie) is een nog ergere taal, dat werk het heel script regel voor regel af. En iedere 'regel' bestaat uit een criterium (een voorwaarde) en een opdracht/commando. vooral handig om lange lijsten door te worstelen.

perl is een 'nieuwe' script taal (denk nieuw in 1990) die ooit is begonnen als combinatie van sed, awk, grep en sh.

Het mooie is dat het zoeken (en vervangen) in de meeste gevallen met reguliere expressies gaan. dat is een stabiele factor in deze talen (en op heel unix/linux).

[EraYaN]

Powershell draait gewoon op linux dus niets? Maar Powershell is in ieder geval veel meer dan cmd. Vooral voor management van microsoft software en services.

[powerboat]

In 2010 heeft Microsoft het licht gezien en is er achtergekomen dat cli werk voor met name beheer. Toch beter/sneller werkt.

[GekkePrutser]

Ik snap ook niet helemaal dat ze dat niet eerder gezien hebben. Dingen als "pas van 100.000 gebruiker accounts even het email domein aan van @a.com naar @b.com behalve de mensen van de sales organisatie" kan je met enkel een GUI een team van 100 man inhuren die er een maand over doet om overal doorheen te klikken (en dan ook nog eens een berg fouten maakt).

Met een CLI kan een beheerder dat in een half uurtje doen. Appeltje eitje. Ook voor je dagelijkse change management wil je geen heel team hebben dat door GUIs heen zit te klikken maar het gewoon kunnen automatiseren. Werkt sneller, goedkoper en maakt geen fouten.

Voor de SMB markt is een GUI handig omdat een beheerder daar vaak heel veel taken heeft en niet alles vaak genoeg doet om het goed te weten. In de Enterprise markt is een CLI onontbeerlijk.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 01:36]

[beerse]

Zelf zou ik tot op zekere hoogte cmd.exe (en command.com) kunnen vergelijken met /bin/sh, /bin/csh en zo onder unix/linux. Het is de commando interpreter en de script taal van het os in de jaren '80 en '90.

Onder unix/linux hebben we daarna voor scripting onderandere perl gekregen.

PowerShell laat zich qua script mogelijkheden in mijn ogen redelijk met perl vergelijken. Al moet ik zeggen dat PowerShell wat meer/perfecter object-oriented is. En PowerShell is op de commandline wat praktischer dan perl.

[rickboy333]

Als shell heeft Powershell de CMD volledig vervangen natuurlijk. Maar voor legacy meuk is CMD nog relevant.

Als MS nu een eigen DOSbox alternatief maakt met 100% compatibiliteit voor DOS programma's, Win 3.x en Win9x programma's zijn ze van al dat gezeik af. Een DOSbox alternatief is veilig (want het werkt in een sandbox), makkelijk (wanneer dit direct geïntegreerd is in Windows) en maak het 64 bit compatibel. Dan kunnen ze CMD weg doen, alle Legacy meuk in Windows 10 en is iedereen blij. Zeker als je de laatste Windows 9x en XP bakken van het net af kan halen.

[Reactie gewijzigd door rickboy333 op 23 juli 2024 01:36]

[MSalters]

Sorry, maar je gooit hier een zwik dingen door elkaar. CMD.EXE is de Windows command-line interpreter. Dat is een 100% 32/64 bits executable, en is het altijd geweest. Een DOSBox is een OS emulator. Daarbinnen vind je typisch COMMAND.COM of een andere 16 bits command-line interpreter, en dat zou vergelijkbaar kunnen zijn met CMD.EXE, maar DOSBox is het zeker niet.

COMMAND.COM in een DOSBox is ook geen alternatief voor CMD.EXE. Het snapt geen lange filenames. Het snapt geen NTFS security. Het snapt geen processen of multi-core CPU's. Het snapt geen GUI's. Het snapt geen file associaties. COMMAND.COM is antiek, en het is onzinnig om te suggereren dat het in welke vorm dan ook een alternatief kan zijn voor CMD.EXE

[rickboy333]

Waar zeg ik dat CMD hetzelfde is als Command.com/MS-DOS en MS-DOS de CMD moet vervangen? Je haalt me woorden in de mond die ik niet heb gebruikt. Of heb je dit niet gelezen:

In een toelichting op een gebruiker die meldt dat hij dan liever een uitgebreide versie van cmd zou willen, voegt hij daar aan toe dat de enige reden voor het bestaan van cmd was om MS-DOS-scripts en commands te draaien voor mensen die van DOS en de Windows 9x-versies overstapten naar Windows NT. "Het zou niet zo lang bestaan moeten hebben."

Wat CMD dus doet is legacy scripts en DOSmeuk draaien. Daarom zou er een soort MS-DOSbox moeten komen zodat die legacy meuk daar terecht kan. De rest kan mooi in powershell.

[Reactie gewijzigd door rickboy333 op 23 juli 2024 01:36]

[hiostu]

MS-DOS-scripts is niet hetzelfde als het draaien van DOS applicaties (of DOS-meuk zoals jij dat noemt) wat DOSbox doet.

[rickboy333]

Dat benoem ik toch, 'legacy script".

Maar goed, je hebt natuurlijk wel gelijk. CMD kan sws niet zelfstandig programma's draaien, alleen met NTVDM kan CMD, DOS applicaties weergeven terwijl scripts altijd direct te draaien zijn. Maar ook dat werkt als ik me niet vergis gewoon in Powershell.

[johnbetonschaar]

Als MS nu een eigen DOSbox alternatief maakt met 100% compatibiliteit voor DOS programma's, Win 3.x en Win9x programma's zijn ze van al dat gezeik af.

Volgens mij is het punt dat door CMD.exe en de backwards compatibility met DOS/Win3.x/Win9x zo lang in stand te houden, er tot op de dag van vandaag bergen met shell scripts mee zijn gemaakt, en ze er nu dus niet makkelijk meer van af komen omdat ook software die alleen maar voor Windows XP/2000/Vista/7/8/10 bedoeld was er afhankelijk van is geworden. Dus wat lost een DOSBox achtig alternatief nu nog op? Het probleem is helemaal niet de implementatie of de beveiliging van CMD.exe en alle ouwe meuk die het ondersteunt, maar het feit dat het niet al veel eerder afgeknald is en vervangen door iets moderners...

[InsanelyHack]

draaien die dan niet in een powershell omgeving? Ik ben geen die hard scripter maar voor mijn scriptjes gebruik ik meestal powershell en heb ik CMD niet nodig.

[johnbetonschaar]

Ik denk dat helemaal niemand CMD.exe nodig heeft en iedereen gewoon overal PowerShell voor zou kunnen (en moeten) gebruiken. Maar omdat CMD.exe al die tijd is meegeleverd hebben veel mensen/bedrijven dat niet gedaan en in plaats daarvan ouderwetse .BAT files geschreven die afhankelijk zijn van archaische tooltjes als copy, del, dir, attrib en weet ik veel wat er allemaal in de 'userland' van windows terecht is gekomen dat oorspronkelijk van DOS afkomt. En nu zitten ze bij Microsoft met het probleem dat ze die functionaliteit niet kunnen verwijderen omdat er dan van alles en nog wat omvalt.

Ik moet overigens eerlijk bekennen dat ik zelf 0 verstand van PowerShell heb, het enige wat ik er van weet op basis van wat ik er ooit van gezien heb is dat het 100x beter is dan wat ik van vroeger ken met BAT files en DOS commando's. En dat ik dus met regelmaat moderne windows programma's en batch jobs tegenkom op het intranet op werk die een CMD.exe openen en daar DOS-achtige meuk in uitvoeren

[Z80]

Je bent geen Windows gebruiker aan je post te lezen. Maar kan wel de conclusie trekken dat niemand CMD nodig heeft.
Klinkt het zelfde als iemand die nooit Linux gebruikt en gaat roepen VI is nergens goed voor en zou niet meer gebruikt moeten worden.

[johnbetonschaar]

Dat is een manke vergelijking, het punt is dat alles wat je met CMD kunt doen, ook met PowerShell kunt doen. En beter. Dat durf ik als niet-Windows gebruiker wel te zeggen, al is het maar omdat note bene de senior program manager console & command-line van Microsoft precies hetzelfde zegt: CMD.exe is alleen maar voor backwards compatibility en heeft geen use-cases die je niet met PowerShell kunt oplossen. Correct me if I'm wrong maar het zou wel heel bijzonder zijn als Microsoft een next-generation shell oplossing introduceert die niet alles kan wat 30-jaar oude CMD.exe kan, right?

Dat sommige mensen het makkelijker vinden om alles op de bekende manier te doen en geen zin hebben om tijd te investeren in het leren van PowerShell is een ander verhaal. Daar mag ik ook als niet-Windows gebruiker best iets van vinden toch? Op dezelfde manier dat ik er iets van mag vinden als mensen blijven vasthouden aan Python 2.6 in plaats van Python 3, of C++98 in plaats van C++11 of nieuwer, etc.

[Reactie gewijzigd door johnbetonschaar op 23 juli 2024 01:36]

[HNO2]

Cmd crasht nooit en loopt nooit vast. Onlangs nog een opstartende powershell console consistent zien vastlopen.
Sommige dingen die eenvoudige acties vereisen, maar uiterst belangrijk zijn, kan je beter buiten powershell houden (weet ik uit ervaring).
Powershell is zeker minder betrouwbaar voor infrastructuur scripts die op duizenden systemen moet lopen, je zal hier en daar er altijd vinden met problemen.

[InsanelyHack]

Heel de aansturing van Microsoft Azure draait op Powershell dus dat het niet consistent zou zijn en dat het niet geschikt zou zijn voor infrastructuur scripts betwijfel ik. Powershell kent wel / of kan worden uitgebreid met additionele modules waarbij wellicht het gedrag van powershell kan worden beïnvloed waardoor het bij jou wellicht niet stabiel oogt.

[HNO2]

UWP was ook zo'n goeie uitvinding. Niks als miserie mee in bedrijven (weten we bij ons uit ervaring). Dat wordt ook gepromoot door Microsoft.
Het is niet omdat Microsoft bakken resources hier tegenaan kan en wilt gooien om te onderhouden dat een ander bedrijf dat goed vindt. Veel zaken moeten 'set & forget' zijn in een bedrijf. Taak/script schrijven en schedulen, en dat moet 10 jaar draaien (minstens).
Powershell is goed, maar gebruik het enkel als nodig.

Ook de helft hier zegt dat Powershell traag opstart, de andere helft niet (consistentie?).
Cmd heeft nog nooit traag opgestart. Hoe komt dat dan?

[InsanelyHack]

doordat powershell allerlei modules meeneemt. Als je bv een exchange server hebt dan is er dus exchange powershell module. Je krijgt dan ineens in powershell mogelijkheden om bv gegevens van een bepaalde mailbox te lepelen. Stel je hebt een distributielijst en personeel verloopt nou ja je kan de mogelijkheden zelf wel bedenken. Deze modules worden allemaal geladen tijdens het starten van powershell immers de commandos van je modules wil je wel kunnen aanroepen.

[HNO2]

Je gaat er zo eventjes makkelijk vanuit dat er extra modules geïnstalleerd staan, wat niet het geval is.
Ook ik heb verschillende vertragingen van opstart gezien op verschillende systemen, zelfs freezes.
Jammer, helaas waar.
Zoek in google maar eens naar: powershell freezes windows 10

[Reactie gewijzigd door HNO2 op 23 juli 2024 01:36]

[InsanelyHack]

Hoe weet je dat? Een virusscanner isntalleert b.v. al extra modules. Wat ook kenmerkend is voor Powershell is dat deze ook intern praat via je netwerk local loopback adres wat ook allerlei issues kan veroorzaken als local firewalls dat blokkeren. Maar goed anyway ik herken me totaal niet in jouw problemen met powershell. Ik werk op een "cloud" afdeling waar heel onze eigen cloud en MS azure volledig is geautomatiseerd op basis van powershell.

[HNO2]

Onlangs 3 identiek geinstalleerde PC’s waar na upgrade naar nieuwe versie v1909 1 PC met problemen.
Problemen die ik achteraf heb zien terugkomen op een handvol andere na upgrade.
Dus powershell modules kan maar zoals gezegd waarom bij de eene wel en de andere niet.
Je lijkt het moeilijk te geloven.
Kleine context, 25 jaar in het vak, 5000 clients in beheer. Geen kleine onderneming van 100 PC’s.
En als er zovelen op internet (en hier) hetzelfde zeggen. Zou het dan misschien toch kunnen?
Op internet wordt vanalles gezegd (uiteenlopende moeilijk vergelijkbare situaties) maar ik kan objectief vergelijken.
Het punt is (mijn punt) gebruik powershell enkel als nodig.
In uw cloud omgeving zal powershell onmisbaar zijn, in veel andere gevallen niet. Ik zou het vermijden op basis van wat ik al heb gezien. Tenzij je graag overuren doet.
Soit ieder zijn voorkeuren maar zeggen dat cmd al weg moest zijn, dan zeg ik eerst tegen MS ‘get your sh#t together first’. Ga zeker geen dingen afschaffen die goed werken. Oud of niet.
Cmd nog nooit weten crashen, in mijn carrière vbscript engine al kapot gezien en powershell traag en hangen. En ik heb geen zin om dat uit te zoeken waarom.
It’s a no for me.

[gengar]

Sorry maar gaan we nu een artikel krijgen elke keer iemand een mening zit te roepen op een rotplatform als twitter? Als er een officiële release komt waar cmd vervangen wordt door powershell dan zou ik het snappen. Maar een artikel bouwen rond een platform waar iedereen zomaar wat kan balken? Amateuristisch.

[TunefulDJ_Mike]

Hoezo mening, de iemand waaraan jij refereerd is een Senior Program Manager bij Microsoft, hij geeft geen mening. Er staat letterlijk het volgende

I'll keep saying this until y'all stop using Cmd:

Cmd is in maintenance mode. It's job is to preserve back compat with ancient & immutable scripts. That's it. Period. It should not be used for interactive shell work.

PowerShell is the future.

Dit is toch wel een redelijk relevante tweet, aangezien hierin ook staat dat cmd alleen nog onderhouden wordt voor compatibiliteit.

[Cergorach]

Deze man is de afgelopen vier jaar bezig als Senior Program Manager bij MS, daarvoor nooit bij MS gewerkt.

Van z'n LinkedIn page:

Making the Windows command-line cool again!
Overhauling the Windows Console.
Helping deliver Windows Subsystem for Linux.
Enthusing about and encouraging others to learn to love PowerShell.

Dat het alleen wordt onderhouden voor compatibiliteit mag toch al heel lang duidelijk zijn... En als het om een Twitter post gaat kan ik het niet als officiële melding zien, zelfs op officiële MS plekken zoals de documentatie is het regelmatig ook niet op orde.

Als ITer moet je redelijk veel doen in Powershell, maar we hebben zoveel 'varianten' en versies, commands die worden 'vernieuwd' uitworden gefaseerd, wel/niet werken met die versie van Windows/Exchange/AD/Office 365, etc. CMD just works! (voorlopig tenminste nog) Zoals iemand eerder al aangaf, richt tool for the job. CMD is dat voor veel zaken ook niet, maar Powershell is soms ook een boorhamer terwijl je met een handboortje veel sneller klaar bent...

[andru123]

Een kerel die van ene bedrijf naar andere gaat elke jaar of vier, is niet echt een goede bron. Hij is geen Product manager, maar een Program manager, whatever that is.
Ik denk (hoop) dat command line veel langer gaat leven dan dit kerel bij Microsoft werken.

[Alex3]

Ze worden daar kennelijk ook niet op hun taalvaardigheid gekozen. (It's job.)

[LordMike]

Ja letterlijk who cares about DT? Je zit hier niet op een curcus Nederlands ofzo hoor.

Nobody else cares about your stuff..

[Anoniem: 310408]

Als die iemand Rich Turner is, stel ik voor dat we daar zeker tweaker nieuws van maken omdat het een deel van de toekomst van Windows laat zien. We kunnen er nu zeker van zijn dat CMD gaat verdwijnen en zoals je hier hebt gezien zal dat veel mensen zwaar op de maag vallen.

Ergo, nieuwswaardig

[Joolee]

Hoezo 'zeker van zijn'? Hij heeft daar niets over gezegd. Windows hang aan elkaar van de legacy meuk, sommige dingen daarvan dateren al van vóór Windows of zelfs DOS. Waarom zouden ze dan nu de woede van 90% van de systeembeheerders op zich gaan halen door cmd.exe te gaan verwijderen? (https://www.youtube.com/watch?v=bC6tngl0PTI bijvoorbeeld)

Overigens blijf ik Powershell maar vervelend vinden. Ik start het wel eens en dan zit ik zo lang naar een leeg blauw scherm te staren dat ik in de tussentijd al cmd.exe heb gestart en gedaan wat ik moet doen voordat er een prompt verschijnt. Ook ooit eens bezig geweest een backup script te schrijven voor MSSQL databases. Wat een draak zeg, bugged API's, foutmeldingen gooien op NULL waarden en dergelijke. Ik snap de kracht van alles in objecten gooien maar doe mij voorlopig nog maar gewoon GNU utils en txt streams.

Al die 100.000 'cmdlets' met namen waar je vingerkramp van krijgt en die je maar allemaal moet gaan onthouden... Blij dat ik al een tijd geen Windows admin meer ben

[Reactie gewijzigd door Joolee op 23 juli 2024 01:36]

[nst6ldr]

Al die 100.000 'cmdlets' met namen waar je vingerkramp van krijgt en die je maar allemaal moet gaan onthouden... Blij dat ik al een tijd geen Windows admin meer ben

Maar dan heb je het niet begrepen. Juist omdat de naamgeving uniform is hoef je er maar twee te onthouden: get-command en get-help. Al het andere is mooi meegenomen maar zeker niet nodig.

[Eonfge]

Ik zou juist het tegenovergestelde stellen: 30 jaar backwards compatibility is Windows' grootste bestaansrecht.

[beerse]

Misschien 40 jaar behoud zonder ontwikkeling en dan opeens grote klappen maken.

Op shell gebied heeft unix/linux een andere/betere/grotere backwards compatibility: /bin/sh gaat volgens mij langer terug dan het bedrijf microsoft. En dat is onder de huidige linux implementaties nog steeds compatibel te gebruiken. Gelukkig zit er bij unix/linux meer een geleidelijke ontwikkeling in die gelukkig nog steeds door gaat.

[Eonfge]

Gemende gevoelens over: Binary compatiblity in Linux is super goed, maar het landschap zelf veranderd snel: In 2014 gebruikte Ubuntu Upstart manager, in 2016 gebruikte Ubuntu Unity UI. In 2018 gebruikte ze Systemd en GNOME.

Als je een linux-native game neemt zoals Quake 3, ontwikkeld door Loki, dan zou je die nu waarschijnlijk niet meer kunnen draaien omdat het landschap te veel veranderd is.

[ToolBee]

Hear hear!

[Marctraider]

Iemand ooit een search gedaan in C:\Windows naar *.exe en zien hoeveel legacy troep er nog steeds in zit?

Beetje nutteloos dus deze berichtgeving of wat deze meneer zegt ;-)

[beerse]

Het mooiste legacy in c:\windows vind ik wel de ...\system32\ directory. Ooit begonnen voor het onderscheid tussen 16 bits en 32 bits. Ondertussen zitten de 64 bits binaries in ..\system32\ en de 32 bits binaries in ...\SysWOW64\...

[SinergyX]

CMD -> ping, netstat en ipconfig, bijna nog dagelijks.

Er zijn 1020 windows tools beschikbaar, maar of met irritante popups, doet het maar half, betaald, achterhaald, gezeur met updates, te actief aanwezig.. gewoon oldschool werkt nog prima

[walteij]

Powershell is zonder irritante popups, doet het absoluut (en IMNSHO beter dan de command prompt), is gratis, wordt geupdate via Windows Update, is niet actief aanwezig, moderner en het werkt prima.

Alledrie de commando's die je noemt werken ook in Powershell, maar Test-Netconnection geeft je meer mogelijkheden dan ping.
netstat is in Powershell Get-NetTCPConnection, ook weer met prima overzichten.
ipconfig kun je vervangen voor Get-NetIPConfiguration

De namen zijn zelfs enigszins logisch:
Get - Zoek op
Set - Stel in
New - Maak iets nieuws aan
Ook de rest van de commandlets zijn vrij duidelijk, Get-Mailbox haalt mailbox informatie op, New-OrganizationRelationship zorgt voor een nieuwe relatie tussen 2 exchange organisaties, Set-password kun je gebruiken om een wachtwoord van een (ad) account te wijzigen.
De basis van Powershell is eenvoudiger te leren dan de basis van de command prompt.

[mphilipp]

Klopt allemaal. Maar als ik niet geïnteresseerd ben in Powershell te leren en slechts enkele commando's gebruik, waarom moet ik dan 'over'? Alleen maar omdat het moderner is, is geen argument. Het is er, ik ken het al 30 jaar en ik wil geen complete scripts bouwen in DOS commando's. Gewoon wat simpele commando's. Geen zin om me in iets anders te verdiepen. Dat gepruts is al lang geen hobby meer van me...

[walteij]

Als je het niet professioneel gebruikt, is er inderdaad weinig stimulans of nut om over te stappen.
Maar als je voor je beroep met het beheren/installeren/configureren van Windows devices te maken hebt, is er absoluut wel nut om je hierin te verdiepen.

Van mij mag de command prompt zo snel mogelijk uit Windows gehaald worden, maar ik snap ook best waarom dit voorlopig nog niet gebeurd.
Veel organisaties gebruiken SCCM voor software deployment, juist heel veel applicaties worden daar gedeployed via een .cmd script. Een organisatie met > 1000 medewerkers heeft al snel een applicatie of 50 die via SCCM gedeployed kan/zal worden. Die grotendeels via een cmd script worden afgevuurd.
Al die organisaties zullen eerst alle deployment scripts moeten aanpassen, naar een soortgelijk powershell script. Daar gaat tijd in zitten, tijd die veel organisaties niet hebben, want IT is een kostenpost, dus is bijna altijd onderbezet, waardoor er gewoon onvoldoende tijd is voor dit soort benodigde aanassingen/verbeteringen.

[kidde]

Erger nog, grote organisaties zouden zomaar eens PowerShell standaard kunnen blokkeren vanwege angst voor virussen. Zoals vroeger was waar ik werk.

Ik ga echt niet aan de PowerShell, en wel vanwege die reden. Vooral niet zo lang BAT bestanden blijven werken. De dag dat die stoppen te werken dondert ons bedrijf in elkaar

@walteij Nee, dat kan ik u niet uitleggen want ik ben geen systeembeheerder en ik maak geen beleid. Eerlijk gezegd vond ik het zelf ook vreemd. Ik als gebruiker weet alleen dat er het risico is, dat het niet overal in het bedrijf draait.

[Reactie gewijzigd door kidde op 23 juli 2024 01:36]

[walteij]

Erger nog, grote organisaties zouden zomaar eens PowerShell standaard kunnen blokkeren vanwege angst voor virussen.

Kun je me uitleggen waarom het risico op virussen bij Powershell script groter zou kunnen zijn dan bij batch files?
Zomaar een willekeurig script van internet trekken, zonder dit te begrijpen of door te nemen wat het doet, daar zie ik uiteraard ook wel het risico van in, maar dat risico is net zo groot in een batch file.
Altijd de code controleren van het script dat je download of doorgestuurd krijgt, nooit zomaar uitvoeren, bij voorkeur door 2 verschillende personen na laten kijken. Als je de code niet geheel vertrouwd, deze in een sandbox of niet connected VM omgeving uitvoeren om te zien wat het wil doen.

[HNO2]

Zoiets?: https://mcpmag.com/articl...-zero-day-powershell.aspx

[walteij]

Dat zeg ik. Nooit zomaar een powershell script van internet downloaden en uitvoeren.
Een script, dat een tweede script download en uitvoert, dat een derde script uitvoert die code uitpakt en in het geheugen dumpt om een geheugenlek in win32k.sys te misbruiken.

Het commentaar verderop is ook wel grappig:

The use of PowerShell for the attacks isn't new. Attackers use it mostly because it's part of Windows systems and doesn't leave file signatures for malware engines to detect.

Dat is met VBscript of CMD file precies hetzelfde. Ook die scripts kunnen gebruikt worden om een aantal nieuwe scripts te downloaden en uit te voeren om daarna code uitpakken, om die in het geheugen te dumpen en een lek in win32k.sys te misbruiken.

Is dus niets nieuws, alleen via een nieuwe taal.

[segil]

Je hoeft het toch niet te leren? Zoals @walteij ook al zegt, je hebt alternatieven voor de bekendste cmd commando's. Dat is een kwestie van omschakelen. Verder hoef je geen complexe functions te leren schrijven om een ping uit te voeren. En meerdere cmd commando's zijn een alias in Powershell. Hoe simpel wil je het hebben?

Het komt nu een beetje over als "ik ben gewend om het op deze 30 jaar oude manier te doen en geen zin om het anders te gaan doen". Dan zit je toch in het verkeerde beroep

[marcovtjetje]

De meeste mensen zijn pas met Windows XP in 2002/2003 naar de NT series met cmd.exe overgestapt.

Maar goed, de hoofdreden is dat de verandering voor de meeste mensen alleen nadelen heeft, namelijk conversie kosten.

Als we een OS wilden dat elke paar jaar totaal veranderd, dan gebruikte we wel een Mac. Als we een DIY kit wilden, gebruikten we wel *nix.

[Chinco]

Dat laatste is met stip de beste beschrijving van de OS-en.

En allemaal hebben hun eigen functie, liefhebbers en doel.

[mphilipp]

Maar zolang er geen dwang is, hoef ik het toch ook niet?

Ik leer met mijn werk genoeg nieuwe dingen. Soms heb ik geen zin om mij ergens in te verdiepen.
En inderdaad @walteij ik heb het niet beroepsmatig nodig. Daar gebruik ik andere dingen.

[marcovtjetje]

Er is altijd dwang, zelfs als het maar alleen het bevoordelen van de alternatieven is.

[[Jules]]

Omdat cmd.exe met een been al buiten de deur staat. Het gaat weg.

[mphilipp]

Dan merk ik dat vanzelf wel. Zolang het niet moet, kan die MS manager vinden wat ie vindt, maar dat boeit mij verder niet zo.

[EraYaN]

Maar goed dan mag men ook niet zeuren als het er dan echt uit gaat, maar het verleden leert dat men dan alsnog heel erg gaat zeuren dat het "onverwacht" en "onbegrijpelijk" is... Dus vandaar dit soort berichtgeving omdat MS hoopt dat tenminste 1 iemand denkt "oohja" en geen nieuw project begint gebaseerd op .bat en .cmd scripts.

[SPee]

Tegen die tijd zullen er vast populaire tooltjes komen die CMD zullen simuleren

[mphilipp]

Ik beloof dat ik niet zal zeuren...

[joco]

probleem is een beetje
ipconfig
netstat
ping

rolled van de tong, makkelijk te onthouden
maar ben nu al weer vergeten dat Get-NetIPConfiguration er ook is.

je hebt dan completion op "Get-" maar dan krijg je zo verschrikkelijk veel.

voor "which" is er ook een powershell command, maar ben al weer vergeten wat dat was..
nu heb ik voor die wel al een mapping aangemaakt dus "which prog" doet wat ik verwacht nu ipv die ellenlange powershell command.

[boe2]

...daarom dat al deze commandos aliases hebben in powershell, net zoals dat in linux gebeurt.

[walteij]

Het rolt makkelijk van de tong, omdat we dit allemaal al sinds Windows 2000 gebruiken. Zoals @SinergyX terecht zegt, de CMD musclememory is volledig ingebouwd.

Ik heb (beroepshalve) bewust gekozen om Powershell te leren en te gaan snappen. De musclememory training hoort daar bij. Ik vind het wel leuk om de mogelijkheden van Powershell wat verder te ontdekken. Ik ben echt geen powershell held, schrijf maar eenvoudige functies en heel soms een simpele module.

Ik ken mensen die kunnen echt alles doen in Powershell, ik kan steeds meer, maar zeker niet alles. Als ik iets in de command prompt wel kan en niet in Powershell, ga ik dus ook zitten puzzelen tot het in Powershell wel lukt. Soms gaat dat heel snel, soms duurt dat wat langer.

[smiba]

Het rolt ook makkelijk van de tong omdat het korte namen zijn ipv. complete commandos

Ik zie mezelf niet zo snel tegen me collega zeggen "Doe ff een Get-NetIPConfiguration", maar wel "Doe ff een ping"

[geoffrey.vl]

correct, bovendien werkt ping ook op andere omgevingen, en wordt bv ipconfig ifconfig op linux/unix dat kan ik ook nog net onthouden. Maar als ik eens af en toe een de IP gegevens snel wil ophalen dan valt die powershell syntax toch wel tegen eerlijk gezegd

[Reactie gewijzigd door geoffrey.vl op 23 juli 2024 01:36]

[SinergyX]

Ik heb de basis van CMD al, ik hoef niets te leren want ik weet dat al. PS kan dit prima vervangen, absoluut met je eens, maar musclememory om CMD te typen gaat iets moeilijker dan simpel 'leren'.

[ArawnofAnnwn]

Ik ben niet zo thuis in Windows maar ik heb best wat cmd scripts geschreven, meer dan ik zou willen. Nu moest ik laatst onder Windows 10 iets voor elkaar krijgen dat alleen onder powershell werkt. Het is dat het windows specifieke dingen zijn, anders had ik al lang gekeken of ik het met een bash script had kunnen oplossen. Dat is tenminste logisch, duidelijk, overzichtelijk.

Als je het via een manager doet, zoals SCCM zoals sommige organisaties gebruiken, dan is het allemaal goed te doen. Maar dan moet je wel eerst het script maken. Het is imho niet de meest logisch opgezette taal.

[Z80]

Om even te weten of de een systeem of netwerk nog reageert heb ik aan ping ruim voldoende.
Alle andere info of meer typewerk is overbodige ballast.

En net even snel een testje wat Test-NetConnection terug geeft. Wachten na de enter ipv direct de gevraagde info. Indien ip6 beschikbaar krijg je enkel die info. ping succeeded: True
reply: ** ms
Ja leuk maar hoe snel per ping. Hoeveel keer ping pakketjes verstuurd?

We kunnen ook Test-NetConnection -InformationLevel "Detailed".
Niet dat je daarmee kunt zien of je connectie stabiel is, maar klinkt leuk.

Maar hoe laat dit commando gewoon zien hoe lang elk pakketje er over doet?

[Reactie gewijzigd door Z80 op 23 juli 2024 01:36]

[Tiepvoud1]

Diezelfde handelingen kan je ook met de meegeleverde Powershell.exe (en nog veel meer).

[SinergyX]

Dat zal prima, maar cmd typen is iets meer ingebakken dan pow (ok, pwo werkt ook).

(en PS kan niet omgaan met de standaard dir /w, om nu eerst naar PS te gaan, daar CMD te typen, dan verder te gaan, mij te omslachtig).

Powershell is wel fijner, kleurnotatie op commando's, bizar veel nieuwe features, maar het is alsof je heel je PC opstart om alleen even te kijken hoe laat het is.

[segil]

Hoezo? PS start binnen een paar seconden en je hebt een cli, net zoals met cmd. Het is niet alsnof het 30 sec duurt. Enige wat iets anders kan zijn is het commando dat je moet intypen. Maar een aantal cmd commando's hebben een PS alias.

[glennoo]

Okay maar als ik zelf al die andere dingen niet gebruikt, dan is het alleen overstappen om het overstappen.

[Cergorach]

Diezelfde handelingen kan je ook met de meegeleverde Powershell.exe (en nog veel meer).

Mee eens, maar ik vraag me dan toch af waarom ik altijd nog CMD open gooi voor inderdaad ping en tracert, etc. Zelfs als ik meerdere versies van Powershell open heb staan... Net maar even gaan testen en CMD start toch iets sneller op dan PWO, scheelt miniem. Wellicht gewenning (na 13 jaar)?

[t link]

powershellkan praktisch alle commands die je in cmd.exe kan.

[Wim-Bart]

Add-Type -AssemblyName System.Speech
$sp = New-Object -TypeName System.Speech.Synthesis.SpeechSynthesizer
$sp.Speak('CMD is for loosers')

En veel leuker wanneer je dit met powershell remoting doet

[TheAnimaL]

Het concept shell en executables is bij sommige mensen in de Windows wereld nog niet geland zie ik.

Shell:
Een gebruikers interface voor de services of programma's van een computer.

Executable:
Ook wel een programma of een service. Een programma op de computer dat een serie taken uit voert.

De grafische schil van windows is een shell, word is een programma.
Powershell ( what's in a name ) en CMD zijn een shell, ping, netstat en ipconfig zijn programma's.

De tools die jij dust gebruikt zijn niet afhankelijk van de shell die je gebruikt. In de Unix wereld is dit trouwens een normaal concept waarmee je opgroeid. Door de manier waarop Microsoft in het verleden de commandline heeft willen wegmoffelen helpt hier niet, sterker nog je ziet de laatste tijd dat Microsoft zich meer en meer gaat richten op die commandline. Goede zet, maar naar mijn idee veel te laat.

[Reactie gewijzigd door TheAnimaL op 23 juli 2024 01:36]

[Anoniem: 58485]

Nee ze willen juist dat je door de baan van een supermoeilijk OS moet wanen om snel en eenvoudig een cmd opdracht in te tikken. Imbecielen.

Ik gebruik het (veels) te vaak nog. Blijf van CMD af.

Windows key > CMD > "....."

Gaat 10x productiever dan een icoontje ergens uit een lijst halen.

[webside007]

ik gebruik CMD heel vaak, privé & op het werk...

[Xm0ur3r]

Waarom als ik vragen mag? (oprechte vraag) PowerShell doet toch hetzelfde?

Ik gebruik PowerShell bijna elke dag maar ben nog niet tegen iets aangelopen waarop CMD mijn voorkeur zou moeten hebben.

[OMX2000]

Mijn beef met Powershell is dat het weer een nieuwe syntax is die je moet leren die nergens op lijkt. Het is het dos/cmd en lijkt ook niet op bash/zsh of whatever. Ik moet dus google-en als ik een dir /s wil doen. Of een ls -latr (lijst van bestanden omgekeerd gesorteerd op tijd). Kort en bondig

Powershell voegt pas wat toe als je scripy gaat programmeren. En ook daar vind ik het crap omdat ze dan beter een C# scipt variant hadden kunnen maken.

[alex3305]

Alhoewel verandering altijd frustratie met zich meebrengt, vind ik de overstap naar Powershell wel echt super relaxed. Vooral in de recentere versies ben ik er echt heel erg blij mee. Nagenoeg alle commando's die in cmd werkte, werken nagenoeg identiek in Powershell. Ze zijn echter meer dan de unix-variant van commando's toegstapt. Dus een [mono]dir /s[/] wordt dan [mono]dir -s[/].

Echter hebben ze ook aliases toegevoegd voor veelgebruikte unix commando's zoals [mono]ls[/] of [mono]wget[/]. Dat maakt de overstap, vind ik, ook een stuk beter. Tevens heb je ook autocomplete er in zitten wat met enige regelmaat erg van pas komt en kun je simpele [mono]man[/] pages opvragen over commando's.

Zelf gebruikte ik altijd cmd omdat ik dat simpelweg gewend was. Maar met de introductie van Windows Terminal gebruik ik eigenlijk alleen nog maar WSL (ZSH). Daarin kun je ook Windows programma's runnen, mits je er de [mono].exe[/] extensie achter plakt. Vanwege compatibiliteit wil ik nog weleens terugpakken naar Powershell en dat gaat nagenoeg moeiteloos.

Met betrekking tot scripting; het is een soort C# variant die je kunt gebruiken. Sterker nog, je kunt cmdlets bouwen in C# en die direct in Powershell gebruiken. In combinatie met de Powershell ISE en MSDN is het dan echt heerlijk werken en kun je relatief eenvoudig problemen oplossen waar je in het oude cmd niet aan wilt beginnen...

Enige 'nadeel' van Powershell vind ik de standaard gekozen kleurstelling. Ik snap dat ze met het blauw willen differentiëren van cmd, maar het contrast hiervan vind ik gewoon matig. Vooral bij foutmeldingen. Vandaar dat ik dus ook Windows Terminal gebruik.

[hottestbrain]

Wie weet dat je hier blij van wordt dan: Powershell core varianten hebben die kleurstelling niet meer en draaien native op Linux.

[Willem2]

Kleuren, lettertypes, etc. kun je al sinds jaar en dag instellen zowel voor cmd als ps hoor (even met rechts op het ps icoontje linksboven klikken en naar properties gaan)

[alex3305]

Dat is, gelukkig, bekend. Daarom gaf ik ook aan dat ik de standaard gekozen kleurstelling niet prettig vind. Daarnaast is dit overigens wel vervelend als je meerdere servers beheert, met soms ook verschillende gebruikersprofielen. Immers blijf je dan aan het aanpassen.

[[Jules]]

Je kunt vanuit Powershell rechtstreeks .NET aanspreken. En als je echt los wilt kun je doodleuk c# broncode inladen.
Maar je hebt gelijk, het is weer een nieuwe syntax. What else is new? Nieuwe syntax wordt wel vaker geintroduceerd.
Zoals @sjanssen15 al zegt: kwestie van gewenning.

[alexbl69]

Nou ja, dat is dus het hele punt...

Met cmd.exe kan ik nog steeds de commando's gebruiken die ik 35 jaar geleden voor het eerst geleerd heb.

Niks nieuwe syntax. Eindelijk iets dat niet om de haverklap 'vernieuwd' wordt.

[Mathijs]

100% met je eens

[walteij]

Je kunt natuurlijk ook gewoon aliasen of functies toevoegen in powershell. Met de volgende functie kun jij gewoon ls -lrt gebruiken ipv Get-ChildItem | Sort-Object -Property LastWriteTime

[code]
function ls {
param(
[Switch] $lrt
)
if ( $lrt ) {
Get-ChildItem | Sort-Object LastWriteTime
}
else {
Get-ChildItem $args
}
}
[/code]

[TheVMaster]

Maar aliassen zoals ls en dir werken gewoon out of the box in PowerShell...

[walteij]

Maar de argumenten van ls werken niet.
ls -lart werkt niet in powershell:

Kijk maar:

PS C:\> ls -lart
Get-ChildItem : A parameter cannot be found that matches parameter name 'lart'.
At line:1 char:4
+ ls -lart

En voor dir /p

PS C:\> dir /p
dir : Cannot find path 'C:\p' because it does not exist.
At line:1 char:1
+ dir /p
+ ~~~~~~
+ CategoryInfo : ObjectNotFound: (C:\p:String) [Get-ChildItem], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

Juist voor de argumenten die meegegeven worden, zul je (eenvoudige) functies moeten schrijven.

[Reactie gewijzigd door walteij op 23 juli 2024 01:36]

[g4wx3]

CMD is snel makkelijk en daarom handig om kleine dingen op te vragen.
Maar batch-scripten is echt een hell!
Er zijn wel dingen die helpen zoals setlocal delayedexpansion
Maar er zijn nog zoveel meer valkuilen, met simpele commando's als IF, FOR, GOTO..SET,CALL
Zonder handleiding krijg je een script moeilijk "bugvrij" (voor zover bewijsbaar)
Ik help even:
https://ss64.com/nt/delayedexpansion.html
https://ss64.com/nt/setlocal.html
https://ss64.com/nt/set.html
https://ss64.com/nt/syntax-redirection.html
https://ss64.com/nt/if.html
https://ss64.com/nt/for.html
https://ss64.com/nt/call.html
https://ss64.com/nt/echo.html

[sjanssen15]

Denk dat het gewenning is en snelheid: voor mij is het WIN+R en dan CMD [enter]. Zeker voor simepel ipconfig of ping. Maar voor de rest Powershell all the way (ook op Linux).

[PageFault]

WIN+X en dan A, nog minder typewerk op in powershell te komen (Windows 10).

[Z80]

En dan wachten tot de prompt in powershell eens van plan is te verschijnen. CMD heeft die vertraging niet.

[PageFault]

Vreemd, hier heb ik geen vertraging. Maar, op sommige systemen die ik tegen kom, is alles traag na win+r, ook bijv. Cmd, services, regedit. Geen idee waar dat aan ligt. Bij mijn systeem gaat het wel snel.

[Heidistein]

Nou... Beetje stomme reden voor mij. Ik begrijp in de regel helemaal niks van Windows. Ik gebruik het sinds versie 2000 niet meer als 'daily driver', gebruik het alleen sporadisch voor 'dingen'. Op het werk moet ik nog wel eens iets op een Windows server doen, en sinds het bijna allemaal Core versies zijn moet ik vaak puzzelen.
Ik ken de ms-dos syntax van toen, en dat lijkt best wel op bash, waar ik wel de hele dag in rammel.
Powershell is een nieuwe syntax en werkt op een nieuwe manier. Als je anders gewend bent is dat heel lastig leren. Tevens is niet out-of-the-box het hele OS ontsloten via PS; soms moet je externe scripts installeren. Dat laat ik dan maar.
En alle commando's zijn zoooooooooo lang! Wat is dat?

[PolarBear]

En alle commando's zijn zoooooooooo lang! Wat is dat?

tab autocomplete en aliassen zijn je vriend.

[Heidistein]

Hmm... Ja, je bedoeld, tab, vekrkeerde commando, heel veel backspace, maar letters meer en weer eens proberen?
Ik vind het fijner dat de tabcomplete (zoals bash) stopt bij de eerste keuze, en dan de opties laat zien.
Aliassen werken natuurlijk alleen op 1 machine, niet als je 100 verschillende servers sporadisch even kijkt.

[Mellow Jack]

Shift tab om terug te gaan

[EraYaN]

En Ctrl+Space on een menu van opties te krijgen.

[EraYaN]

Aliassen zijn prima te deployen naar je (roaming) Windows profiel.

En je kunt je complete type instellen: https://docs.microsoft.co...ll-7#completion-functions

Gebruik Set-PSReadLineKeyHandler om de config te wijzigen (in je profiel)

[Reactie gewijzigd door EraYaN op 23 juli 2024 01:36]

[Caayn]

En alle commando's zijn zoooooooooo lang! Wat is dat?

Veel commandos kan je afkorten, bijvoorbeeld:

Get-ChildItem -> gci
ForEach-Object -> foreach -> %
Where-Object -> where -> ?

Onderstaande twee regels doen exact hetzelfde, de een is alleen een heel stuk korter en minder verbose.
Get-ChildItem C: | Where-Object {$_.length -lt 5} | ForEach-Object {$_}
gci C: | ? {$_.length -lt 5} | % {$_}

Cheat sheet: https://devblogs.microsof...asic-powershell-commands/

Sommige commandos zijn inderdaad tergend lang. Lang leven de "tab" knop, totdat die een verkeerd commando selecteert... Gelukkig kan je de werking van de "tab" key aanpassen. Zelf vind ik "Set-PSReadlineKeyHandler -Key Tab -Function MenuComplete" het fijnste werken.

[Reactie gewijzigd door Caayn op 23 juli 2024 01:36]

[EraYaN]

Voor iedereen hier is een lijst van complete functions: https://docs.microsoft.co...ll-7#completion-functions

[mschol]

op een vlot systeem vind ik powershell trager starten tov cmd, voor mij al genoeg reden om bij cmd te blijven, alle powershell commando's zijn imho ook een draak bij sporadisch gebruik

[gooos]

Ik gebruik eigenlijk ook in 99,9% van de tijd gewoon de command prompt. Denk dat het vooral is omdat cmd zo lekker kort intypen is ten opzichte van powershell. Als ze er een shortcut van ps voor maken zal dat het gebruik van PowerShell ongetwijfeld ten goede komen.

[[Jules]]

Dan zit je op de oude <5.1 versie?
Alle nieuwere versies is domweg pwsh tikken.
Nou, vooruit, 1 extra toetsaanslag.. m'n leven...

[gooos]

Nee, op W10. Aha, dat is een stuk korter dan powershell voluit en die ene extra letter tov cmd is inderdaad te verwaarlozen, ben benieuwd hoe snel dat in mijn routine gaat zitten

[Martinspire]

De reden dat ik het gebruik is vooral omdat ik niks nodig heb van PowerShell. Mijn werk bestaat vooral uit nodejs commando's invoeren en dat kan in eenderwelke.

Overigens gebruik ik nu cmder (soort wrapper programma bovenop cmd die overigens ook powershell kan doen) dus ik zou kunnen wisselen. Ik vind het vooral fijn om meerdere tabs naast elkaar te openen en bij het opstarten van de app al meteen mijn folders te openen van het project waar ik mee aan de slag ga.

Je zit in de automatisering of niet

[webside007]

Uit gewoonte & eenvoud denk ik
Klopt, maar met andere commando’s.

[beerse]

Zelf spring ik nog wel eens even snel naar cmd om de omgevingsvariabelen uit te lezen, gewoon omdat het met `cmd ` gevolgd door `set` een simpel overzicht geeft. Eventueel even snel door `findstr` pijpen en ik vind meestal snel wat ik hebben moet.

En om een shortcut in elkaar te hakken: Wat op de cmd.exe prompt werkt, werkt vaak ook in een shortcut. Maar de powershell commando's in de regel niet. En zo ook voor de scheduler (tasks) en dergelijke.

[g4wx3]

Wat op de cmd.exe prompt werkt, werkt vaak ook in een shortcut
Dat is een zeer goeie opmerking!
Anderzijds maken virussen hier ook juist misbruik van, en had een shortcut nooit de extra mogelijkheden mogen hebben. Achja, nieuw decenium, bye flash, ActiveX, HTA.. CMD zal ook wel mogen gaan

[beerse]

Wat in cmd.exe werkt, werkt ook in:
start.exe
invoke-command
shortcut
scheduled-task
'default program' instelling zoals dat vanuit de explorer/verkenner wordt gebruikt op basis van de extentie.

In al deze (en nog meer) plaatsen gebruik je het volledige path naar de executable, een 'starting directory' en een lijst met opties.

Vanuit powershell werkt veel meer, want ook de powershell commando's. Het aantal ingebouwde commando's bij cmd.exe is (gelukkig) zeer beperkt.

[walteij]

Na jarenlang met de commandprompt te hebben gewerkt, ben ik sinds server 2012 overgestapt op Powershell.
In Powershell kan ik sneller, eenvoudiger en vooral meer doen dan ik ooit in de command prompt heb gedaan. De command prompt is inderdaad (voor mij zeker) verleden tijd. Powershell is zowel het heden als de toekomst.

[Swerfer]

Voor een ipconfig gebruik ik nog altijd de cmd, maar daar houdt het verder wel mee op denk ik...

[xouns]

Alle CMD commandos werken ook gewoon in Powershell, dus zelfs dat hoef je niet te doen.

[Anoniem: 392841]

Niet alle hoor. Ipconfig/all wilt PS niet aan, moet wel zeggen dat het een van de uitzonderingen is.

[beerse]

Dan moet je netter typen. Er hoort een spatie tussen het commando en de opties. De cmd.exe is vergevingsgezind als ze het commando kan herkennen, powershell iets minder. Natuurlijk kan je daar een alias voor maken, zoals ik dat onder unix/linux ook altijd deed voor ls-l.

[Alex3]

Mklink werkt niet.

[kid1988]

ik heb ook mijn default "win-X A" in windows 8 vrij snel vervangen door powershell. Al moet ik toegeven dat voor mijn gevoel sommige commando's anders zijn in powershell en dan start ik vaker CMD op dan dat ik op zoek hoe ik het in powershell zou moeten doen.

[iWishmaster]

Ik gebruik een handvol commando's in CMD, de rest heb ik niet nodig, alles wat Powershell meer kan, heb ik nog nooit nodig gehad en zal ik waarschijnlijk nooit nodig hebben. Ik wil best powershell gaan gebruiken hoor, moet ik alleen even wennen aan de syntax van die 5 commando's.

[Wim-Bart]

Ligt geheel aan de toepassing.
Voor complexe integratie en scripts is Powershell fantastisch, maar voor een eenvoudig script wat 5 keer ROBOCOPY aanroept is CMD misschien wel sneller, zeker omdat je bij een scheduled task gewoon c:\Scripts\Mijnscript.cmd kan aanroepen en je niet hoeft na te denken over "powershell.exe" en o ja, je moet ook nog de juiste argumenten mee geven omdat ie het anders niet doet.

[g4wx3]

maar cmd is dan wel weer veel foutgevoeliger dan powershell, al die uitzonderingen met variabele in een for die het dan niet doen, of je moet !var! gebruiken, wat dan weer een ander probleem teweeg brengt.
Anderzijds ook te misbruiken 1 lijn variabelen te wisselen met %disabledelayedexpansion%

[Wim-Bart]

Of het magische shift commando
Of CALL :label / GOTO :EOF