Bei Powershell bleiben oder was anderes lernen?

[pizza4ever]

Hallo zusammen,

ich bin ein bekennender Powershell Liebhaber. Ich finde Powershell großartig und habe damit tolle Sachen gebaut. Auch bei größeren Projekte hatte ich nie das Gefühl, dass der Code irgendwann unwartbar wurde weil man Funktionen, Module und Klassen hatte und wenn es Performanceprobleme gab, konnte man oft auf c# ausweichen oder - da meine Probleme es zugelassen haben - einfach mit einer längeren Laufzeit leben. Und die Verfügbarkeit vom .net Framework ist einfach einfach super, weil man damit für seeehr viele Themen was fertiges hat. Auf der Arbeit war es immer so, dass man ein Projekt für ein Problem anfangen konnte (schnelles Prototyping) und dann das ganze bei Bedarf ausbauen konnte.

Es gibt aber auch Dinge die mich stören an Powershell

1.) Gefühlt wenig Weiterentwicklung
2.) Es gibt immer mal wieder Probleme, wo man beim Blick über über den Tellerrand sieht, dass z.B. Python am Ende schlicth bessere Module vorhanden sind. z.B. die Excel Integration ist OK bei Powershell, aber es gibt genau ein Modul und das ist teilweise unsäglich langsam. Python ist sogar um etliche Male schneller wenn man die Daten erst in ein JSON rausschreibt und dann wieder einliest. Es gibt zwar externe Libarys z.B. IronXl aber die sind dann ggf. kostenpflichtig. Weiteres Beispiel ist das SQLITE Modul, welches seit 5 Jahren kein Update erfahren hat. Man kann zwar über System Data SQLITE auch direkt das ganze anbinden, aber dann erzeugt man schon viel (teilweise unschönen) code in Powershell + Dokus findet man dann auch fast nur noch wenn man nach c# googlet (und den code dann portiert).
3.) Kleine Community v.a. bei komplexeren Themen. Ich höre immer wieder von Leuten die damit kleinere Aufgaben automatisieren, aber wenig davon dass damit wirklich größere Themen betrieben werden.

Sachen die mich reizen würden wäre Python oder Golang, was ja inzwischen auch riesig geworden sein soll. Ich habe vor Jahren mal mit Python rumexperimentiert, bin aber nie wirklich warm damit geworden.

Was sind eure Meinungen?

 

[JennyCB]

Sei nicht so Windows fixiert.

 

[madmax2010]

was baust du denn darin?
geht es dir um Entwicklung, Automatisierung oder Bedienung deines Computers?

Im Vergleich mit anderen shells, finde ich Powershell unnötig kompliziert, inkonsistent und altbacken.

Mein Stack zur täglichen Arbeit ist gerade ZSH mit ein paar Plugins in Ghostty. Sehr angenehm und es nimmt einem sehr viel tippen ab.

Zur Entwicklung / Automatisierung von Aufgaben:
Was auch immer gerade die akut sinnvolle Sprache ist.. Aktuell viel Python, C++, Typescript und Ocaml.

Was sind eure Meinungen?

the right tool for the job

 

[nutrix]

was baust du denn darin?
geht es dir um Entwicklung, Automatisierung oder Bedienung deines Computers?

Das ist die richtige Frage, jedes Ding für einen Gewissen Zweck. Du mußt erst mal wissen oder definieren, was Du überhaupt genau machen willst.

Im Vergleich mit anderen shells, finde ich Powershell unnötig kompliziert, inkonsistent und altbacken.

Geht mir auch so.

Powershell ist an sich keine richtige Programmiersprache, sondern eine Verwaltungs bzw. Batchsprache, um das OS verwalten zu können.

 

[madmax2010]

killall chrome
vs
Get-Process chrome | ForEach-Object { $_.Kill() }


grep -r "hello" .
vs
Select-String -Path .\* -Pattern "hello" -Recurse


sed -i 's/foo/bar/g' *.txt
vs
Get-ChildItem *.txt | ForEach-Object {
(Get-Content $[I]) -replace 'foo', 'bar' | Set-Content $[/I]
}


du -sh .
vs
"{0:N2} MB" -f ((Get-ChildItem -Recurse | Measure-Object -Property Length -Sum).Sum / 1MB)


wc -l file.txt
vs
(Get-Content file.txt).Count


Ich habe respekt vor jedem, der mit Powershell arbeitet.

 

[areiland]

