Bash, PowerShell, Python - skrypty?

Hej

Uczę się w tej chwili Linuxa i wkrótce będę uderzał w skryptowanie w Bashu. W niedalekiej przyszłości będę się też uczył Win Server oraz PowerShella... No i wpadła mi do głowy pewna myśl.

Bash jest Linuxowy. PowerShell jest Windowsowy. Różnią się składnią. Zapewne również działaniem. A może nie warto zgłębiać się nad nimi jakoś specjalnie, jedynie przerobić podstawy i umieć coś napisać, przeczytać a przycisnąć Pythona? No bo Python jest stosunkowo zwięzły, jest preinstalowany na większości Linuxów, na Windowsie instaluję go w kilka minut.

Z czego korzystacie chcąc zautomatyzować jakieś działania w systemie operacyjnym?

Ja tam od lat skrypty na Windowsa w bashu pisze. Python spoko, ale dla mnie to bardziej język programowania, niż język do automatyzacji. Taki bash naturalniej jakoś działa z plikami, strumieniami etc. Ofc mowa o bash i spółka czyli ln,awk,grep,find,ls,dd,mv etc. Skrypty pythonowe odpalam z basha jak np. chcę coś skomplikowanego zrobić - np. parsowanie plików, komunikacja z zew. serwisami etc.

W dzisiejszych czasach jest zarówno power shell na Linuksie jak i bash na Windowsie (np. przez WSL). Z przyzwyczajeniu raczej piszę w Bashu (znajomi windowsowcy mówią że PS to shit). Jak trzeba napisać coś bardziej złozonego to bash jest bardzo złym pomysłem więc sięgam po perla. Pythona nie trawię, ale jak ci się podoba to pewnie dobry pomysł.

Ja używam PowerShella i naprawdę fajne rzeczy można zrobić dzięki temu, że można bez większych perturbacji korzystać z DLLi .netowych czy jakichś innych. Pyton i PS czy Bash to są języki na zupełnie innym poziomie. Jak chcesz być człowiek orkiestra to Bash, PowerShell, a potem Python no i poza samym językiem trzeba wiedzieć jak ich użyć w konkretnych przypadkach.

• Serce mówi: PowerShell < Bash < Python < Perl
• Rozum mówi: PowerShell < Bash < Perl < Python

J.w. - automatyzacja systemu (backupy, monitoring, cron joby itp) - Bash / PowerShell.
Programowanie małych narzędzi z przetwarzaniem wierszy wielokolumnowych - Python.
Zamiast Pythona możesz jeszcze zastosować Go, Perl, REXX - ale tylko jeśli musisz (są mniej popularne).

Zdecydowanie bash albo Perl. Warto mieć tu świadomość, że Python rzadko używa wywołań systemowych. Dlatego nie ma żadnej gwarancji, że ten sam skrypt nie zmieni swojego zachowania po aktualizacji Pythona albo skopiowaniu na inny serwer. Bash i Perl są tu bardziej przewidywalne. Jeśli skrypt będzie odpalany przez agentów na różnych serwerach, to prędzej bash zachowa się wszędzie tak samo, niż Python.
Oczywiście różnic może być więcej a powyżej to tylko przykłady :) .

Bash nie jest taki kolorowy, bo nikt nie używa czystego basha tylko unixowych narzędzi posklejanych w bashu. A te potrafią się różnie zachowywać np. dużo podstawowych narzędzi zachowuje się w inny sposób na mac os x, bo mają inny rodowód (BSD) i część ficzerów działa inaczej/nie działa tak samo jak w przypadku GNU

Pozwolę sobie na dopytanie w poście, bo uważam że to na temat. @slsy: jakie sa różnice w toolach? Ja zauważyłem że potrafią być inne przełączniki jednoliterowe bo były nie objęte POSIXem. Konkretnie było -D zamiast -d, ale opcja długa czyli --delete działało tak samo. Co do innych problemów z MacOS to teraz tam nie ma domyślnie basha tylko zsh. Przez co niektóre projekty które zakładają że sh to zawsze bash stały sie niekompilowalne :D

@KamilAdam: z tego co pamiętam: brak grep -P czyli perlowe regexy, brak takiej opcji jak -f w readlink -f , która zwraca pełną scieżkę do pliku niezależnie od tego, czy to symlink, relative path czy global path. sed -i nie działa tak samo jak linuxowy odpowiednik. xargs chyba też się różnił, ale już nie pamiętam gdzie. Przykładów pewnie jest całe multum, to co napisałem to problemy, które pamiętam i które sprawiły mi problem

Z tego co pamiętam to też jakieś jaja były z findem. On potrzebował akcji do wykonania z plikami co znajdzie. Podobno powodowało to problemy i od jakiejś wersji domyślną akcją jest -print co wcześniej nie było takie oczywiste.

