News Microsoft: Ubuntus Unix-Shell Bash läuft nativ in Windows 10

??? schrieb:
Der Vergleich ist wirklich unglaublich.
...
Bash:
Code:
df -h | awk '{print $5}' | grep -v Use | sort -n | tail -1 | cut -d% -f1
Der Vergleich ist vor allem deshalb unglaublich, weil weder df noch awk noch grep noch sort noch tail noch cut Teile von bash sind sondern alles vollkommen unabhängige Programme, die im Beispiel lediglich von bash aufgerufen und kombiniert werden. Das ist der klassiche Job einer Shell, die genau deshalb Shell heisst.

MS' Powershell ist in dem Sinne keine reine Shell, sondern will neben dem Shell-Dasein haufenweise Zeug selbst stemmen.
 
Erzwungene Updates und Systemreports nerven ?
Einfach die entsprechenden IPs im Router sperren, Problem gelöst.
 
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? ;) 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:
Code:
dir *.log | Get-FileHash
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...
 
Zuletzt bearbeitet:
Yuuri schrieb:
Als Tipp für dich:
Code:
dir *.log | Get-FileHash
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>]
Das berechnet mir aber die SHA256-Prüfsumme. Wenn ich SHA1 will, muss ich mir entweder die Syntax des Befehls merken, oder mich durch die Hilfeseiten lesen.
Wenn ich SHA3 will, habe ich unter PowerShell momentan noch Pech, unter Linux nutze ich einfach sha3sum.
Yuuri schrieb:
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...
Mag sein, dass die PowerShell viel mächtiger ist. Das bringt mir aber nichts, wenn die ständig anfallenden einfachsten Aufgaben dadurch unnötig kompliziert werden. Wenn ich Dinge machen will, die Objektorientierung erfordern, dann nehme ich Python, das wiederum PowerShell alt aussehen lässt.

PowerShell ist da nix halbes und nix ganzes.
 
chithanh schrieb:
Das berechnet mir aber die SHA256-Prüfsumme. Wenn ich SHA1 will, muss ich mir entweder die Syntax des Befehls merken, oder mich durch die Hilfeseiten lesen.
Code:
dir *.log | Get-FileHash -Algorithm SHA1

Algorithm       Hash                                                                   Path
---------       ----                                                                   ----
SHA1            B2CFA80B0D177BDD6513F6DF3257087C7F85E9B2                               R:\test.log
Ist jetzt nicht so schwer den Algorithm Parameter anzuhängen.
 
Yuuri schrieb:
Der Text mit der Intention gilt auch für dich. Verkomplizierst du alles immer so?
Ist beides übrigens leckeres Obst.
Code:
Get-Volume | sort SizeRemaining | select -last 1 | % { [int]($_.SizeRemaining / $_.Size * 100) }
Junge Junge, du bist echt ein ganz Schlauer. Vergleiche die Ausgabe mit deinem bash-Konstrukt und auch du wirst bemerken, dass das etwas anderes ist.

Du vergleichst weiterhin Äpfel mit Birnen. :-)

Edit:
Ich will die PowerShell nicht schlecht reden, aber das ganze Ding steckt noch dermaßen in den Kinderschuhen, so dass sich da zu oft Dinge ändern die einen zwingen, Skripte umzuschreiben. Das geht sogar soweit, dass man auf Exchange-Servern besser nicht die aktuelle PS-Version installiert, weil dadurch die PS-Skripte von MS nicht mehr laufen. Ganz großes Kino.
 
Zuletzt bearbeitet von einem Moderator:
Yuuri schrieb:
Ist jetzt nicht so schwer den Algorithm Parameter anzuhängen.
Schwer ist es nicht, aber unnötig kompliziert. Dieses Thema zieht sich durch die gesamte PowerShell und ist, was ich kritisiere.
Bash nehme ich für einfachste Dinge, und da erwarte ich einfache, leicht zu merkende Syntax ohne Überraschungen. Für alle komplizierten Aufgaben nehme ich Python oder andere Sprachen.

PowerShell hat weder die Einfachheit von bash noch die Mächtigkeit von Python. Es vereinigt nur das Schlechte aus beiden Welten.
 
Was der Powershell also fehlt sind Aliase, die Parameter setzen können. Stimme ich dir absolut zu. Dank autocomplete wird das Problem aber deutlich gemindert - PS lässt dich ja mit tab durch alle Parameter und gültige Werte durchiterieren. Insofern musst du dir noch nichtmal die syntax merken (ist aber natürlich immer noch deutlich mehr Aufwand als wenn es schon ein vorgefertigtes Get-Sha1FileHash Cmdlet geben würde).

Was die andere Diskussion angeht: Sind für euch zwei Befehle nur dann äquivalent, wenn sie exakt den gleichen output produzieren? Ich würde sagen das wichtige ist, dass sie die gleiche Information liefern. Einträge direkt nach mem Property namen zu sortieren finde ich übrigens deutlich verständlicher als nach Spaltennummer (vor allem wenn man nicht auswendig weiß, in welcher Spalte was steht).

So trivial es klingt: Für mich als Gelegenheitsnutzer (sowohl der bash als auch der PS) war bisher einer der größten Nachteile der Powershell (vor Win10), dass man sie nicht einfach mit der Maus breiter ziehen oder vernünftig snappen konnte.
 
Der exakt gleiche Output muss es nicht sein. Das wäre bei derart unterschiedlichen Konzepten unsinnig. Der Informationsgehalt sollte jedoch halbwegs der Selbe sein und da war Yuuris erstes Beispiel Käse. Sein Bashunfall vs. seiner eleganten PS Lösung gegenüber zu stellen ging schon eher in die Richtung trollen.

Was das Sortieren nach Name vs. sort auf Spalte angeht. Einmal muss man wissen wie die Eigenschaft heißt und einmal die wievielte Spalte das Gewünschte erhält. Der Unterschied ist für mich klein genug, als das er für mich nicht der Rede wert ist.
 
@Piktogramm: Es geht mir mehr um die Lesbarkeit und ich kann mir namen leichter merken (zumindest soweit, dass Autocomplete den Rest machen kann). Aber ja, nen großen Unterschied macht es nicht und generell nutze ich beides zu wenig um wirklich sagen zu können, was besser ist und ob eine shell wirklich Defizite gegenüber der anderen aufweist oder ob's letztendlich nur ne Frage der Gewohnheit ist.
 
Was die Syntax angeht ist es natürlich schiere Gewohnheit. Genauso was die Lesbarkeit angeht, solang da beim Schreiben kein Unfug getrieben wird lassen sich Scripte und Eingaben gleichermaßen lesen. Da nehmen sich die verschiedenen shells oft wenig.
 
Könnte man so eigtl rsync nutzen?
 
Zurück
Oben