Powershell ist an sich keine richtige Programmiersprache, sondern eine Verwaltungs bzw. Batchsprache, um das OS verwalten zu können.

Die Powershell ist ja auch keine Programmiersprache, sondern ein Terminal, in dem Du mit jeder von Windows nativ unterstützten Sprache direkt zeilenweise oder als Script Code schreiben kannst und kannst direkt die entsprechenden Dialoge auch verwenden. Die steht einer Bash in nix nach!

Powershell gabs ursprünglich sogar mal als eine eigene OS Implementierung namens Singuralitiy

 

[KitKat::new()]

Ich habe respekt vor jedem, der mit Powershell arbeitet.

Ist das nicht ein bisschen Äpfel und Birnen?
Du vergleichst ja Programme mit einer Scriptsprache statt zwei Scriptsprachen

Sei nicht so Windows fixiert.

PS ist auch für Linux verfügbar fwiw.

Ergänzung (22. März 2025)

Die Powershell ist ja auch keine Programmiersprache,

Doch ist es, denn Powershell bezeichnet mehrere Dinge, sh. https://learn.microsoft.com/en-us/powershell/scripting/overview?view=powershell-7.5

 

[madmax2010]

Du vergleichst ja Programme mit einer Scriptsprache statt zwei Scriptsprachen

Einerseits hast du irgendwie recht, anderseits ist es 2025 und beides sind keine tollen Skriptsprachen. Man (in meinem Umfeld), nutzt sie als Werkzeug um seinen PC zu bedienen.

Powershell gabs ursprünglich sogar mal als eine eigene OS Implementierung namens Singuralitiy

Singularity war ein experimentelles, primär in C# (und 1-2 dialekten davon) geschriebenes Microkernel OS. Powershell war darunter nicht verfügbar.
Tbh habe ich das als teenager mal installiert und damit gespielt, als ich mich noch nicht an Linux getraut habe..

fwiw

TIL
wer macht denn so etwas..

Ergänzung (22. März 2025)

Die Powershell ist ja auch keine Programmiersprache, sondern ein Terminal, i

Ein Terminal-Emulator ist das Programm, das dir ein Textfenster öffnet, in dem du mit einer Shell arbeiten kannst (bspw Windows Terminal, iTerm, ghostty).
Eine Shell ist ein Programm, das deine Texteingaben liest, interpretiert und die passenden Programme aufruft (e.g. powershell, bash, zsh).
Wobei Bash und PS halt auch wieder Sprachen sind.

Aka: manche sind nur eins davon, andere sind viele

 

[BeBur]

Ich habe respekt vor jedem, der mit Powershell arbeitet.

Schlimmer als Bash geht gar nicht. Solange es schön simpel bleibt wie in deinen Beispielen ist es okay, also nur ein einzelnes Programm aufrufen mit wenigen Parametern. Kann schon sein, dass die vorgefertigten Programme für Windows/Powershell weniger Anwendungsfälle gut abdecken.
Aber richtige Skripte mit Bash schreiben ist einfach Grauenhaft. Habe bisher nichts ernsthaftes mit Powershell gemacht, aber das kam mir immer deutlich sinnvoller vor.

 

[crashbandicot]

Ich habe respekt vor jedem, der mit Powershell arbeitet.

Objekte > plain Text

Alleine, dass man mit Select-Object direkt auf die benötigten Objekte und damit Inhalte zugreifen kann, während man bei bash immer die Spalten abzählen und dann hoffen muss, dass sich nie was an der Reihenfolge ändert ist mehr als Gold wert.

 

[andy_m4]

Schlimmer als Bash geht gar nicht.

Ich werfe mal INTERCAL in den Ring. :-)

Letztlich muss man die Bash als das sehen, was sie ist. Die ist nicht dafür gedacht große Skripte zu schreiben. Die ist nett dafür, wenn man mal eben schnell mit den gewohnten Kommandozeilentools was automatisieren will. Aber spätestens(!) wenn Dein Skript an der 100-Zeilen-Grenze kratzt, ist Bash vermutlich nicht mehr das geeignete Werkzeug.

By the way ist die Bash in zweilei Hinsicht doof.
Als Skriptsprache, weils besseres gibt.
Aber auch der interaktive Part, weils auch da besseres gibt.

Den einzigen Vorteil den die Bash wirklich hat, ist ihre (historisch bedingte) Verbreitung. Zumindest im Linux-Universum kannst Du immer davon ausgehen, das Du eine Bash verfügbar hast.

mit Powershell

