Piktogramm schrieb:
Eben mal die Netzwerkconfig, mal regedit und das Nächstemal wieder etwas ganz Anderes.
netsh(.exe), die Registry kannst du mit der PowerShell manipulieren und das nächste Mal nutzt du auch das entsprechende Tool.
Piktogramm schrieb:
Deine Kritik, dass die Bash hauptsächlich Strings parst stimmt an der Stelle zwar, aber das ganze passiert Konsistent über das gesamte System hinweg.
Also konsistent Scheiße?
![Zwinkern ;) ;)](/forum/styles/smilies/wink.gif)
Genau darum gings mir doch. Es ist konsistent beschissen. Ständig musst du Strings auseinander friemeln und wieder zusammen setzen. Das ist extrem umständlich und nicht gerade fehlerresistent.
Piktogramm schrieb:
Dieser rote Faden ist für mich bei der Powershell nicht durchgängig[/U] erkennbar.
Weil die PowerShell eine Shell ist und kein Text-Editor (das ist die bash übrigens auch nicht, sondern nano/vi/emacs/..., früher edit unter Windows) oder ein Tool, womit ich Einstellungen von Excel manipulieren kann/können soll. Hier trifft doch die total irre Ideologie von "Everything is a file" mit großen, performanten Programmen zusammen. Config Files zu parsen ist kein Zuckerschlecken. Falsche Syntax in der Config? Tja, dann startet der Apache halt mal gar nicht... Haken ändern, läuft trotzdem. Und erzähl mir bitte nicht, dass du an nem Desktop System, selbst wenn du auf der Konsole arbeitest, lieber nano/vi nutzt als kurz Sublime Text o.ä. aufzurufen. Auf nem Server ist das was Anderes, aber auf dem Desktop mach ich mir nicht die Arbeit und stell bei nano erst mal den Linewrap via
Esc + $ (WTF?!) ein.
Piktogramm schrieb:
Nice try, die beiden Befehlsketten bewirken aber auch grundlegend verschiedene Sachen, die Ausgabe ist bei weitem nicht identisch.
Danke, dass du meine Intention nicht verstanden hast. Nochmal: Die PowerShell gibt
Objekte zurück. Will ich nun eine HDD/Partition haben, mach ich Folgendes:
Code:
Get-Volume C
DriveLetter FileSystemLabel FileSystem DriveType HealthStatus OperationalStatus SizeRemaining Size
----------- --------------- ---------- --------- ------------ ----------------- ------------- ----
C Windows NTFS Fixed Healthy OK 62.9 GB 237.52 GB
Will ich nun wissen, wie viel Speicher verfügbar ist:
Code:
$C = Get-Volume C
$C.Size
255033602048
Nun wie viel frei ist:
Code:
$C.SizeRemaining
67539312640
Alles ohne die Tools neu aufzurufen, ohne irgend ne Ausgabe zwischenzuspeichern, ohne neu zu filtern, zu ersetzen, anzuhängen, an ein weiteres Tools ne Abfrage geben... Die Größe des freien Speichers in Prozent:
Code:
$C.SizeRemaining / $C.Size * 100
26,4825152833345
Hm, Kommastellen zu viel? Cast ichs eben auf ein int...
Code:
[int]($C.SizeRemaining / $C.Size * 100)
26
Will ich runden?
Code:
[Math]::Round( $C.SizeRemaining / $C.Size * 100,2 )
26,48
Alles ohne Probleme, direkt mit .NET im Hintergrund. Ohne Dritttools, die nur spezielle Aufgaben erfüllen wollen, welche ich dann ggf. verketten muss usw. Einfach nur ein dummes Objekt, was mir Daten bereitstellt.
OOP ist nun nicht gerade so beliebt, weil man gern mit Strings hantiert...
??? schrieb:
Der Vergleich ist wirklich unglaublich.
Der Text mit der Intention gilt auch für dich. Verkomplizierst du alles immer so?
??? schrieb:
Code:
Get-PSDrive -PSProvider FileSystem | Where-Object Free | Select @{L='Use';E={"{0:N0}" -f ($_.Used*100/($_.Used+$_.Free))}} | Sort Use | Select -Last 1 | Format-Table -HideTableHeaders
Wenn man Äpfel mit Birnen vergleicht, kommt natürlich Murks bei raus...
Ist beides übrigens leckeres Obst.
Code:
Get-Volume | sort SizeRemaining | select -last 1 | % { [int]($_.SizeRemaining / $_.Size * 100) }
chithanh schrieb:
Mag sein, dass es Gewohnheitssache ist, aber mit der PowerShell-Syntax konnte ich mich bislang nicht so recht anfreunden.
Als Tipp für dich:
Ja mit der PowerShell kann man wunderbar pipen.
Get-Help verräts dir übrigens:
Code:
Get-Help Get-FileHash
SYNTAX
Get-FileHash [-Path] <String[]> [-Algorithm <String>] [<CommonParameters>]
Get-FileHash [-Algorithm <String>] -LiteralPath <String[]> [<CommonParameters>]
PARAMETER
-LiteralPath <String[]>
Specifies the path to a file. Unlike the Path parameter, the value of the LiteralPath parameter is used exactly as it is typed. No characters are interpreted as
wildcard characters. If the path includes escape characters, enclose the path in single quotation marks. Single quotation marks instruct Windows PowerShell not
to interpret characters as escape sequences.
Erforderlich? true
Position? named
Standardwert
Pipelineeingaben akzeptieren?True (ByPropertyName) <--
Platzhalterzeichen akzeptieren?false
Da der Parameter Pipelineingabe an der Property annimmt, kannst du auch eigene Objekte mit LiteralPath Property an das Cmdlet weitergeben.
Code:
PS R:\> $o = New-Object PsObject
PS R:\> $o | Add-Member NoteProperty Name "test variable"
PS R:\> $o | Add-Member NoteProperty AndereProperty "zweite variable"
PS R:\> $o | Add-Member NoteProperty LiteralPath R:\test.log
PS R:\> $o
Name AndereProperty LiteralPath
---- -------------- -----------
test variable zweite variable R:\test.log
PS R:\> $o | Get-Member
TypeName: System.Management.Automation.PSCustomObject
Name MemberType Definition
---- ---------- ----------
Equals Method bool Equals(System.Object obj)
GetHashCode Method int GetHashCode()
GetType Method type GetType()
ToString Method string ToString()
AndereProperty NoteProperty string AndereProperty=zweite variable
LiteralPath NoteProperty string LiteralPath=R:\test.log
Name NoteProperty string Name=test variable
PS R:\> $o | Get-FileHash
Algorithm Hash Path
--------- ---- ----
SHA256 68877741BBF07DF13E1F304F37594145974D8DF92082727BAB6FC1DBE3F5F4E3 R:\test.log
mensch183 schrieb:
MS' Powershell ist in dem Sinne keine reine Shell, sondern will neben dem Shell-Dasein haufenweise Zeug selbst stemmen.
Hm jein. Cmdlets sind natürlich quasi auch "externe Programme", je nach Auffassungsgabe. Aber in Linux ist ja auch vieles einfach nur ein Skript, von daher hierbei gleichwertig "extern".
Die Konzepte der Cmdlets ist aber imho einzigartig, einfach und extrem komfortabel.
Code:
function Get-Command
{
<#
Dokumentation der Funktion
- Name
- Beschreibung
- Parameter
- Beispiele
- ... (siehe Get-Help)
#>
Param(
[Parameter(
Position = 1,
Mandatory = $true,
ValueFromPipeline = $true,
ValueFromPipelineByPropertyName = $true
)]
[string]$Name,
[ValidateSet("Affe","Zebra","Schlange")]
[string]$Tier,
[ValidateScript({ Test-Path -LiteralPath $_ })]
[string]$Path,
[int]$Number,
[switch]$YesNo
)
dynamicparam
{
# Bildung von dynamischen Parametern beim Autocomplete
}
begin
{
# Ausführung bevor irgendwas abgearbeitet wird
# Prüfung von Vorbedingungen
}
process
{
# relevant beim Pipen von Variablen
# für einzelne Objekte natürlich nur eine Ausführung
# der Block wird für jedes Objekt welches reingegeben wird, ausgeführt
# > dir *.log | Get-FileHash
# für jeden Eintrag in dir *.log wird Get-FileHash::process ausgeführt
}
end
{
# Ausführung am Ende offentsichtlich
}
}
Ich muss nicht manuell von stdin testen/lesen, nicht Parameter parsen, Get-Help zeigt mir automatisch eine Hilfe-Seite dazu an, mittels ps1xml-Dateien kann die Ausgabe von Objekten/Klassen komplett gesteuert werden, i18n/l10n problemlos möglich, Nutzung von (.NET) DLLs möglich, quasi aber auch der WinAPI, Definition unterschiedlicher Parameter Sets (siehe oben Get-FileHash mit zwei Sets, automatisch über Parameterattribute aufgelöst), Parameterattribute (Pflichtparameter, Validierung einzelner Parameter, Aliase, not null/empty Checks, ...), Type Hinting falls gewünscht, ... Dank .NET kann ich sogar problemlos Bilder manipulieren. Ohne ImageMagick wär man da mit der bash schnell aufgeschmissen.
In Datenbanken kann man übrigens auch direkt in der PowerShell navigieren und diese Daten manipulieren, insofern man da einen entsprechenden
Provider einsetzt.
Wenn man sich da mal ein bisschen reinfitzelt, sieht die bash ziemlich alt aus. Aber man kennt halt die bash und will anscheinend nichts mehr dazulernen... traurig... leider...