none
Variablendefinition, lesbaren Code schreiben? RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    wie macht ihr das mit den Variablendefinitionen?

    für mich wäre es oft lesbarer wenn direkt im CMD Let zb. Pfad und Dateiname angeben werden könnte, was leider in der Praxis nicht immer so funktioniert.

    zb. copy-item $pfad$dateiname ....

    und so bräuchte ich nicht auch noch eine $fullname Variable

    die cmd-lets arbeiten aber unterschiedlich. zb. new-item braucht wieder $pfad und $Dateiname (da hilft der Fullname wieder nicht) usw.

    wie macht ihr das?

    am Anfang vom Code? oder wo es benötigt wird (finde ich für mich teils lesbarer wenn es nur 1x vorkommt).

    $Whitelist = 'WhitelistNeu.txt'
$WhitelistFilter = 'WhiteList_FilterNeu.txt'

    #bestehende Whiteliste ins Archiv kopieren
    $FullDestFileNameArchive = "Z:\Archiv\Whitelist_" + (get-date -Format 'dd.MM.yyyy') + ".txt"
    $FullDestFilterFileNameArchive = "Z:\Archiv\Whitelist_Filter_" + (get-date -Format 'dd.MM.yyyy') + ".txt"
    
    $FullDestWhiteList = "Z:\WhitelistNeu.txt"
    $FullDestWhiteListFilter = "Z:\Whitelist_FilterNeu.txt"
        
    Copy-Item $FullDestWhiteList -Destination $FullDestFileNameArchive -Force
    Copy-Item $FullDestWhiteListFilter -Destination $FullDestFilterFileNameArchive -Force

    # Whiteliste kopieren
    Copy-Item .\$Whitelist -Destination $FullDestWhiteList -Force
    Copy-Item .\$WhitelistFilter -Destination $FullDestWhiteListFilter -Force

    Chris

    Donnerstag, 6. Juli 2017 13:18
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

     ... new-item braucht wieder $pfad und $Dateiname (da hilft der Fullname wieder nicht) 

    ... wieso nicht?

    ... wie macht ihr das?

    Ich packe die Variablenzuweisungen üblicherweise dahin, wo ich sie das erst mal brauche.

    Um strukturierten und gut lesbaren Code zu produzieren nutze ich gerne splatting, gerade wenn es cmdlets mit vielen Parametern sind, oder wenn die zu übergebenden Werte etwas länger werden.

    Grüße - Best regards

    PS:> (79,108,97,102|%{[char]$_})-join''


    • Bearbeitet BOfH-666 Donnerstag, 6. Juli 2017 13:45
    • Als Antwort markiert -- Chris -- Donnerstag, 6. Juli 2017 19:56
    Donnerstag, 6. Juli 2017 13:45
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    ich werde auch mal meinen Senf dazu geben. Ich habe mir bei "Produktionsskripten" folgendes angewöhnt:

    - Konstanten und "Konstanten" (also Variablen, die nicht als unveränderlich definiert sind, aber trotzdem unveränderlich sind) am Anfang des Skriptes belegen und jeweils dahinter kommentieren, was sie bedeuten. Von Zuweisungen fester Initialwerte mitten im Skript halte ich überhaupt nichts. Außnahme: Counter-Variablen, die mehrmals im Laufe des Skriptes verwendet werden, sollten natürlich möglichst kurz vor der Schleife genullt werden, die sie dann inkrementiert.

    - Werte, die von Aufruf zu Aufruf eines Skriptes variieren, nicht (oder nur mit default-Werten) in den Queltext schreiben, sondern in eine INI- oder CLIXML-Datei. Hintergrund: Ab und zu muss ich Skripte signieren, und dann ist es doof, wenn der Quelltext verändert werden muss, nur weil gerade eine andere AD-Gruppe analysiert werden soll... Außerdem läßt sich so ein Skript zwischen verschiedenen Umgebungen übertragen, ohne jedes Mal angepasst werden zu müssen. Bei Skripten, die händisch aufgerufen werden, ggfls. auch als Parameter definieren.

    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 -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    • Als Antwort markiert -- Chris -- Donnerstag, 6. Juli 2017 19:56
    Donnerstag, 6. Juli 2017 19:19
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    ganz primitiv wäre eine INI im Format

    key1=value1