Powershell ist sicher von der Programmierung her angenehmer.
Allerdings in der interaktiven Benutzung ist Luft nach oben.
Eine Shell, die diesbezüglich besser ist, ist die Nushell, finde ich.

Es kommt natürlich auch, und das klang ja hier im Thread schon an, so ein bisschen darauf an, was man macht und in welchem Umfeld man sich bewegt. Um unter Windows ein bisschen Automatisierung zu machen ist die PowerShell natürlich am besten.
Braucht man den eigentlich Shell-Aspekt gar nicht, dann ist man mit einer Skriptsprache wie Python und Co u.U. besser dran.

Ich habe respekt vor jedem, der mit Powershell arbeitet.

Wobei man sagen muss, die UNIX- und Linux-Befehle sind natürlich sehr darauf optimiert, kurz zu sein. Das ist gut, wenn man das interaktiv benutzt. Was man beim Skript ja eher haben will ist, das es auch gut lesbar ist. Damit will ich jetzt nicht sagen, das die PowerShell unbedingt und in jedem Fall lesbarer ist, aber gibt schon echt fiese Bash-Skripts die auf der nach oben offenen Perl-Skala hohe Werte erreichen. :-)

 

[nutrix]

Schlimmer als Bash geht gar nicht.
...
Aber richtige Skripte mit Bash schreiben ist einfach Grauenhaft. Habe bisher nichts ernsthaftes mit Powershell gemacht, aber das kam mir immer deutlich sinnvoller vor.

Alles eine Frage der Gewöhnung, genau wie die Bedienung von vi(m). Borne Shell sh und die Korn Shell ksh sind in der Vergangenheit extrem zuverlässig gewesen, um zwischen unterschiedlichen Unix-Maschinen Verwaltungen und mehr zu steuern, und mit bash konnte man das so ab ca. 2005-7 dann mehr und mehr auch nutzen, als es unter Solaris und AIX verfügbar war. Man kann Bash einfach nach Linux, AIX, sogar WSL und Cygwin verschieben, es funktioniert immer zuverlässig.

Ich mache seit bald 40 Jahren Shell und heute Bash, und ich habe beileibe keine solchen Aversionen dagegen wie Du. Ganz im Gegenteil, ich hab damit bis heute sogar noch zu tun, und lerne in den Reviews, die ich betreue, sogar immer wieder noch was dazu, weil immer wieder was von den vielen Entwicklern auftaucht, was ich so bisher noch nicht kannte. Und mit Ansible und Pyhton kannst Du doch noch nicht alles so ersetzen, daß man auf Bash in großen Umgebungen verzichten könnte. Mal so tausende Server, VMs, Dockers, Microservices DBs und Co. ohne Bash zu betreuen stelle ich mir sehr schwierig vor.

Ergänzung (22. März 2025)

Wobei man sagen muss, die UNIX- und Linux-Befehle sind natürlich sehr darauf optimiert, kurz zu sein. Das ist gut, wenn man das interaktiv benutzt. Was man beim Skript ja eher haben will ist, das es auch gut lesbar ist. Damit will ich jetzt nicht sagen, das die PowerShell unbedingt und in jedem Fall lesbarer ist, aber gibt schon echt fiese Bash-Skripts die auf der nach oben offenen Perl-Skala hohe Werte erreichen. :-)

Wem sagst Du das. Ich versuche hier gerade ein paar Altlasten loszuwerden, die alte Entwickler, die in Rente sind, hinterlassen hatte. Aber dann bist Du auch wieder im Dilemma, tauscht Du Bash 1:1 gegen Python oder Ansible mühsam aus oder nicht. Wenn da am Ende auch wieder Grütze und unwartbares Zeugs rauskommt, dann bleibe ich doch lieber bei Bash, was so bisher wenigstens anstandslos funktionierte.

 

[andy_m4]

Man kann Bash einfach nach Linux, AIX, sogar WSL und Cygwin verschieben, es funktioniert immer zuverlässig.

Also dieses zero-dependency-Ding ist auch etwas, was ich an klassischen Shellskripten schätze.
Wie ich schon sagte: Bash ist eigentlich i.d.R. immer verfügbar.
Bei Skripten stecken die Abhängigkeiten halt im Skript selber. Bash-Skripte bauen ja ganz viel auf anderen Programmen auf und die müssen halt auch da sein.
Bei so einem Python-Skript hast Du eben eine bestimmte Standard-Lib und weißt: Wenn da ein Python-Interpreter ist, dann hast Du auch das und das da. Und wenn Du mal doch mehr Abhängigkeiten hast, dann hast Du mit dem Python-Paketmanager eine Möglichkeit diese Abhängigkeiten zu hinterlegen.
Geht in Bash natürlich auch irgendwie, aber ist komplizierter.

