BOfH_666

Nee, siehste, das is mir glatt durchgerutscht. Gut, dass Du nochma rübergeguckt hast.

Cool. Ein Fehler weniger. Du erzeugst Dein "Menü" mit Write-Host. Damit ist das Menü vom eigentlichen Code völlig unabhängig. Das sind nur Pixel auf Deinem Bildschirm ohne weitere Funktion. Wichtig ist der Code, den Du benutzt, um die Eingabe des Benutzers auszuwerten. Davon hast Du aber bisher nur ein paar lose miteinander verbundene Schnipsel gezeigt. Damit kann ich leider nicht wirklich sehen, was Du in Deinem Code machst. Aber nicht, wenn Du das switch-Statement bereits einmal erfolgreich durchlaufen hast. Dafür müsstest Du die Auswahl erneut erhalten - also das switch-Statement erneut ausführen - mit einer Schleife zum Beispiel. ... es sei denn, ich habe Dich falsch verstanden. ... kommt immer mal wieder vor ... Vielleicht machst Du Dir einfach mal ein MockUp. Also ein Script-Gerüst, welches den Script-Ablauf zeigt, ohne die eigentlichen Funktionen auszuführen. So könntest Du die Menü-Struktur testen, ohne den Balast des Codes der Funktionen mitzuschleppen. Das macht es manchmal einfacher. Dann hast Du in Deinen externen Scripten irgendwo einen logischen Fehler. Hast Du eventuell im der Script-Datei mit der Funktionsdefinition für MyBenutzer, die Funktion MyBenutzer direkt aufgerufen? Edit: Hier mal ne kleine Demo: $Menu = @' Hauptmenue ================================================== 1 : Benutzerverwaltung 2 : Gruppenverwaltung -------------------------------------------------- 0 : zurück ================================================== '@ Clear-Host Write-Host $Menu function show-input { param ( $BenutzerEingabe ) "`n `t$BenutzerEingabe`n " } $Eingabe = Read-Host -Prompt "Bitte Zahl zwischen 1 und 5 eingeben " switch ($Eingabe) { 1 { show-input -BenutzerEingabe "Du hast wohl ne '1' eingegeben " } 2 { show-input -BenutzerEingabe "Du hast wohl ne '2' eingegeben " } 3 { show-input -BenutzerEingabe "Du hast wohl ne '3' eingegeben " } 4 { show-input -BenutzerEingabe "Du hast wohl ne '4' eingegeben " } 5 { show-input -BenutzerEingabe "Du hast wohl ne '5' eingegeben " } Default { show-input -BenutzerEingabe "Das muss irgendwas Anderes als 1 bis 5 gewesen sein!" } } } Nachdem Du etwas Beliebiges an der Eingabeaufforderung eingegeben hast, wird das switch-Statement genau 1 mal durchlaufen und dann beendet.

... und es sollte natürlich auch nicht heißen, dass Du hier nicht mehr fragen darfst ... auch zu diesem Thema/Script - jederzeit - dafür sind wir alle hier. Es macht uns ja auch selber Spaß