key2=value2

    die man dann etwa mit

    $inifile = "$PSScriptRoot\myscript.ini"
Set-Location Variable:
foreach ($line in (Get-Content $inifile)) {
    $key = ($line -split "=")[0]
    $value = ($line -split "=")[1]
    New-Item -Name $key -Value $value
}

    zu Variablen umwandeln kann. Viel spannender jedoch ist eine Datei wie

    js Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04">
  <Obj RefId="0">
    <TN RefId="0">
      <T>Deserialized.System.Management.Automation.PSCustomObject</T>
      <T>Deserialized.System.Object</T>
    </TN>
    <MS>
	  <S N="DBServer">DBServer123</S>
	  <S N="DBAuth">sql</S>
	  <S N="DBPath">C:\SQL</S>
	  <S N="DBUser">sqldba</S>
	  <S N="DBPasswd">!2345Qwert</S>
    </MS>
  </Obj>
</Objs>

    die man dann mit

    $settings = Import-CLIXML P:\fad\zur\Datei.xml
    einliest und ein Objekt erhält, das die Eigenschaften DBServer, DBAuth usw. hat, mit entsprechenden Werten halt. Es sind hier auch explizite Typendefinitionen möglich wie Boolean, Integer usw., und sogar Listen, die dann als Array in PowerShell abgebildet werden.

    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 -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    • Als Antwort markiert -- Chris -- Freitag, 7. Juli 2017 06:07
    Donnerstag, 6. Juli 2017 21:39
    |
  • Question
    Anmelden
    0
    Anmelden
    Ich lege auch oft Konfigurationsparameter (wie Nutzernamen, Basispfade etc.) in externen Dateien ab. Entweder nutze ich dafür auch strukturierte Textdokumente. Oder ich lege es gleich in eine ps1-Datei, die ich mit Dot-Sourcing (also  
    . "Skriptpfad"
    lade. Der Unterschied zwischen . und & beim Skriptaufruf ist, dass beim . die Variablen in den ausführenden Scope geladen werden. Somit sind sie dann im Haupt-Skript verfügbar. Wenn man das Skript von Hand aufruft, kann man auch ganz gut mit Out-Gridview (und InputMode Single) zwischen verschiedenen Konfigurationen wählen: 
    $KonfigDatei = Get-Childitem ".\Konfig" | out-Gridview -Outputmode Single

. $Konfigdatei.Fullname

    • Als Antwort markiert -- Chris -- Freitag, 7. Juli 2017 06:07
    Freitag, 7. Juli 2017 06:01
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

     ... new-item braucht wieder $pfad und $Dateiname (da hilft der Fullname wieder nicht) 

    ... wieso nicht?

    ... wie macht ihr das?

    Ich packe die Variablenzuweisungen üblicherweise dahin, wo ich sie das erst mal brauche.

    Um strukturierten und gut lesbaren Code zu produzieren nutze ich gerne splatting, gerade wenn es cmdlets mit vielen Parametern sind, oder wenn die zu übergebenden Werte etwas länger werden.

    Grüße - Best regards

    PS:> (79,108,97,102|%{[char]$_})-join''


    • Bearbeitet BOfH-666 Donnerstag, 6. Juli 2017 13:45
    • Als Antwort markiert -- Chris -- Donnerstag, 6. Juli 2017 19:56
    Donnerstag, 6. Juli 2017 13:45
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    ich werde auch mal meinen Senf dazu geben. Ich habe mir bei "Produktionsskripten" folgendes angewöhnt:

    - Konstanten und "Konstanten" (also Variablen, die nicht als unveränderlich definiert sind, aber trotzdem unveränderlich sind) am Anfang des Skriptes belegen und jeweils dahinter kommentieren, was sie bedeuten. Von Zuweisungen fester Initialwerte mitten im Skript halte ich überhaupt nichts. Außnahme: Counter-Variablen, die mehrmals im Laufe des Skriptes verwendet werden, sollten natürlich möglichst kurz vor der Schleife genullt werden, die sie dann inkrementiert.

    - Werte, die von Aufruf zu Aufruf eines Skriptes variieren, nicht (oder nur mit default-Werten) in den Queltext schreiben, sondern in eine INI- oder CLIXML-Datei. Hintergrund: Ab und zu muss ich Skripte signieren, und dann ist es doof, wenn der Quelltext verändert werden muss, nur weil gerade eine andere AD-Gruppe analysiert werden soll... Außerdem läßt sich so ein Skript zwischen verschiedenen Umgebungen übertragen, ohne jedes Mal angepasst werden zu müssen. Bei Skripten, die händisch aufgerufen werden, ggfls. auch als Parameter definieren.

    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 -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    • Als Antwort markiert -- Chris -- Donnerstag, 6. Juli 2017 19:56
    Donnerstag, 6. Juli 2017 19:19
    |
  • Question
    Anmelden
    0
    Anmelden

    Evgenij

    würde eine *.ini in meinem Beispiel auch Sinn machen.

    wie machst du das mit der INI (get-content?). Kannst du noch ein kleines Beispiel hier ablegen?

    Chris

    Donnerstag, 6. Juli 2017 20:00
    |
  • Question
    Anmelden
    0
    Anmelden

    Moin,

    ganz primitiv wäre eine INI im Format

    key1=value1
key2=value2

    die man dann etwa mit

    $inifile = "$PSScriptRoot\myscript.ini"
Set-Location Variable:
foreach ($line in (Get-Content $inifile)) {
    $key = ($line -split "=")[0]
    $value = ($line -split "=")[1]
    New-Item -Name $key -Value $value
}

    zu Variablen umwandeln kann. Viel spannender jedoch ist eine Datei wie

    js Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04">
  <Obj RefId="0">
    <TN RefId="0">
      <T>Deserialized.System.Management.Automation.PSCustomObject</T>
      <T>Deserialized.System.Object</T>
    </TN>
    <MS>
	  <S N="DBServer">DBServer123</S>
	  <S N="DBAuth">sql</S>
	  <S N="DBPath">C:\SQL</S>
	  <S N="DBUser">sqldba</S>
	  <S N="DBPasswd">!2345Qwert</S>
    </MS>
  </Obj>
</Objs>

    die man dann mit

    $settings = Import-CLIXML P:\fad\zur\Datei.xml
    einliest und ein Objekt erhält, das die Eigenschaften DBServer, DBAuth usw. hat, mit entsprechenden Werten halt. Es sind hier auch explizite Typendefinitionen möglich wie Boolean, Integer usw., und sogar Listen, die dann als Array in PowerShell abgebildet werden.

    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 -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    • Als Antwort markiert -- Chris -- Freitag, 7. Juli 2017 06:07
    Donnerstag, 6. Juli 2017 21:39
    |
  • Question
    Anmelden
    0
    Anmelden
    Ich lege auch oft Konfigurationsparameter (wie Nutzernamen, Basispfade etc.) in externen Dateien ab. Entweder nutze ich dafür auch strukturierte Textdokumente. Oder ich lege es gleich in eine ps1-Datei, die ich mit Dot-Sourcing (also  
    . "Skriptpfad"
    lade. Der Unterschied zwischen . und & beim Skriptaufruf ist, dass beim . die Variablen in den ausführenden Scope geladen werden. Somit sind sie dann im Haupt-Skript verfügbar. Wenn man das Skript von Hand aufruft, kann man auch ganz gut mit Out-Gridview (und InputMode Single) zwischen verschiedenen Konfigurationen wählen: 
    $KonfigDatei = Get-Childitem ".\Konfig" | out-Gridview -Outputmode Single

. $Konfigdatei.Fullname

    • Als Antwort markiert -- Chris -- Freitag, 7. Juli 2017 06:07
    Freitag, 7. Juli 2017 06:01
    |