So hat alles seine Vor- und Nachteile.
Aber ja: Insbesondere bei kurzen Sachen bevorzuge ich auch ein Shell-Skript.

Wenn da am Ende auch wieder Grütze und unwartbares Zeugs rauskommt

Ja. Das ist halt immer die Frage. Wenns nur darum geht, es durch etwas modernes zu ersetzen und sonst aber keinen Nutzen davon zu haben und im Erfolgsfall Du allenfalls gleich gut wie die alte Lösung bist, macht es natürlich wenig Sinn zu wechseln.

 

[Pummeluff]

Schlimmer als Bash geht gar nicht. …
Aber richtige Skripte mit Bash schreiben ist einfach Grauenhaft. Habe bisher nichts ernsthaftes mit Powershell gemacht, aber das kam mir immer deutlich sinnvoller vor.

Ich liebe Bash. Hab da auch schon einige komplexere Scripte geschrieben. Wenn's dann mal komplexer wird, nehm ich auch sehr gern Python. Gerade bei Python macht man die Erfahrung, dass sehr schnell sehr große Erfolge erzielt. Dann gibt's noch Perl. Da war die Lernkurve steil. Nur leider hab schon am nächsten Tag meine Perl-Skripte nicht mehr verstanden.

Powershell find ich hingegen einfach nur ätzend. Man piped ein Objekt, wo man eigentlich keine Ahnung hat, was da rauskommt. Und das übergibt man an ein anderes Objekt, wo man eigentlich keine Ahnung hat, ob das jetzt damit umgehen kann. Und dazu kommt die grässliche Syntax: CamelCase ist out. Und Getters- und Setters waren schon vor 15 Jahren schlechter Stil.

Bei meinem früheren Arbeitgeber musste ich mal ein Skript in Powershell schreiben, was ein Projekt aus Subversion auscheckt, compiliert, eine Testumgebung erstellt und bestimmte Tests ablaufen lässt. Ich saß damals mit Powershell geschlagene 3 Wochen dran. Mit Bash hatte ich das problemlos in weniger als 1 Woche geschafft.

Mal ein Beispiel, warum ich Bash so mag:
Berechnung größter gemeinsamer Teiler (Euklid):

ggT

#!/bin/bash
[[ $2 -eq 0 ]] && echo $1 || $0 $2 $(($1 % $2))

In Python braucht man da schon mehr Zeilen:

Spoiler: ggt.py

#!/usr/bin/env python3
import sys

def euklid(a,b):
    if b == 0:
        return a
    else:
        if a == 0:
            return b
        else:
            if a>b:
                return euklid(a-b,b)
            else:
                return euklid(a,b-a)

def euklid2(a,b):
    return a if b == 0 else euklid2(b, a % b)

print(euklid2(int(sys.argv[1]), int(sys.argv[2])))

Oder wenn's etwas länger sein soll. Ich hab mal ein Skript gebastelt, wo man seine externe IP abfragen kann auch in Bezug auf Carrier-Grade Nat.

Spoiler: showIP

#!/bin/bash

URL="ifconfig.co"
ipv4=0
ipv6=0
verbose=0
ip=""

print_usage()
{
    echo "IP-Infos"
    echo -e "\nUsage: $(basename $0) [-h] [-4] [-6] [-v] [ip]"
    echo -e "\nOptionale Argumente:"
    echo -e "  -h, --help\tZeige diese Hilfe und beende das Programm"
    echo -e "  -4,\t\tNur IPv4"
    echo -e "  -6,\t\tNur IPv6"
    echo -e "  -v,\t\tZeig mir alles!"
    echo -e "  ip,\t\tPrüfe IP, default=eigene IP"
}