Natywne CMD pod Windowsem i (BA)SH w systemach uniksopodobnych odznaczają się łatwością i szybkością użycia, są najlepsze do prostych skryptów. Nie radzą albo słabo radzą sobie jednak z przetwarzaniem danych (np. tabel), więc jeśli zachodzi taka potrzeba należy użyć albo pełnowymiarowych języków skryptowych (jak Perl, ew. Python), albo narzędzi typu SED czy języków domenowych (mam na myśli Awk). PowerShell jest hybrydą języka powłoki z językiem skryptowym, dlatego bywa dziwny podobnie jak C++ będący hybrydą paradygmatów proceduralnego i obiektowego. Trzeba jednak przyznać, że PS mimo pewnych udziwnień dostarcza dużą funkcjonalność "na wyciągnięcie ręki".

Po jednym projekcie gdzie bardzo często m.in. podmontowywałem dyski sieciowe w powershellu z innym użytkownikiem niż zalogowany nabawiłem się strasznej traumy.
U mnie zazwyczaj jest mieszanka basha i pythona :P. Jak muszę ojebać jakaś logike to wale to do pythona a reszta w bashu.

slsy napisał(a):

@KamilAdam: z tego co pamiętam: brak grep -P czyli perlowe regexy, brak takiej opcji jak -f w readlink -f , która zwraca pełną scieżkę do pliku niezależnie od tego, czy to symlink, relative path czy global path. sed -i nie działa tak samo jak linuxowy odpowiednik. xargs chyba też się różnił, ale już nie pamiętam gdzie. Przykładów pewnie jest całe multum, to co napisałem to problemy, które pamiętam i które sprawiły mi problem

pieczarek napisał(a):

Z tego co pamiętam to też jakieś jaja były z findem. On potrzebował akcji do wykonania z plikami co znajdzie. Podobno powodowało to problemy i od jakiejś wersji domyślną akcją jest -print co wcześniej nie było takie oczywiste.

To są rzeczy, które wykraczają poza sam język.

Tak i nie. Sam BASH bez tych narzędzi jest nieużyteczny. Rozjazd tych narzędzi na środowiskach może powodować, że cały skrypt BASH wykona się błędnie.

Czyli tak jak prawie każdy inny program używający poleceń systemowych.

No właśnie nie. Bo to nie polecenia systemowe ale programy, które mogą być w różnych wersjach. Zresztą nazywaj to jak chcesz, niemniej może to powodować niekompatybilność skryptów mimo, że napisane zostały w tej samej wersji BASHA. Wystarczy mieć w głowie te różnice i się zabezpieczyć, jednak nie można powiedzieć, że skrypty w BASH będą działać zawsze, a w pythonie w zależności od wersji, bo tu i tu są rozjazdy.

Nie "nazywaj jak chcesz" tylko polecenia systemowe to polecenia systemowe a nie polecenia powłoki. To są dwie różne rzeczy (najczęściej, ale to nie pora na wątki poboczne). Rozumiem, że można się pomylić w przypadku echo, bo pod tym symbolem może znajdować się polecenie powłoki i systemu. Ale find? To jest oddzielny byt.
Co do Pythona pisałem o tym, że funkcje typu os.remove to funkcje Pythona a nie wywołania systemowe. W taki przypadku nie dość, że system może zachować się różnie, to jeszcze Python może zachować się różnie. W przypadku bashowego rm najczęściej potrzebujesz wiedzieć jak działa rm. Gdyby funkcja os.remove zachowywała się jak wywołanie systemowe, nie rzucałaby wyjątkami Pythona. Przykład https://docs.python.org/3/library/os.html

Remove (delete) the file path. If path is a directory, an IsADirectoryError is raised. Use rmdir() to remove directories. If the file does not exist, a FileNotFoundError is raised.
This function can support paths relative to directory descriptors.
On Windows, attempting to remove a file that is in use causes an exception to be raised; on Unix, the directory entry is removed but the storage allocated to the file is not made available until the original file is no longer in use

Gdyby Python miałby być tu bardziej przewidywalny, w dokumentacji nikt nie pisałby akapitu o różnicy między systemami.

Bez tych oddzielnych bytów jak find, grep, awk to bash jest bezużyteczny i można go do kosza wrzucić. To działa jedynie w tandemie i jest użyteczne.

Akurat find, grep i awk możesz mieć jako polecenia powłoki, czyli wbudować je w basha. Wtedy jednak będą zachowywać się jak te, które ktoś skompilował z bashem a nie jak polecenia systemowe. Mimo wszystko nie wiem skąd oczekiwanie, że bash będzie czymś więcej, niż powłoką. Chcesz czegoś więcej, użyj Perla. Tam właśnie jest taka sytuacja - grep zachowuje się tak jak perlowy grep a nie tak jak systemowy.

Niby racja, ale lubię czasem czytać to co napisałem ;)