OK. Als erstes hast Du ihn Deinem MyMain einen Klammerfehler im switch-Statement. Das sollte so aussehen: Function MyMain { #Hauptmenue cls Write-Host Write-Host "Hauptmenue" Write-Host "==================================================" Write-Host "1":" Benutzerverwaltung" Write-Host "2":" Gruppenverwaltung" Write-Host "--------------------------------------------------" Write-Host "0":" EXIT" Write-Host "==================================================" $input = Read-Host "Auswahl" Switch ($input) { 0 { exit } 1 { . $m_benutzer MyBenutzer } 2 { . $m_gruppen MyGruppen } 3 { MyMain } DEFAULT { exit } } } MyMain Darf ich fragen, welchen Code-Editor Du benutzt? Sowohl die Powershell_ISE als auch VSCode würden diesen Syntaxfehler entsprechend markieren. ... oder ist das nur ein Copy-&-Paste-Fehler hier im Forum? Jetzt wo die Klammern stimmen, solltest Du, auch wenn es vielleicht im Moment funktioniert, dringend die Variable $Input ändern. $Input ist eine für Powershell reservierte Variable, die nicht für eigene Zwecke benutzt/missbraucht werden sollte, Hmm ... das switch-Statement wird von oben nach unten abgearbeitet. Wenn Du die Option 1 wählst, bist Du über die 0 schon drüber. Das kann also nicht funktionieren. ... und der Default-Zweig wird nur ausgeführt, wenn keine der zur Verfügung stehenden Optionen passt. Wenn Du immer wieder in Dein Hauptmenü zurück möchtest, wirst Du eine while oder do Schleife benutzen müssen. Es macht übrigens nicht wirklich viel Sinn, die "extenen" Scripte erst mittels dot-Sourcing in Dein Hauptscript einzubinden, wenn der entsprechende Menüeintrag gewählt wird. Einfacher wäre es, wenn Du am Anfang Deines Scriptes einfach mittels: Get-ChildItem $PSScriptRoot -Filter *.ps1 | ForEach-Object { . $_.FullName } alle weiteren Funktionen in den Scope Deines Hauptscriptes importiertest. Somit brauchst Du im Code nur noch mit den Funktionsnamen zu arbeiten. Damit wären wir beim nächsten Thema: Funktionsnamen. Wenn Du irgendwann mal Deine Scripte in Module umwandelst und diese vielleicht auch an Kollegen weitergeben möchtest, empfiehlt es sich, besonders für Funktionen, die direkt aufgerufen werden sollen, die gleiche Schreibweise zu benutzen, wie bei den eingebauten cmdlets - also <Verb>-<Nomen>. Das macht im Zweifel ihre Funktion direkt erkennbar und erleichtert das Verstehen und Debuggen. Empfehlenswerte Lektüre dazu ist The Unofficial PowerShell Best Practices and Style Guide.

Yep ... zeig uns bitte den relevanten Code. ... ohne diesen, wird es bestenfalls "Raten auf hohem Niveau"! Edit: Nur schon mal als Tipp, wenn das vielleicht ein Projekt ist, welches Du in Zukunft ausbauen möchtest. Du könntest Dir die Arbeit erleichtern, wenn Du die Anzeige Deines Menüs etwas weniger statisch gestalltest: $TaskList = @( 'Benutzerverwaltung' 'Gruppenverwaltung' ) $Index = 1 $IndexedTaskList = foreach ($Task in $TaskList) { [PSCustomObject]@{ Index = $Index Task = $Task } $Index++ } Clear-Host "`n`n`tAuswahl des Tasks:`n " $IndexedTaskList | Format-Table -AutoSize -HideTableHeaders Das mag für 2 auszuwählende Tasks etwas überkandidelt erschienen, aber wenn Dein Projekt wächst, wirst Du es vermutlich zu schätzen wissen.

Für alle Powershell-Nutzer, die mit VSCode unterwegs sind ... ... ich könnte gut mir vorstellen, dass das über kurz oder lang auch in der Powershell landet (natürlich nur v7 oder höher )

Schau mal hier: https://gpsearch.azurewebsites.net/

Möglichst bitte nicht so lange warten! ... das Wochenende steht vor der Tür ... und wir sind wegen Corona sowieso eingeschränkt ... warum nicht die Zeit sinnvoll nutzen? Soll das heißen, Du glaubst, dass ich meine Kenntnisse aus diesen beiden Quellen erhalten habe? ... Du bist ja putzig ... sagen wir einfach "Ich mache das schon lange genug, um ein wenig Erfahrung angehäuft zu haben.". "kleines bisschen Feinschliff"??? Du krempelst grade die Anforderungen um. Das hätte alles in Deine erste nachricht gehört. Fällt Dir wenigstens auf, dass Du hier die Anforderungen Stück für Stück erweiterst? 1. Was ist der Unterschied zwischen *.pdf und *.pdf. Das hast Du zwei mal. 2. Das hängt davon ab, ob Du während der Ermittlung der zu kopierenden Ordner danach suchen möchtest, oder ob Du nur die Dateien beim Copy-Job mit einschließen möchtest. Dann einfach bei robocopy ein weiteres "Datei-Muster" angeben. 3. Das lernst Du auch mit den Grundlagen von Powershell - wie die Hilfe zu lesen und zu verstehen ist. Die Hilfe ist übrigens in der Powershell eingebaut. Du kannst für jedes cmdlet in der Konsole oder in der ISE oder in VSCode einfach mit "Get-Help <cmdlet>" die Hilfe aufrufen. Hmmm ... bitte möglichst nicht falsch verstehen, aber ich glaube, das ist die Stelle, an der ich darum bitte, dass Du diese Erweiterungen selbst einbaust, sobald Du genug Powershell-Kentnisse erworben hast, um das alleine zu machen - wenigstens zum größten Teil. Angefangen hast Du - jedenfalls hab ich es so verstanden - mit PDF-Dateien in "B01_"-Ordnern, jetzt sind noch JPG-Dateien dazu gekommen - kein Problem - kannst Du bei robocopy einfach mit einschließen. Jetzt kommen aber noch "A01_"-Odner und PDF-Dateien dazu - die aber nur wenn sie mit "LF-" oder "BE-" anfangen .... Man kann so ein Script natürlich beliebig komplex gestallten. Aber je komplexer es wird, desto fehlerträchtiger und schwerer zu pflegen wird es auch gern mal. Dann kommen Wechsel- oder Nebenwirkungen dazu, die häufig sehr schwer zu ermitteln und zu beseitigen sind. Eventuell wird auch die Leistung/Verarbeitungsdauer beeinflusst. Du hattest am Anfang beschrieben, dass es um ca. 10TB an Daten in ca. 1000 Projekt-Ordnern mit den entsprechenden Unterordnern geht. Powershell ist, wenn es um Dateisytem-Operationen geht, nicht die beste (weil ziemlich langsame) Option, die man wählen kann. Deshalb ist auch robocopy immer wieder das Mittel der Wahl, weil es um Größenordnungen schneller ist. Wenn Du jetzt aber die Powershell benutzt, um quasi jede einzelne Datei zu identifizieren und robocopy dann fast nur noch einzelne Dateien kopieren soll, dann ist der Geschwindigkeits-Vorteil dahin und das Script läuft am Ende vielleicht so lange, dass es gar nicht rechtzeitig fertig wird. Vielleicht schaust Du erstmal, wie sich das Script, was Du bis jetzt hast, in der Praxis bewährt. Und in kurzer Zeit hast Du genug Powershell gelernt und kannst es entweder erweitern oder einfach ein zweites bauen, mit leicht angepassten Bedingungen.

Nee ... wir werden doch jetzt nicht anfangen, Pfade oder Laufwerksbuchstaben im Code hart zu verdrahten ... ich hätte vielleicht dazusagen sollen: "Pfoten weg von meinem Code! " ... nicht meinen Code anpassen - eigenen ergänzen. Dieser Teil hier: $QuellPfad = 'C:\Quelle\Desktop\Kopier-Skript\Test\Quelle' $ZielPfad = 'C:\Ziel\Desktop\Kopier-Skript\Test\Ziel' $OrdnerSuchMuster = '\\B\d{2}_' $PotenzielleBackupOrdnerListe = Get-ChildItem -Path $QuellPfad -Directory -Recurse | Where-Object { $_.FullName -match $OrdnerSuchMuster } | ForEach-Object { $DateiSuchMuster = Join-Path -Path $_.FullName -ChildPath '*.pdf' if (Test-Path -Path $DateiSuchMuster) { [PSCustomObject]@{ FullName = $_.FullName ShortName = $_.FullName -replace [REGEX]::Escape($QuellPfad) } } } ... war doch nur dazu da, zu zeigen, wie man die zu kopierenden Ordner ermittelt und die Pfade entsprechend aufbereitet. Die damit erzeugte Liste $PotenzielleBackupOrdnerListe können wir dazu benutzen, den Zielpfad zusammenzubauen und den Copy-Job anzustoßen: foreach ($PotenzielleBackupOrdner in $PotenzielleBackupOrdnerListe) { $KopierZielPfad = Join-Path -Path $ZielPfad -ChildPath $PotenzielleBackupOrdner.ShortName "Quelle : '$($PotenzielleBackupOrdner.FullName)' - Ziel: '$($KopierZielPfad)'" # Robocopy.exe $PotenzielleBackupOrdner.FullName $KopierZielPfad *.pdf } Die robocopy-Zeile ist noch auskommentiert. Wenn Du geprüft hast, ob die ausgegebenen Pfade zu Deinen Anforderungen passen, kannst Du das "#" vor robocopy entfernen. ... trotzdem nochmal mit Test-Daten und Test-Pfaden testen bitte!! Wenn dann mit den Test-Daten alles wie gewünscht funktioniert, brauchst Du nur noch die Variablenzuweisungen vom Anfang des Codes anpassen und es passt auch für die produktiven Daten. Doch, aber dann musst Du diesen auch angeben. Wie Martin schon erwähnte, ist $PotenzielleBackupOrdnerListe ein Array von Objekten mit Eigenschaften. Es gäbe zwar Möglichkeiten, das so zu bauen, dass sich Copy-Item die richtige Eigenschaft aus dem Object rauspickt, aber wir wollen ja sowieso robocopy benutzen. Und das kann damit eben nicht umgehen. Also müssen wir die entsprechende Eigenschaft der Objekte explizit angeben. Du hattest erwähnt, dass Du Dich näher mit dem Thema Scripting befassen möchtest. Das ist mit Sicherheit eine sehr gute Idee. Du solltest Dir ein bissl Zeit nehmen, um Dir die Grundlagen von Powershell draufzuschaffen. Ein guter Einstieg, wie ich finde, ist immernoch der Video-Kurs mit Jeffrey Snover: Getting Started with Powershell. Und wenn Du was zum Nachschlagen brauchst, kannst Du Dir das hier anschauen: Windows PowerShell™ 4: TFM. ... beides kostenlos.

Martin, Martin Martin. CDs und DVDs hat hier grad niemand auch nur erwähnt ... außer Dir!! Und USB-Sticks oder USB-Platten sind im Hochtechnologie-Land-Deutschland (leider) noch lange nicht aus der Mode. Auf dem flachen Brandenburger Land bist Du froh, wenn Du DSL-Light oder 16Mbit-DSL bekommst. Mit Glück hast Du dann eine hoffentlich stabile Upload-Bandbreite von vielleicht 2MBit. Darüber möchtest auch Du kein Backup in die Cloud schieben. Und es gibt auch noch Leute, die "der Cloud" nicht oder nur sehr eingeschränkt vertrauen und lieber etwas in der Hand haben, was sie wegtragen und einschließen können. ... wie gesagt ... kein Business - private Privat-Patienten. Wir leben halt nicht in der besten aller Welten, sondern in dieser ....

... klingt gut ... nicht für mich ... eher für meine "Privatpatienten".

Um dieses unglaublich unsägliche Gefrickel mit Laufwerksbuchstaben völlig zu umgehen, kann man - auch in Windows - einen angeschlossenen USB-Datenträger in einem leeren Verzeichnis "mounten". Dieser Pfad bleibt für ein gegebenes USB-Speichermedium immer der Gleiche - auch bei z.B. baugleichen Medien desselben Herstellers. Ich hab z.B. im Root von C: einen leeren Ordner USB in dem ich dann die jeweiligen gerätespezifischen Unterordner erstelle. Bei USB-Sticks verwende ich dann gern "beschreibende" Namen wie ItensoGreen8GB oder SndskCrzrEdge16GB oder so ... Edit: ... noch vergessen ... das Ganze funktioniert natürlich mit Bordmitteln!!

Da ist schon Deine Einstellung falsch. Das ist kein Problem, sondern eine Herausforderung. Fast. Get-ChildItem liefert mit den angegebenen Parametern ALLE Ordner, aus denen dann mittels Where-Obejct die Ordner herausgefiltert werden, in deren Pfad das Suchmuster auftaucht. Bis hierhin noch keine Schleife ... nur Pipeline. Jetzt kommt die Schleife mit Foreach-Object. Darin wird erstmal das Datei-Suchmuster aus dem kompletten Pfad des aktuellen Ordners und des Datei-Musters zusammengebaut. Das wird dann mit Test-Path benutzt, um zu prüfen, ob der aktuelle Ordner PDF-Dateien enthält. Wenn ja, wird das aktuell in der Pipeline befindliche Objekt ausgegeben und damit in der Variablen $PotentielleBackupOrdner gesammelt. Der nächste Teil ist ein bissl knifflig. Ich gehe mal davon aus, dass Du nicht wirklich den ganzen Pfad im Ziel wiederhergestellt haben willst, sondern nur den Teil der nach Deinem $QuellPfad kommt. Wir müssen also den kompletten Pfad um den "Anfangs-Pfad" kürzen. $PotenzielleBackupOrdner = Get-ChildItem -Path $QuellPfad -Directory -Recurse | Where-Object {$_.FullName -match $SuchMuster} | ForEach-Object { $DateiSuchMuster = Join-Path -Path $_.FullName -ChildPath '*.pdf' if (Test-Path -Path $DateiSuchMuster) { [PSCustomObject]@{ FullName = $_.FullName ShortName = $_.FullName -replace [REGEX]::Escape($QuellPfad) } } } $PotenzielleBackupOrdner Wir benutzen den -replace Operator um den Teil des Pfades zu entfernen, der dem $QuellPfad entspricht. -replace arbeitet mit regulären Ausdrücken. Deshalb müssen wir alle Zeichen, die in regex als "spezielle" Zeichen gelten "escapen". So ... kannst ja schon mal probieren, den Ziel-Pfad zusammen zu bauen ... ich komm nachher wieder ...

Ein einigermaßen aktuelles Powershell vorausgesetzt, sollte das hier reichen: Get-ChildItem \\Filer1\Data$\S_Finanzen\Informatik -Recurse -Directory | Sort-Object -Property LastWriteTime -Descending | Select-Object -First 30 -Property LastWriteTime,FullName | Out-GridView Statt Out-GridView, kannst Du natürlich auch Format-Table benutzen ... die Properties kannst Du dann da weglassen, die hast Du schon im Select-Object. Bitte bitte bitte: niemals Backticks verwenden, wenn es nicht wirklich wirklich wriklich dringend nötig ist. Das wird so gut wie immer als sehr schlechter Stil angesehen. ... und ist im Zweifel auch noch fehlerträchtig. Edit: Ich sehe gerade, dass Du in Deinem Where-Object-Filter nach Mode -notlike "d*" filterst. Damit filterst Du alle Ordner raus. Ich nahm an, dass Du eben genau die Ordner sortieren wolltest!? Seit Powershell v3.0 hat das cmdlet Get-ChildItem den Parameter -File und -Directory. Damit limitierst Du die Ergebnisse auf Dateien bzw. Ordner. Dann brauchst Du das später nicht aufwändig rausfiltern.

$_ ist die sogenannte Pipeline-Variable. Sie representiert das gerade in der Pipeline befindliche Object - wird also automatisch befüllt und sollte auf überhaupt gar keinen Fall direkt deklariert oder sonst irgendwie für eigene Zwecke missbraucht werden. Ich hab den Code gerade nochmal bei mir getestet - er läuft und liefert (wenigstens mit meinen Beispiel-Ordnern) das erwartete Ergebnis. Hast Du den Code so benutzt, wie ich ihn gepostet hatte, oder hast Du ihn "angepasst"? Der in der Fehlermeldung angezeigte Pfad dürfte an dieser Stelle so nicht auftauchen. Edit: Oooops ... Kommando zurück!! ich hatte einen Fehler eingebaut. ich hab den Code korrigiert - versuch jetzt nochmal, bitte

Aber das ist doch was, was Du vorzeigen kannst ... es ging nicht darum, dass Du etwas perfekt Funktionierendes zeigen sollst ... dann bräuchtest Du ja auch nicht hier fragen ... OK, so lange ich nebenbei Zeit habe, können wir uns langsam rantasten ... Immer unter der Voraussetzung, dass ich das alles richtig verstanden habe, kannst Du mit folgendem Snippet die Ordner ermitteln. die mit einem "B" und zwei darauffolgenden Ziffern beginnen und in denen PDF-Dateien liegen. Bitte prüfen und zurückmelden. $QuellPfad = 'C:\Quelle\Desktop\Kopier-Skript\Test\Quelle' $ZielPfad = 'C:\Ziel\Desktop\Kopier-Skript\Test\Ziel' $SuchMuster = '\\B\d{2}_' $PotenzielleBackupOrdner = Get-ChildItem -Path $QuellPfad -Directory -Recurse | Where-Object {$_.FullName -match $SuchMuster} | ForEach-Object { $DateiSuchMuster = Join-Path -Path $_.FullName -ChildPath '*.pdf' if (Test-Path -Path $DateiSuchMuster) { $_ } } $PotenzielleBackupOrdner.FullName

Auch auf die Gefahr hin pingelig zu wirken - ließt Du eigentlich die Antworten bis zum Schluss?

Neee ... ich meinte eher sowas hier: ... und ich vermisse auch Deinen Code. Du wirst doch bestimmt schon mehr haben, als eine vage Idee, wie Du es machen möchtest, oder?

Hallo TechTech und Willkommen. Get-ComputerInfo ist auf den meisten Computern wahnsinnig träge, weil es erst mal eine Menge Informationen einsammelt, die man aber meistens nicht braucht. In Deinem Fall würde ich etwas Einfacheres empfehlen: $Hersteller = Get-CimInstance -ClassName CIM_ComputerSystem | Select-Object -ExpandProperty Manufacturer IF ($Hersteller -like 'fujitsu*'){ 'cool' } else { 'uncool' } Außerdem solltest Du keine Format cmdlets verwenden, wenn Du die Informationen weiterverarbeiten möchtest. Format cmdlets sind nur gut um Ausgaben in der Konsole für uns Menschen aufzubereiten. Computer (Programme, Scripte) brauchen das nicht und es stört meistens eher.

Was hast Du denn schon bisher? Zeig doch mal bitte Dein Script? Ohne auf den gleichen Monitor zu schauen und die gleiche Systemumgebung zu sehen, ist es manchmal schwer, sich etwas so vorzustellen, dass man es mit einem Script beackern möchte. Ich kann mir Deine Ordner-Struktur und wie Du was sichern möchtest bisher nicht so richtig vorstellen. Vielleicht erzeugst Du einfach mal eine kleinere aber immernoch representative Besispiel-Ordner-Struktur und machst uns davon einen Screenshot oder eine textuelle Ausgabe und erklärst daran, was Du nun genau machen möchtest.

... ich dachte auch, dass sich bei CMD seit 1994 nix mehr geändert hat ... ... scheint wohl mit W7 gekommen zu sein.

Das war nicht gemeint ... das wartet nur, bis das gestartete Program beendet wurde. Oooopps ... das ist mir tatsächlich durchgerutscht ... dann ziehe ich meinen Einwand hiermit demütigst zurück. ... ich sollte mich eben doch raushalten, wenn's um CMD geht ...

In CMD gibt es kein eingebautes "wait". Microsoft empfiehlt ein oder mehrere Pings zu benutzen.

OK, aber wenn ich das richtig gesehen habe, ist die aktuelle Einstellung "Der Kamerazugriff für dieses Gerät ist aktiviert", richtig? Kannst Du denn im Bereich darunter einzelnen Apps den Zugriff gewähren? ... oder hab ich wieder was ganz falsch verstanden? ... passiert mir öfters ...

Hattest Du auch mal unter "Einstellungen -> Datenschutz -> Kamera" nachgesehen?