trim() {
    local var="$*"
    # remove leading whitespace characters
    var="${var#"${var%%[![:space:]]*}"}"
    # remove trailing whitespace characters
    var="${var%"${var##*[![:space:]]}"}"
    var=${var//,,/,}
    echo -n "$var"
}

out()
{
    local termlen=$(tput cols)
    local col=10
    local val="$(trim ${@:2})"
    local collen=$((termlen-col-1))
    local outtext=$val
    local next=0

    if [[ ${#val} -gt $collen ]]; then
        temp=${val:0:$((collen+1))}
        outtext=${temp% *}
        collen=${#outtext}
        next=1
    fi

    if [[ "$1" == "+" ]]; then
        printf "%*s$outtext\n" $((col+1))
    else
        # fix multibyte character length in tabbing
        charlen=${#1}
        lang_orig=$LANG
        lc_orig=$LC_ALL
        LANG=C
        LC_ALL=C
        bytelen=${#1}
        LANG=$lang_orig
        LC_ALL=$lc_orig
        col=$((col+bytelen-charlen))
        [[ "$1" == "Name:" ]] && echo
        printf "%-*s %s\n" $col "$1" "$outtext"
    fi

    if [[ $next -eq 1 ]]; then
        out "+" ${val:$collen}
    fi
}

check_ip()
{
  local ip="$1"
  
  # IPv4
  if [[ $ip =~ ^([0-9]{1,3}\.){3}[0-9]{1,3}$ ]]; then
    IFS='.' read -r -a octets <<< "$ip"
    valid=1
    
    for octet in "${octets[@]}"; do
      if (( octet < 0 || octet > 255 )); then
        valid=0
        break
      fi
    done
    
    if [[ $valid -eq 1 ]]; then 
        echo 4 
        return 0
    fi
  fi

  if [[ $ip =~ ^([0-9a-fA-F]{0,4}:){1,7}([0-9a-fA-F]{0,4})$ ]]; then
    # Prüfe auf Doppel-Doppelpunkt (::) für Kompression der Nullen
    if [[ $(grep -o "::" <<< "$ip" | wc -l) -le 1 ]]; then
      # Zähle die Anzahl der Doppelpunkte
      colon_count=$(grep -o ":" <<< "$ip" | wc -l)
      
      # Bei Kompression (::) dürfen es weniger als 7 sein, sonst genau 7
      if [[ $ip == *"::"* && $colon_count -lt 7 ]] || [[ $ip != *"::"* && $colon_count -eq 7 ]]; then
        echo 6
        return 0
      fi
    fi
  fi
  return 1
}

get_city()
{
    echo "$(curl -s "https://api-bdc.io/data/reverse-geocode-client?latitude=$1&longitude=$2&localityLanguage=de")"
}

print_all()
{
    local ip_type=""
    if [[ -n "$ip" ]]; then
        ip_type=$(check_ip $ip)
        retval=$?
        if [[ $retval -eq 1 ]]; then
            echo "IP nicht korrekt. Abbruch!"
            exit 1
        fi
        case $ip_type in
            4)  ipv4=1
                ipv6=0
                ;;
            6)  ipv4=0
                ipv6=1
                ;;
        esac
        ip="?ip=$ip"

    fi
    if [[ $ipv4 -eq 1 ]]; then
        JSON4="$(curl -s -4 $URL/json$ip)"
        CITY4="$(get_city $(jq -r '.latitude' < <(echo $JSON4)) $(jq -r '.longitude' < <(echo $JSON4)))"
        JSON="$JSON4"
        CITY="$CITY4"
    fi
    if [[ $ipv6 -eq 1 ]]; then
        JSON6="$(curl -s -6 $URL/json$ip)"
        CITY6="$(get_city $(jq -r '.latitude' < <(echo $JSON6)) $(jq -r '.longitude' < <(echo $JSON6)))"
        [[ -z "$JSON" ]] && JSON="$JSON6"
        [[ -z "$CITY" ]] && JSON="$CITY6"
    fi
    [[ -z "$JSON" ]] && echo "Fehler: Keine Daten" && exit 1

    out "Provider:" "$(jq -r '.asn_org' < <(echo $JSON))"
    out "ASN:" "$(jq -r '.asn' < <(echo $JSON))"
    if [[ $ipv4 -eq 1 ]]; then
        out "IPv4:" "$(jq -r '.ip' < <(echo $JSON4))"
        out "+" "$(jq -r '.city' < <(echo $CITY4)), $(jq -r '.locality' < <(echo $CITY4)), $(jq -r '.principalSubdivision' < <(echo $CITY4)), $(jq -r '.countryName' < <(echo $CITY4))"
    fi
    if [[ $ipv6 -eq 1 ]]; then
        out "IPv6:" "$(jq -r '.ip' < <(echo $JSON6))"
        out "+" "$(jq -r '.city' < <(echo $CITY6)), $(jq -r '.locality' < <(echo $CITY6)), $(jq -r '.principalSubdivision' < <(echo $CITY6)), $(jq -r '.countryName' < <(echo $CITY6))"
    fi
}

while [[ $# -gt 0 ]]; do
    case $1 in
        "--help"|"-h")
            print_usage
            exit 0
            ;;
        "--verbose")    verbose=1;;
        -*)
            options="${1#-}"
            while [[ -n "$options" ]]; do
                case "${options:0:1}" in 
                    "4")    ipv4=1;;
                    "6")    ipv6=1;;
                    "v")    verbose=1;;
                    *)  echo "Fehler: Unbekannte Option -${options:0:1}" >&2
                        exit 1
                        ;;
                esac
                options="${options:1}"

            done
            ;;
        *)     
            ip="$1";;
    esac
    shift
