Benutzer mit den meisten Antworten
Wildcards are permitted. -> Accept wildcard characters? false

Frage
-
Mich treibt die Hilfe noch in den Wahnsinn.
Das Problem dieser widersprüchlichen Informationen finde ich öfters.
Get-Help Get-Help -Parameter para* -Parameter <String> Displays only the detailed descriptions of the specified parameters. Wildcards are permitted. This parameter has no effect on displays of conceptual ("About_") help. Required? true Position? named Default value None Accept pipeline input? False Accept wildcard characters? false
Warum steht bei "Accept wildcard characters?" "false"? Dies ist doch offensichtich falsch. Eine Regel kann ich nicht finden und ein "Get-Help about_Parameters" sagt:
Get-Help about_Parameters ... Accepts Wildcard Characters? This setting indicates whether the parameter's value can contain wildcard characters so that the parameter value can be matched to more than one existing item in the target container.
Eine Suche im Netz hat mir auch nicht helfen können. Ich bin für jede Hilfe dankbar, gerne auch ein Link, unter dem ich eine vernünftige Erklärung bekomme.
Liebe Grüße,
cc- Bearbeitet cgplc Samstag, 28. Juli 2018 00:25 Rechtschreibfehler korrigiert
Antworten
-
Moin,
da muss ich Olaf mall widersprechen ;-)
Diese spezielle Diskrepanz rührt daher, dass die Hilfe zum Teil NICHT von Menschen erstellt wird, der maschinelle Prozess aber ein paar Limitierungen hat, z.B. diese:
Evgenij Smirnov
I work @ msg services ag, Berlin -> http://www.msg-services.de
I blog (in German) @ http://it-pro-berlin.de
my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
Exchange User Group, Berlin -> https://exusg.de
Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com
In theory, there is no difference between theory and practice. In practice, there is.
- Als Antwort markiert cgplc Samstag, 28. Juli 2018 06:40
Alle Antworten
-
Mich treibt die Hilfe noch in den Wahnsinn.
Warum denn das? Hast Du irgendein Problem mit einem Script oder mit Code, den Du geschrieben hast und das/der nicht funktioniert?
Wenn Du Dir sicher bist, dass Du einen Fehler gefunden hast, kannst Du den natürlich gern an Microsoft melden. Auch die Hilfe wird von Menschen erstellt und Menschen können Fehler machen.Du kannst inzwischen sogar selbst mitmachen. Powershell Core ist ja jetzt Open Source und Du kannst auf GitHub mitmachen.
Meine Empfehlung wäre, einfach ein bissl fehlertoleranter beim Lesen der Hilfe zu sein und im Zweifel, die Sachen einfach auszuprobieren. Es geht am Ende ja doch eher darum, lauffähigen Code zu erzeugen und nicht fehlerfreie Hilfe zu haben. ;-) :-D
Best regards,
(79,108,97,102|%{[char]$_})-join''
-
... Auch die Hilfe wird von Menschen erstellt und Menschen können Fehler machen. ...
Meine Empfehlung wäre, einfach ein bissl fehlertoleranter beim Lesen der Hilfe zu sein und im Zweifel, die Sachen einfach auszuprobieren. Es geht am Ende ja doch eher darum, lauffähigen Code zu erzeugen und nicht fehlerfreie Hilfe zu haben. ;-) :-D
Best regards,
(79,108,97,102|%{[char]$_})-join''
Du meinst, die Hilfe ist falsch und es gibt keine vernünftige Erklärung, außer dass Menschen halt Fehler machen und der Fehler ist bis heute nicht aufgefallen? Das mag ich nicht glauben.
Kann ich sicher sein, dass ein Code, der mir funktioniert auch überall funktioniert? So wie ein "fflush(stdin);" in C? Der Standard sagt Nein (undefniertes Verhalten). Linux-Programmierer werden dies bestätigen können, Buchautoren ganz häufig nicht. Ist "ausprobieren" wirklich ein sicheres Vorgehen? Ganz sicher nicht!
Ich bevorzuge eine verlässliche Dokumentation, bei der ich mich darauf verlassen kann, dass eine Lösung portabel ist. Ansonsten kann ich leider nicht sagen, ob ich mit einem Skript ein Problem haben werde. Meine Skripte laufen ja nicht zwangsläufig nur bei mir.
Dennoch vielen Dank für Deine Antwort. Sie spendet etwas Trost.
cc
-
Moin,
da muss ich Olaf mall widersprechen ;-)
Diese spezielle Diskrepanz rührt daher, dass die Hilfe zum Teil NICHT von Menschen erstellt wird, der maschinelle Prozess aber ein paar Limitierungen hat, z.B. diese:
Evgenij Smirnov
I work @ msg services ag, Berlin -> http://www.msg-services.de
I blog (in German) @ http://it-pro-berlin.de
my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
Exchange User Group, Berlin -> https://exusg.de
Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com
In theory, there is no difference between theory and practice. In practice, there is.
- Als Antwort markiert cgplc Samstag, 28. Juli 2018 06:40
-
Default values and a value for "Accept Wildcard characters" do not appear in the "Parameter attribute table" even when they are defined in the function or script. To help users, provide this information in the parameter description.
Danke, das ist eine Erklärung, die ich erst einmal nachvollziehen kann.
Vielen Dank.
cc
-
Du meinst, die Hilfe ist falsch und es gibt keine vernünftige Erklärung, außer dass Menschen halt Fehler machen und der Fehler ist bis heute nicht aufgefallen?
Nein, ich meinte, dass die Hilfe Fehler enthalten kann ... und übrigens nicht nur der Hilfe. :-) Und dass es eventuell zielführender und weniger frustrierend für Dich sien könnte, wenn Du Dich nicht von solchen Fehlern bremsen lässt und nicht darauf konzentrierst, sondern auf Deinen Code, bzw. die Aufgabe, die Du lösen möchtest. Zumal es hier ja offenbar nicht mal um "produktive" cmdlets ging, sondern um die Hilfe für die HIlfe. :-D
Darf ich Dich nach dem Hintergrund Deiner Fragen fragen? Kann es sein, dass Du gerade angefangen hast, ein Powershell-Buch zu lesen? (nur reine Neugier von mir - Du musst darauf auch nicht antworten, wenn Du nicht magst ;-) )
Best regards,
(79,108,97,102|%{[char]$_})-join''
-
Du meinst, die Hilfe ist falsch und es gibt keine vernünftige Erklärung, außer dass Menschen halt Fehler machen und der Fehler ist bis heute nicht aufgefallen?
Nein, ich meinte, dass die Hilfe Fehler enthalten kann ... und übrigens nicht nur der Hilfe. :-) Und dass es eventuell zielführender und weniger frustrierend für Dich sien könnte, wenn Du Dich nicht von solchen Fehlern bremsen lässt und nicht darauf konzentrierst, sondern auf Deinen Code, bzw. die Aufgabe, die Du lösen möchtest. Zumal es hier ja offenbar nicht mal um "produktive" cmdlets ging, sondern um die Hilfe für die HIlfe. :-D
Darf ich Dich nach dem Hintergrund Deiner Fragen fragen? Kann es sein, dass Du gerade angefangen hast, ein Powershell-Buch zu lesen? (nur reine Neugier von mir - Du musst darauf auch nicht antworten, wenn Du nicht magst ;-) )
Best regards,
(79,108,97,102|%{[char]$_})-join''
Ich antworte gerne.
Nein, ich habe nicht gerade angefangen ein PowerShell-Buch zu lesen. Das Beispiel mit Get-Help war auch nur ein Beispiel. Ich hätte auch auf "Get-help Get-Command -Parameter Name" verweisen können.
Ich versuche zu verstehen, was ich vorfinde. Solange eine Lösung oder Antwort nicht logisch oder nachvollziehbar ist, bin ich nicht zufrieden. Dass auch beispielsweise eine Sprach-Spezifikation einen Fehler beinhalten kann, ist mir schon klar. In Java hatte ich vor ein paar Jahren einen Fehler entdeckt (nicht als Erster) und in C hatte ich einen vermutet (fehlt da nicht ein Semikolon? for(deklaration ausdruck;ausdruck) anweisung - Nein, das Semikolon steckt im Wort deklaration). In beiden Fällen habe ich gefragt und Dank der Antworten viel dabei gelernt. Hier auch wieder. Wie gehabt, ich bin für jede Antwort dankbar.
Liebe Grüße
cc
-
Das Thema Wildcard betrifft ja nicht die Hilfe sondern den Parameter des entsprechenden Kommandos.
Dass bei "Get-help Get-Command -Parameter Name" der Wert "Name" keine Wildcard erlaubt ist doch logisch da ich die Hilfe zum Parameter "Name" des "get-command" haben will.
Dass zur Ausführungszeit von "get-command -name parameters" dann parameters generisch sein können beschreibt dann die Hilfe schon.Und was den flush(stdin) angeht, so kann ich verstehen, dass dies nicht jeder implementiert da es eigentlich Unsinn ist.
flush() ist eine Ausgabefunktion des beschriebene Puffers, stdin ist aber eine Eingabe-Datei. Ein flush(stdout) hat immmer und überall bisher die selbe Wirkung gehabt.
Dies ist genauso, wie wann du am falschen Ende einer Einbahnstraße alle rauswinken würdest. -
Dass bei "Get-help Get-Command -Parameter Name" der Wert "Name" keine Wildcard erlaubt ist doch logisch da ich die Hilfe zum Parameter "Name" des "get-command" haben will.
Nein,nein. Da hast Du mich falsch verstanden. Bei der Ausgabe des Kommandos "Get-Help Get-Command -Parameter Name" ist das gleiche Problem zu finden.
Get-help Get-Command -Parameter Name -Name <String[]> Specifies an array of names. This cmdlet gets only commands that have the specified name.
Enter a name or name pattern. Wildcard characters are permitted. To get commands that have the same name, use the All parameter.
When two commands have the same name, by default, Get-Command gets the command
that runs when you type the command name. Required? false Position? 0 Default value None Accept pipeline input? True (ByPropertyName, ByValue) Accept wildcard characters? falseNebenbei, bei dem Kommando "Get-Help Get-Command -Parameter Name" sind Wildcards erlaubt. Das war ja meine ursprüngliche Frage.
cc
- Bearbeitet cgplc Samstag, 28. Juli 2018 13:27
-
"Enter a name or name pattern"
"Pattern" ist ein regulärer Ausdruck, während "Wildcards" ausschließlich "*" und "?" sind.
So gilt "*" alleine als Ausdruck nicht, da "*" der Repeater des vorherigen Ausdrucks ist, "." entspricht dem "?" und somit ".*" dem "*" des Wildcards.https://www.quora.com/Whats-the-difference-between-a-wildcard-and-a-regular-expression
-
"Enter a name or name pattern"
"Pattern" ist ein regulärer Ausdruck, während "Wildcards" ausschließlich "*" und "?" sind.
So gilt "*" alleine als Ausdruck nicht, da "*" der Repeater des vorherigen Ausdrucks ist, "." entspricht dem "?" und somit ".*" dem "*" des Wildcards.https://www.quora.com/Whats-the-difference-between-a-wildcard-and-a-regular-expression
Ok, dann muss also der Aufruf wie folgt lauten, wenn ich nur "Name" ausgegeben haben möchte:
Get-Help Get-Command -Parameter N.*e
und nicht
Get-Help Get-Command -Parameter N*e
Und folgendes ist dann wohl auch falsch:
Get-Help Get-Command -Parameter N??e
Nun, zumindest meine Konsole sieht das anders.
cc
-
Du befindest dich ja im "get-Help" und nicht im "get-command".
Get-Help soll die Hilfe von "get-command" zum Parameter des "get-command" mit dem Namen "Name" anzeigen.
Das Original ohne Hilfe wäre ja "get-command -name parameters"
Um aber die Hilfe zu "Name" anzeigen zu können, ist an dieser Stelle kein Wildcard erlaubt.
-
Du befindest dich ja im "get-Help" und nicht im "get-command".
Get-Help soll die Hilfe von "get-command" zum Parameter des "get-command" mit dem Namen "Name" anzeigen.
Das Original ohne Hilfe wäre ja "get-command -name parameters"
Um aber die Hilfe zu "Name" anzeigen zu können, ist an dieser Stelle kein Wildcard erlaubt.
Du redest in Rätzeln. Gib doch bitte mal ein Beispiel und zeige wo genau bei den genannten Kommandos und Parameter ein Wildcard nicht erlaubt ist. -
Ich habe dein Problem einfach nicht (Version 5.1):
PS C:\Users\Fürchau> Get-Help Get-Help -Parameter para* -Parameter <string> Erforderlich? true Position? Benannt Pipelineeingaben akzeptieren?false Name des Parametersatzes Parameters Aliase Keine Dynamisch? false
PS C:\Users\Fürchau> Get-help Get-Command -Parameter Name -Name <string[]> Erforderlich? false Position? 0 Pipelineeingaben akzeptieren?true (ByValue, ByPropertyName) Name des Parametersatzes AllCommandSet Aliase Keine Dynamisch? false