done

[[ $ipv4 -eq 0 ]] && [[ $ipv6 -eq 0 ]] && ipv4=1 && ipv6=1

if [[ $ipv4 -eq 1 ]]; then
    ipv4_content="$(curl -4 -s $URL/ip)"
    if [[ $? -eq 0 ]]; then
       [[ $verbose -eq 0 ]] && echo $ipv4_content
    else
       ipv4=0 && echo "Keine IPv4 vorhanden."
    fi
fi

if [[ $ipv6 -eq 1 ]]; then
    ipv6_content="$(curl -6 -s $URL/ip)"
    if [[ $? -eq 0 ]]; then
       [[ $verbose -eq 0 ]] && echo $ipv6_content
    else
       ipv6=0 && echo "Keine IPv6 vorhanden."
    fi
fi

[[ $ipv4 -eq 0 ]] && [[ $ipv6 -eq 0 ]] && exit 1
[[ $verbose -eq 1 ]] && print_all

Um noch mal auf das Zitat zurückzukommen.

Schlimmer als Bash geht gar nicht. …

Schlimmer als Powershell geht schon. Das wäre die Command-Shell. Man möge sich da nur mal die For-Schleife reinziehen, die eigentlich nicht mal zwangsläufig eine Schleife ist.

Bei Powershell wird ja immer die .NET-Anbindung gelobt. Wenn man die allerdings benötigt, dann ist man eigentlich an dem Punkt, dass man eine richtige Programmiersprache verwenden kann.

Sachen die mich reizen würden wäre Python oder Golang,

Mit Python machst du definitiv nichts falsch. Mit Go hab ich noch keine Erfahrungen.

 

[andy_m4]

Mal ein Beispiel, warum ich Bash so mag:
Berechnung größter gemeinsamer Teiler (Euklid):

Ja. Und wenn allein im Aufrufpfad nur ein Leerzeichen ist, funktioniert das Skript schon nicht mehr. Mal davon das es ineffizient ist jedes mal ne neue Shell-Instanz zu starten, wenn Du ein Rekursion machst.
Und dann willst Du ja vielleicht noch eine ordentliche Fehlerbehandlung falls die Argumente nicht "passen".

Wenn man das alles berücksichtigt, dann hast Du schnell eben keinen signifikanten Vorteil mehr gegenüber z.B. Python was die Lines-of-Code angeht.

Zugegebenermaßen reichen aber auch nicht-perfekte Lösung oft. Man denke nur an Einmal-Skripte, wo es nur darum geht einmalig ein Problem zu lösen und danach wird das Skript weggeworfen.

Ich will hier nicht irgendwas schlecht machen oder so. Ich finde nur nicht, das es irgendwie Sinn macht sich irgendwelche Sachen rauszufischen, die die "eigene" Sprache gut aussehen lassen. Alles hat so seine spezifischen Vor- und Nachteile und ist für die jeweilige Aufgabe schlechter oder besser geeignet.

 

[BeBur]

Man piped ein Objekt, wo man eigentlich keine Ahnung hat, was da rauskommt. Und das übergibt man an ein anderes Objekt, wo man eigentlich keine Ahnung hat, ob das jetzt damit umgehen kann.

Und bei Bash? Da gibt es gar nicht erst Objekte bzw. gar nicht erst irgendein ernsthaftes Typsystem. Powershell ist da ein riesiger Schritt nach vorne.

Und dazu kommt die grässliche Syntax: CamelCase ist out.

Reine Geschmacksfrage. Ist btw. auch nicht out.

Und Getters- und Setters waren schon vor 15 Jahren schlechter Stil.

Bei typischer objektorientierter Programmierung. Sollte man vorsichtig sein, das in einem Shell-Kontext zu bewerten. Vor allem ist das im Vergleich zu Bash jammern auf hohem Niveau.

#!/bin/bash [[ $2 -eq 0 ]] && echo $1 || $0 $2 $(($1 % $2))

Ziemliches Anti-Beispiel. Welchen Vorteil hat diese Symbolwüste denn gegenüber etwas, das vernünftig lesbar ist? Code wird weit öfters gelesen als er geschrieben wird und es gibt auch kein Platzproblem, das man irgendwie Zeilen einsparen muss, damit der Code noch auf die Diskette passt.

if [[ $ipv6 -eq 1 ]]; then
        out "IPv6:" "$(jq -r '.ip' < <(echo $JSON6))"
        out "+" "$(jq -r '.city' < <(echo $CITY6)), $(jq -r '.locality' < <(echo $CITY6)), $(jq -r '.principalSubdivision' < <(echo $CITY6)), $(jq -r '.countryName' < <(echo $CITY6))"
    fi

Das ist vor allem was für Menschen, die es geil finden, kaum lesbaren Code zu produzieren, damit sie ihren Elitismus ausleben können "also MIR ist das alles glasklar". Oder wenn man gerne in der Zeit stehen bleibt und weiterhin wie vor 40 Jahren programmieren möchte. In einem professionellen Umfeld hat sowas aber nichts mehr zu suchen.

Ergänzung (22. März 2025)

Alles eine Frage der Gewöhnung, genau wie mit vi(m).

vim Kommandes sind Editor-Befehle, die werden einmal geschrieben und keinmal gelesen. Und wenn ein Bug drin ist, dann macht man die Änderung einfach rückgängig.

Man kann Bash einfach nach Linux, AIX, sogar WSL und Cygwin verschieben, es funktioniert immer zuverlässig.

Ja, sowas sind definitiv Vorteile. Es gibt gewiss auch gute Gründe dafür, dass Bash immer noch eingesetzt wird. Diese liegen aber nicht darin, dass Bash so eine tolle Sprache ist.

Und mit Ansible und Pyhton kannst Du doch noch nicht alles so ersetzen, daß man auf Bash in großen Umgebungen verzichten könnte. Mal so tausende Server, VMs, Dockers, Microservices DBs und Co. ohne Bash zu betreuen stelle ich mir sehr schwierig vor.

Woran würdest du sagen liegt das? Also ist ganz neutral und interessiert gefragt. Ist schlicht nicht ganz mein Bereich.

 

[gymfan]

1.) Gefühlt wenig Weiterentwicklung

Für mich ist das Gegenteil davon der Hauptgrund, privat immer noch beim .NET Framework 4.8 zu bleiben. Ich habe schlicht keine Lust, alle 2-3 Jahre meine Programme zwangsweise migrieren zu müssen. Das nervt bei meiner privaten Webseite mit PHP schon dass ich mir bei jeder Mail meines Providers wieder überlege., wie ich PHP endlich loswerden kann und was mich das dann kostet.

Spracherweiterungen von C#/vb.net nuzte ich nur dann, wenn sie für meine Projekte sinnvoll sind. Damit gibt es durchaus noch Abschnitte im Code, in dem ich meine Threads von Hand erzeuge. Das läuft seit 15 Jahren unverändert, also wozu ändern? Nur, weil die Programmiersprache mittlerweile etwas eleganteres bietet?

Was sind eure Meinungen?

Nutze das Tool/die Sprache, die zu Deinen Aufgaben passt.

Bei mir ist es mitlerweile zwangsweisse die PowerShell, da ich nur mit ihr auf den Windows-Servern meine Skripte direkt bearbeiten kann.

Mit Python habe ich mal privat etwas herum gespielt. Eine Sprache, bei der ich Blöcke nur durch Einrückung definieren kann, ist mir persönlich eher suspekt. Mit fehlt vermutlich nur der 2m breite Monitor, um alle riesig eingerückt darzustellen.

Python war halt zum Ansprechen der Stable Diffusion API die schnellste Möglichkeit, um meine Sachen zu realisieren. Und auf dem TV-Receiver war/ist Python auch die bessere Lösung wie Shell-Skripte.

Was ich an Deinen Aussagen nicht verstehe:
Einerseits schreibst Du "konnte man oft auf c# ausweichen", was sich nicht so liest, als ob Du das nicht machen wolltest/gemacht hast. Andererseits ist genau das bei SQLite für Dich das NoGo?

Ich habe einfach meine Zugriffsklassen auf Oracle, MSSQL und SQLite von vb.net/c# konvertiert, dazu braucht es bei mir kein c# im PowerShell Skript. Für die Sachen, die ich damit machen muss, reicht es und ich kann die Datenbanken weiterhin so ansprechen wie ich es seit Jahren gewohnt bin.

 

[nutrix]

Das ist vor allem was für Menschen, die es geil finden, kaum lesbaren Code zu produzieren, damit sie ihren Elitismus ausleben können "also MIR ist das alles glasklar". Oder wenn man gerne in der Zeit stehen bleibt und weiterhin wie vor 40 Jahren programmieren möchte. In einem professionellen Umfeld hat sowas aber nichts mehr zu suchen.

Sehe ich genauso, und sowas wird bei mir, wenn gesehen, mittlerweile aussortiert und umgewandelt, daß kann doch keine Sau mehr warten... Sorry @Pummeluff 😅 Aber ja, man findet sehr viel solches Zeugs, gerade im professionellen Umfeld.

vim Kommandes sind Editor-Befehle, die werden einmal geschrieben und keinmal gelesen. Und wenn ein Bug drin ist, dann macht man die Änderung einfach rückgängig.

Ich meinte das eher in die Richtung Gewöhnung bgzl. Bedienung und Verwendung, weil viele Neueinsteiger jammern, wie alt und schwierig vi(m) als Editor ist. Ich kenne es halt schon lange seit den 80er, und habe damit auch wirklich bis in die 2007er damit programmiert. Gut, natürlich hatte ich dann bei Windows auch Editoren wie Eclipse und VS verwendet.

Ja, sowas sind definitiv Vorteile. Es gibt gewiss auch gute Gründe dafür, dass Bash immer noch eingesetzt wird. Diese liegen aber nicht darin, dass Bash so eine tolle Sprache ist.

Wie gesagt, für mich ist es einfach Batch. Wenn ich was vernünftiges programmieren will, nehme ich natürlich was anderes.

Woran würdest du sagen liegt das? Also ist ganz neutral und interessiert gefragt. Ist schlicht nicht ganz mein Bereich.

Weil in den Scripten teilweise recht komplexe Logik gepackt wurde, oder teilweise dann doch darüber Anwendungen gesteuert werden. Kein Witz, ich sehe Bash Scripte mit ungelogen 1000-3000 Zeilen. Und warum machte man das? Schlichtweg, weil man es konnte, und weil es anscheinend für die damaligen Admins einfach zugänglich war. Da wird ganz munter noch SQL und anderes eingebaut, daß es einem nur den Kopf so dreht.

Ergänzung (22. März 2025)

Spoiler: showIP

aaa

😳

 

[JumpingCat]

Kein Witz, ich sehe Bash Scripte mit ungelogen 1000-3000 Zeilen. Und warum machte man das? Schlichtweg, weil man es konnte, und weil es anscheinend für die damaligen Admins einfach zugänglich war.

Vielleicht hat das auch betriebliche oder andere historische Gründe? Software ist nicht statisch, die wächst mit der Zeit mit den Anforderungen. Eine Erweiterung ist schneller gemacht als eine Neuentwicklung wo man auch noch alles Testen müsste.

Geschweige davon das es auch viele Firmen gibt wo man je nach Abteilubg die Programmiersprache wechseln muss weil es von oben vorgegeben wird. Dazu kommt das man auch (Security) Support braucht und man sich nicht irgendwo einfach irgendwo aussuchen kann.

In einem Startup mag das alles klappen, aber nicht in Firmen wo die IT schon 50 Jahre in Betrieb ist.

 

[nutrix]

Vielleicht hat das auch betriebliche oder andere historische Gründe?

Richtig.

Software ist nicht statisch, die wächst mit der Zeit mit den Anforderungen. Eine Erweiterung ist schneller gemacht als eine Neuentwicklung wo man auch noch alles Testen müsste.

Ebenso korrekt.

Geschweige davon das es auch viele Firmen gibt wo man je nach Abteilubg die Programmiersprache wechseln muss weil es von oben vorgegeben wird. Dazu kommt das man auch (Security) Support braucht und man sich nicht irgendwo einfach irgendwo aussuchen kann.

Wieder ins Schwarze getroffen, gerade das Thema Security, daß Faß will ich hier gar nicht aufmachen.

In einem Startup mag das alles klappen, aber nicht in Firmen wo die IT schon 50 Jahre in Betrieb ist.

Genau, es muß einfach laufen, Betrieb über alles, alles andere ist dann "irrelevant", außer es wird ein dann Securitythema daraus.