Nyílt forrású lett a PowerShell, elérhető Linuxra

Open Source

A Microsoft ma bejelentette, hogy MIT licenc alatt nyílt forrásúvá tette a PowerShell-t. Egyben azt is, hogy elérhető Linuxra és OS X-re. Támogatott Linux disztribúciók az Ubuntu 14.04, Ubuntu 16.04, CentOS 7. OS X-ből a 10.11-es támogatott.

[ PowerShell is open sourced and is available on Linux | PowerShell on Linux and Open Source! | PowerShell @ GitHub ]

( kantal | 2016. 08. 18., cs – 20:12 )

Előrebocsátom, hogy nem ismerem a PowerShellt. Vajon az a hír valódi értéke, hogy az MS megint lépett egyet az open source felé? Vagy van valami ezen túlmutató is, tekintve azt, hogy már rengeteg multiplatformos szkriptnyelv létezik?

________________________________________
https://sites.google.com/site/eutlantis/

nem tetszik nekik, hogy nincs elég megfelelő minőségű bug és hátsóajtó a linux disztrókban, + a windows frissítéshez hasonlóan szeretnének elég adatot lopni a linux felhasználóktól is..

ezért hajlandóak a ronda - egyébként legtöbbször titkolt - kódjaikat is felfedni :))

( secretx v | 2016. 08. 18., cs – 21:04 )

Varom mikor lesz a default shell (ironia)

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( BehringerZoltan | 2016. 08. 18., cs – 21:12 )

Nyújt ez olyan/annyi pluszt linuxon, ami miatt érdemes beleásni magát az embernek? Vagy csak inkább azoknak lett kitalálva, akik elve ezt ismerik és ha linux elé kerülnek akkor is otthonosan érezhessék magukat?

Körülbelül az a kategória. Amit én látok, hogy komolyabb szkriptek már mind pythonban vannak írva. Valszeg az ilyen kereskedelmi linuxok mint a Red hat, Oracle esetleg Ubi előbb utóbb át fognak erre térni.
Viszont azt a tömérdek bash szkripetet ami az idők folyamán felgyűlt nem hiszem hogy át fogják írni. (én biztos nem fogom az enyémeket, igaz ma már én is pythonba vagy luába írok mindent ami kell.)

--
GPLv3-as hozzászólás.

'Valszeg az ilyen kereskedelmi linuxok mint a Red hat, Oracle esetleg Ubi előbb utóbb át fognak erre térni.'

ez nagyon vicces volt!
fel is lépsz vele?

amíg a powershell egy eddig nem is létező problémára ad egy rossz választ, - nevezetesen hogy a unixok, és a unix szerű oprendszerek sok különböző, más-más problémára megoldást kínáló héjjal, scriptnyelvel meg ilyesmivel vannak felszerelne - addig a windowsnak csak a szar command.com/cmd.exe van, ami már a dos 6.22-ben is rég elavult volt. a basic szar meg érthetetlen, körülményes, és hiányos.

most erre kitaláltak egy ugyanilyen körülményeskedő, csak és kizárólag beavatottaknak érthető vackot, és kikiáltották nagyon királynak, pedig céljával ellentétben 6 év továbbképzés kell ahhoz hogy egy 'a' betűt kirajzoljon vele az ember egy terminálra :))

pedig céljával ellentétben 6 év továbbképzés kell ahhoz hogy egy 'a' betűt kirajzoljon vele az ember egy terminálra :))

WUT? :)

Egyébként meg szvsz. majd meglátjuk. Az Oracle ugye ebben a körben nem játszik, azok azt csinálják, amit a PirosKalaposok, akik pedig tényleg lehet, hogy beállnak mögé (miután a jogi osztály kisakkozta, hogy mehet-e :) ): ők is terméket készítenek, mint az MS (szemben azokkal a disztrókkal, amik inkább szoftvergyűjteményt*). Ráadásul elindultak arra, hogy a legtöbb dolog D-Bus-on beszélget (amit lehet utálni meg nem, de azt el kell ismerni, hogy standard, objektumorientált, nyelv- és platformfüggetlen; így nincs az, hogy minden program a saját socket-jén a saját protokollját beszéli, mert NIH), amit kényelmesen lehetne exportálni a PowerShell-be (tekintve, hogy az is hasonlóan objektumokban gondolkozik).

Ráadásul meg is érné nekik, mivel így az MS-es rendszergazdik újabb dolgot tudnának cross-platform használni, vagyis egy migráláskor ezzel is csökkenne az átképzésre fordítandó idő/költség - ami a RedHat-nak jó, mert nagyobb eséllyel mennek neki egy-egy migrálásba cégek.

*: hogy példát is mondjak: a Debian-ban is ott van a PostgreSQL, a Fedora viszont csinált köré egy Server role kezelőt, amivel egy "gombnyomással" (nem tudom, a Cockpit-re kivitték-e már, ha igen, akkor tényleg egy gomb nyomás :) ) feltelepíti és a best practice-k alapján bekonfigolja neked. Másik példa: az egyik Samba dev tartott egy konferenciaelőadást a Samba3 és a Samba4 fejlesztési szemlélete közötti különbségről, hogy a 3-asnál kaptál egy doboz legót (egy LDAP servert, egy KDC-t, egy Samba-t ...), amikből ami kellett neked, azt összefűzhetted egy kész rendszerré - a Samba4-nél már (még :) ) jóval kevésbé tudsz legózni, megkapod az egészet egy termékként, kész és biztonságosra konfigolt LDAP sémával és adatbázissal (példának írta, hogy a legtöbb Samba3+LDAP+KDC tutorial elfelejtette említeni, hogy érdemes nem word writable tenni a userek jelszavait :) ).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

nagyon jók a példák, az elsőnél a fedora csinálta nem az ms,
a másodiknál meg olyan jó tanácsokat adtak a samba4-hez, hogy pont ugyanolyan fatális sebezhetőségek lettek benne mint a windows hálózatkezelésében. köszönjük emese! király volt..

a samba3 legalább működött windows xp-vel, 10-el, de még a régi bizhub nyomtatóval is, ami már nem akar windows 8-al sem együttműködni smb-n keresztül.

szóval pont azok adnak tanácsokat, akik a saját rendszerükkel nem képesek kompatibilis szoftver csinálni :))

az elsőnél a fedora csinálta nem az ms,

Az MS-nek nem kellett ilyet csinálnia, ugyanis már volt neki, egész pontosan ugyanezen a néven, időtlen idők óta. Leültél egy Windows Server elé és feltelepítetted az Active Directory Domain Controller role-t. Aztán ha kellett, a DHCP Server role-t. Aztán...

Ebben a szemléletben (legó vs. kulcsrakész dolog) eléggé le vannak maradva a szabad szoftverek. Mert ott vannak a "cél-disztrók", amik pl. egy bekonfigolt FreePBX-et adnak, vagy egy bekonfigolt tűzfalat, vagy akár (Zentyal és tsai) összekonfigolt teljes kisvállalati rendszert, viszont a standard disztrók bár szállítják az építőkockákat, nem adnak gyorsan és viszonylag standard módon összeállítható rendszereket. (oké, a Fedora már igen)

a másodiknál meg olyan jó tanácsokat adtak a samba4-hez, hogy pont ugyanolyan fatális sebezhetőségek lettek benne mint a windows hálózatkezelésében.

Azok a jó tanácsok speciel a protokollok voltak, ha pl. a Badlock-ra gondolsz (ill. szinte az összes Samba4 CVE protokoll-szintű hiba volt, kevesebb volt az implementációs hiba). A protokollok meg sajnos olyanok, hogy nem árt, ha ugyanazt beszéli mindkét oldal :)

a samba3 legalább működött windows xp-vel, 10-el

A 4-esben is engedélyezhetsz mindent, ami a hármasban ott volt, akár lan managerig visszamenőleg. Csak most secure by default, szemben a hármassal, ahol a disztibnek és/vagy az adminnak kellett a nem biztonságos dolgokat letiltania. (a fenti protokoll-változtatások miatt meg nem meglepő, hogy egy naprakész szerver egy két és fél éve EOL kliens nem állnak szóba egymással)
[egyébként meg a Samba3 _nagyrészt_ működött pl. egy 7-el, annak a megjelenésére az NT 4.0 már EOL volt, így a Samba3-as NT domain már egy nem támogatott, nem dokumentált ... code path miatt működött, és ha jól rémlik registry hack is kellett hozzá]

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

igen...

szóval ha egy használtan is 1-2 m Ft-közé eső árú cucc, jelen eseteben egy nyomtató nem támogatott csak azért mert nem tegnap jött ki a gyárból, akkor nem csoda hogy powershellel kell próbálkoznia az ms-nek, hogy egyáltalán fenn lehessen a szakmai portálokon. mert ennek a kódnyitásnak más célja nincs, az ms hanyatlása meg már nem hír értékű..

még jó hogy a nyomtató gyártója is gondolt ilyesmire, és ftp-n is kommunikál a nyomtató, különben mehetne a levesbe, v. lehetne súlyos 100 ezrekért firmwert szerezni hozzá, mer sajnos nem csak az ms a vendor lock mestere :))

Azért az MS-re sok mindent lehet mondani, de azt, hogy a saját eszközeivel nem működik együtt, azt nem igazán. Az lm/ntlmv1 auth-ot vagy egy évtizeddel azután sikerült alapbeállításon tiltaniuk, hogy megjelentek a triviális törések hozzájuk (Vista/2008).

Logokban a szerveren semmi értelmes nincs, hogy miért nem beszélget a klienssel?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Persze: https://en.wikipedia.org/wiki/Richard_Stallman

"In 1980, Stallman and some other hackers at the AI Lab were refused access to the source code for the software of a newly installed laser printer, the Xerox 9700. [...] This experience convinced Stallman of people's need to be able to freely modify the software they use.[22]"

Az eredményét pedig szabad szoftveres mozgalomként ismerjük... :D

Üdv,
Marci

Hát a konica gyártója sokmindenre gondolhatott. Vagy legalábbis az aki a firmware-t írta + hozzá az összes implementációt ...

Egy "csoda" . Kezdetnek elég annyi hogy pl bizonyos típusok (tán 282++) csak és kizárólag firefoxban kezelhetők weben keresztül.
Míg a kisebb példányok (222, stb) gyakorlatilag bármilyen böngészővel.. Bár, olyat is láttam már, hogy chrome-ba az istennek se találtam XY menürészben Z dolgot, firefoxal lám csodát ott volt benne ... :)

Bár én anno 282-est rá tudtam bírni SMB-re szkennelésre, igaz az egy Samba 3.X volt. 4-es sambával nem próbáltam még. S arra se emlékszem mi volt a "kombó" amivel összejött :)

Az meg hagyján hogy mennyi ezekből az "utángyártott" csoda. Kyocera, Océ, Verilink** ... :) A 222-esekbe pedig olyan gyatra chipek kerültek, hogy megöli a PDF nyomtatásokat, olyan tetű lassú. Kivéve! Ha LPR porttal (btw ezt külön be kell még kapcsolni a Windows szolgáltatásoknál) veszed fel és egy PS drivert feldobsz mellé. Csoda.

Ja bocs, off volt, a powershellhez semmi köze. Csak a konica csodáit láthattuk :)

"példának írta, hogy a legtöbb Samba3+LDAP+KDC tutorial elfelejtette említeni, hogy érdemes nem word writable tenni a userek jelszavait :)"

Szerintem egy tutorial azt feltételezi, hogy nem értesz az összelegózandó dolgok közül 1-hez, 2-höz, n-1-hez. Sem azt nem feltételezi, hogy egyikhez sem (mert ekkor ne te csináld), sem azt, hogy agyalágyult hülye vagy. Mert azért ez a példa ez utóbbit feltételezi. De nyilván kissé kritikus vagyok.

(Amúgy szerencsére :-) én pont ilyen agyalágyultaknak készültet olvastam, amiben levezették, hogy hogyan és *miért*.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

https://www.samba.org/samba/samba/ftp/slides/linux.conf.au-abartlet-sam…

Érdemes átfutni... nézzük a Samba helyett a FreeIPA-t és hogy ha nem lenne a kulcsrakész, telepíthető, összekonfigolt termék, hanem kézzel akarnád összerakni, mi az, amihez értened kellene:
* LDAP (akár openLDAP, akár a FreeIPA-s 389DS, akár...)
* Kerberos (akár Heimdal, akár MIT, akár...)
* NTP (akár a referencia implementáció, akár egy SNTP implementáció, akár az ntimed)
* DNS (akár a bind, akár dnsmasq, akár...)
* Cert authority (és akkor itt a konzolban hívogatott openssl-től kezdve bármi lehet)
* sudoers konfig (centralizálva), pam konfig (centralizálva), nsswitch konfig (centralizálva) - ezek lehetőleg úgy, hogy offline/más hálózatban se zárja ki magát a user a rendszerből [nscd?]
* SELinux konfig
* ha Windows kliensekkel is együtt akarsz működni egy trust idejére: Samba4

És ezek mindegyikét ismerned kell külön-külön, hogy hogyan integrálhatóak, hogy melyik hogyan tud biztonságosan működni. Ja, és skálázódni, ill. hogyan tudsz megszüntetni SPoF-eket.

Vagy felteszed a FreeIPA-t 1-2 szerverre, a kliensekre meg az SSSD-t (vagy a realmd-t, hogy még az SSSD-t se kelljen kézzel konfigolnod, menjen az is automatikusan).

És félre ne érts, nem azt mondom, hogy lehetetlen összedrótozni őket, még azt se, hogy egy FreeIPA-t illik üzemeltetni úgy, hogy nem ismered a programokat, amiket használ ill. a protokollokat, amiket támogat. Csak ami ennyire kiemelten fontos biztonságilag, ott van értelme annak, ha nem úgy állunk a dolgokhoz, hogy "a rendszer építő majd úgyse felejti el beállítani X-et"...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Az a gond Shuttleworth túl sokra értékeli ha egy eszköz mögött kereskedelmi entitás áll (még akkor is ha ő az). Részben igaza van, mert a heartbleed is pénzhiány miatt lett.
Sztem emiatt fogja nyomni a powershellt a bash helyett. De mondjuk mindegy is mivel linuxon mindenki használhatja a kedvenc nyelvét shell szkriptelni (én is ezt teszem).
Nem tudom milyen idős vagy de DOS-on rengeteg batch extension volt. Legjobb talán az NDOS és 4DOS volt. Csak a nagyon lámák használtak sima batch fájlokat... szóval egy bizonyos szint felett a command.com már nem jáccott. De ez tényleg nagyon régen volt.

--
GPLv3-as hozzászólás.

( csabka v | 2016. 08. 18., cs – 22:51 )

Azért a case sensitivity-t nem sikerült megszokniuk :

$ PowerShell -Help
PowerShell: a parancs nem található
$ PowerShell.exe -Help
PowerShell.exe: a parancs nem található

pedig csak a "H"elp javaslata alapján tettem :-), amit amúgy minden formában megeszik biztosra mentek -legalább ebben-: --help -help --Help -Help :-D
$ powershell -help|grep Help
PowerShell[.exe] -Help | -? | /?

Javasolt patch, mert a doksiban mindenhol cserélni szerintem macerásabb:
ln -s /usr/bin/powershell /usr/bin/PowerShell

( uid_17626 | 2016. 08. 18., cs – 22:56 )

Milyen valós igény szülte ezt?

Úgy érted, hogy miért jó, ha egy kereskedelmi termék nyílt forrásúvá, szabadszoftveres licencűvé és közösségi fejlesztésűvé válik?

De hogy ne értselek direkt félre, a fenti videoból: "...make customers successful. Customers live in a heterogeneous world, they wanna use any client, run workloads on any service on any cloud." "Single management stack for all workloads"

Üdv,
Marci

A PowerShell kurvajó. A két dolog közül az egyik, ami nagyon jó a Microsoft-nál (a másik a Hyper-V).
Bash után megváltás konkrétan (és kevésbé idegesítő, mint a python). Ha valahogy SSH-n keresztül is menne (vagy lenne PS-Remoting linuxon... az SSL-es egyébként?), akkor biztosan linuxon is elég szép részesedést vághatna magának a tortából.

ISE is lesz linuxon? Vagy ez hogy működik majd? Mert a szövegszerkesztők eléggé rosszul kezelik a nyelvet egyelőre.

Egyetértek. Bár inkább úgy fogalmaznék, hogy a cmd után megváltás, a bash-t csak simán leiskolázza.

Kíváncsiságból feltettem Bash on Ubuntu on Windows-ra, mert hát az mégis csak egy Ubuntu 14 Windows kernelen. Az Ubuntu 14-t pedig támogatja a Linuxos PowerShell.
Sajnos a konzol megjelenítését össze..ssza ebben a felállásban, mégis csak egy alpha release.

A következő pl. egy Bash on PowerShell on Bash on PowerShell on Bash on PowerShell on Bash on Ubuntu on Windows:

http://kpocza.net/download/bashon.png

A PowerShell nagytestvér ps szűrésében azért van 4 PowerShell, mert önmagát is mutatja, valamint azért van 5 bash, mert egy bash.exe-vel indítja az egész cuccot hostoló Pico processt.

a bash (illetve tulképp az akármi_sh) azért szerintem iszonyatosan tele van olyan baszakodásokkal, amik nem a problémáról szólnak, hanem a toolról. Nehézkes. Ugyan nem ismerem a pst, de a tologassunk objektumokat dolog elméletben egészen jól hangzik, és a szokásos (de most itt double quote kell, mert mivan ha hét lépéssel előbb valaki betett egy spacet), meg a faragjunk mindenféle fura regexpet, hogy faszom borderline karaktereket tesznek néha bele random) szopásokat ránézsére eliminálja.

(ettől még, amikor ps snipletekre nézek rá, akkor egész wattafak fejet szoktam vágni, de nagyon gyanús, hogy csak a nevezéktan szar, és igazából, ha nem tudnám, hogy mit jelent a sed, awk, tr, cat, és hasonló dolgok, akkor gondolom semmivel nem jobb olvasni mint valami random getEntity-t.)

Kb leírtad azt, amit én így fogalmaztam: én ismerem. Azaz hogy mivel tudom (kb) hogy mire kell figyeljek, *általában* meg tudom írni úgy azt a nyomorult 25 elemű pipeline-t, hogy a kívánt eredményt adja. Azaz egy példa: amikor a "ps -ef" kimenetét baszakodják grep-pel, cut-tal, awk-val azért hogy a megkapják az "lpd" processz PID-jét, az azt mutatja, hogy nem ismerik a rendszert. Ha PowerShell-ben tudja, hogy kérheti az objektumok közül csak az "lpd" nevű adatait, majd annak getPID metódusával csak a PID-et (vagy valami hasonló), akkor akár azt is elvárnám, hogy ismerje a "ps -C lpd -o pid=" formát - és máris nem kell baszakodni semmit grep-pel, sed-del, awk-val, tr-rel és cut-tal. (Legalábbis Linux alatt nem. Ahol persze használható a pidof is akár.) A vicc, hogy azt mindenki (?) természetesnek tekinti, hogy a PS-hez regényeket kell elolvasni (szerintem pl. pont az iszonyat elbonyolított nevezéktan miatt) mire használható tudást szerez az ember, addig a shell-programozás c. játéknál nem érti, hogy el kell olvasni és meg kell érteni a man sh-t, a man sed-et, a man 7 regex -et, stb. Ami persze ugyanúgy sok oldal.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

vagy meg kéne nézni a pidof parancsot, és nem kell 'greppelni' 'sedezni' 'awkzni' :))

vagy egyszerüen tudni kéne mit akar az ember csinálni, és máris nem kell powershell. amúgy meg sem a grep-nek, sem az awk-nak, sem a sed-nek nincs semmi köze a bash-hoz. ezek a bash-tól független programok.

A pidof-ot leírtam ;-)
Amúgy az utolsó két mondatod szigorúan nézve csak szintaktikailag korrekt, szemantikailag baromira nem. A legtöbb scriptelési feladatnál még az extrém bashista se tudja kikerülni külső parancsok hívását - azaz ahhoz, hogy valódi feladatot oldjál meg *sh-ban, szinte biztos kell ezek (grep, sed, awk, cut, tr, stb) egy része.
Én szoktam ilyesmikkel játszani, hogy oldjunk meg X, Y, Z feladatot csak shell-internal eszközökkel - hát nyögvenyelős és legtöbbször nem kivitelezhető (volt már hogy itt is leírtam, ha valami érdekesebbet *sikerül* - akár csak részben); nálam persze extrém nehezítő tényező, hogy próbálok nem csak bash-only vagy Linux-only megoldást találni a dolgokra.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Csak most, csak neked *sh internal command megoldás, ami majdnem olyan, mintha PS-ben lenne írva: 


[ -n "$VAR" ] && { echo "Nem üres" ; }

Igazából a kapcsos zárójelek se kellenek, de ebben az esetben nyugodtan lehet sok-sok parancsot lefuttatni a nem-üres esetben. Nyilván ha mind a két esetben (üres/nem-üres) akarunk valamit csinálni, akkor a logikai-és helyett rendes if/then/else/fi írandó.
(Valamint a modernebb shellek mindegyikében létező [[ ... ]] parancs is ismeri a -n str ( és -z str ) - azaz non-zero-length/zero-length tesztet.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Ellenőriztem. Teljesen igazad van, így módosítottam úgy, hogy *sh-ban akkor is jó legyen, ha * épp a c-re illeszkedik (természetesen ez sokkal erőforrásigényesebb, ugyanis csinál egy alshell-t a kerek- vs kapcsoszárójel miatt, de a hordozhatóságnak ára van ;-) ): 


[ -n "$VAR" ] && ( echo "Nem üres" )

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Azért kicsit fordítsuk komolyra is.

Értem én, hogy *sh-ban mindent meg lehet csinálni beépített eszközökkel, de szerintem Te is tudod, hogy a legtöbb rendszergazda a unix toolset nélkül elveszettnek érzi magát. Ami azért teljesen normális, mert egy Unix/Linux pont ezekkel együtt értelmes.
Ha *sh + unix toolset-ről beszélünk, avval kb. valóban mindent meg tud csinálni egy művelt rendszergazda, amit elképzelsz.
Ugyanez igaz egyébként a szörnyű (sic!) CMD-re és tooljaira is. (Kitérő: szeretnék egyszer találkozni a CMD-beli FOR megalkotóival. Lennének kérdéseim.)

A PowerShell viszont ezekhez képest, már csak születési körülményei és kora okán is sokkal modernebb.
Ezért szerintem a szabadszoftveres közösség nagyon értékes dologhoz jutott ezzel, remélem, hasznosítva lesz.

Üdv,
Marci

Modernebb, de milyen függőségeket hoz magával (itt a lényeg szerintem)? :)

De nem vitatom, biztos hasznos (nekem valamiért a syntax baromi idegen) inkább csak túl "magas szintű". :)

Ez olyan mint pl. a legutóbbi sysadmin teszt (you suppose to know how to deploy a dockler container, but who gives sh*t that your test system actually creates an open proxy for the world :))

Feltettem az open PowerShell-t Ubuntu on Windows-ra, mert lusta voltam VM-et indítani.

Az ebben a környezetben bugos readline implementáción kiszenvedtem a következő parancsot: 


  (get-process -processname "powershell").Modules

Ez gyakorlatilag megmondja, hogy a PowerShell process milyen modulokat töltött be.

Ennek eredménye a következő: 


   Size(K) ModuleName                                         FileName
   ------- ----------                                         --------
        88 powershell                                         /opt/microsoft/powershell/6.0.0-alpha.9/powershell
        44 libnss_nis-2.19.so                                 /lib/x86_64-linux-gnu/libnss_nis-2.19.so
        92 libnsl-2.19.so                                     /lib/x86_64-linux-gnu/libnsl-2.19.so
        36 libnss_compat-2.19.so                              /lib/x86_64-linux-gnu/libnss_compat-2.19.so
        92 libresolv-2.19.so                                  /lib/x86_64-linux-gnu/libresolv-2.19.so
        20 libnss_dns-2.19.so                                 /lib/x86_64-linux-gnu/libnss_dns-2.19.so
        40 libnss_files-2.19.so                               /lib/x86_64-linux-gnu/libnss_files-2.19.so
        16 libpsl-native.so                                   /opt/microsoft/powershell/6.0.0-alpha.9/libpsl-native.so
      7424 System.Private.CoreLib.ni.dll                      /opt/microsoft/powershell/6.0.0-alpha.9/System.Private...
       552 Microsoft.PowerShell.CoreCLR.AssemblyLoadContex... /opt/microsoft/powershell/6.0.0-alpha.9/Microsoft.Powe...
       412 Microsoft.PowerShell.ConsoleHost.ni.dll            /opt/microsoft/powershell/6.0.0-alpha.9/Microsoft.Powe...
       412 Microsoft.PowerShell.ConsoleHost.ni.dll            /opt/microsoft/powershell/6.0.0-alpha.9/Microsoft.Powe...
     29048 System.Management.Automation.ni.dll                /opt/microsoft/powershell/6.0.0-alpha.9/System.Managem...
     29048 System.Management.Automation.ni.dll                /opt/microsoft/powershell/6.0.0-alpha.9/System.Managem...
       224 Microsoft.PowerShell.Security.ni.dll               /opt/microsoft/powershell/6.0.0-alpha.9/Microsoft.Powe...
       224 Microsoft.PowerShell.Security.ni.dll               /opt/microsoft/powershell/6.0.0-alpha.9/Microsoft.Powe...
       708 Microsoft.PowerShell.PSReadLine.ni.dll             /opt/microsoft/powershell/6.0.0-alpha.9/Microsoft.Powe...
       708 Microsoft.PowerShell.PSReadLine.ni.dll             /opt/microsoft/powershell/6.0.0-alpha.9/Microsoft.Powe...
      1260 Microsoft.PowerShell.Commands.Utility.ni.dll       /opt/microsoft/powershell/6.0.0-alpha.9/Microsoft.Powe...
      1260 Microsoft.PowerShell.Commands.Utility.ni.dll       /opt/microsoft/powershell/6.0.0-alpha.9/Microsoft.Powe...
      1092 Microsoft.PowerShell.Commands.Management.ni.dll    /opt/microsoft/powershell/6.0.0-alpha.9/Microsoft.Powe...
      1092 Microsoft.PowerShell.Commands.Management.ni.dll    /opt/microsoft/powershell/6.0.0-alpha.9/Microsoft.Powe...
        52 System.Native.so                                   /opt/microsoft/powershell/6.0.0-alpha.9/System.Native.so
     22960 libicudata.so.52.1                                 /usr/lib/x86_64-linux-gnu/libicudata.so.52.1
      2016 libicui18n.so.52.1                                 /usr/lib/x86_64-linux-gnu/libicui18n.so.52.1
      1424 libicuuc.so.52.1                                   /usr/lib/x86_64-linux-gnu/libicuuc.so.52.1
        52 System.Globalization.Native.so                     /opt/microsoft/powershell/6.0.0-alpha.9/System.Globali...
      2196 libclrjit.so                                       /opt/microsoft/powershell/6.0.0-alpha.9/libclrjit.so
       132 liblzma.so.5.0.0                                   /lib/x86_64-linux-gnu/liblzma.so.5.0.0
        64 libunwind-x86_64.so.8.0.1                          /usr/lib/x86_64-linux-gnu/libunwind-x86_64.so.8.0.1
        48 libunwind.so.8.0.1                                 /usr/lib/x86_64-linux-gnu/libunwind.so.8.0.1
        16 libuuid.so.1.3.0                                   /lib/x86_64-linux-gnu/libuuid.so.1.3.0
        28 librt-2.19.so                                      /lib/x86_64-linux-gnu/librt-2.19.so
      6480 libcoreclr.so                                      /opt/microsoft/powershell/6.0.0-alpha.9/libcoreclr.so
       772 libhostpolicy.so                                   /opt/microsoft/powershell/6.0.0-alpha.9/libhostpolicy.so
       628 libhostfxr.so                                      /opt/microsoft/powershell/6.0.0-alpha.9/libhostfxr.so
      1768 libc-2.19.so                                       /lib/x86_64-linux-gnu/libc-2.19.so
        88 libgcc_s.so.1                                      /lib/x86_64-linux-gnu/libgcc_s.so.1
      1044 libm-2.19.so                                       /lib/x86_64-linux-gnu/libm-2.19.so
       920 libstdc++.so.6.0.19                                /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
       100 libpthread-2.19.so                                 /lib/x86_64-linux-gnu/libpthread-2.19.so
        12 libdl-2.19.so                                      /lib/x86_64-linux-gnu/libdl-2.19.so
       140 ld-2.19.so                                         /lib/x86_64-linux-gnu/ld-2.19.so

Tehát van itt .NET natív-től kezdve .NET Core clr-ig minden.

Érdekesség, hogy míg Windows-on a ps alias a Get-Process-re, Linuxon a natív Linux-os ps fut. Vagy pl. Windows-on a dir és az ls is alias a Get-ChildItem-re, itt csak a dir és meghagyták a nativ ls-t.

Elég gáz: 


(ls)[0].GetType()                                                                                                       
IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     False    String                                   System.Object

Tehát, vissza a középkorba. Szöveget kell parsolni, ha valaki az ls kimenetét akarja értelmezni Linuxon PowerShellből és derogál a dir vagy a Get-ChildItem.

fordítsuk

megint ott tartunk mint a doc/xls meg ilyen hülye fileokkal.

önmagán kívül semmivel sem kompatibilis, legtöbbször még önmagával sem, pusztán azért mert az ms-nek olyan kedve van, v. épp nincs, v. képtelen alkalmazkodni, v. alkalmazni a szabványokat.

most fogja magát, és egy semmivel sem kompatibilis, írott/íratlan szokásokon, szabványokon kívüli vackot akar lenyomni a zemberek torkán..

majd később aztán mindenkit megveszteget, hogy ugyan szabványosítsák már az a vackot, ami sehogy és sehova sem illik.

hát velem ezt a szart nem etetik meg..

Ezen nem veszünk össze az x azért került oda mert muszáj volt. (értsd ha nincs "nyílt szabvány" bizonyos szektorból biza nyista money (some restrictions may apply)). Igazából amennyire én tudom a "strict" lenne ISO szabvány (amit semmi sem képes előállítani :D).

Azt meg, hogy mennyire nyílt egy formátum, amit a saját terméken kívül semmi más nem tud rendesen kezelni, döntse el mindenki maga. :)

btw érdekes a fentebbi felvetés.. a szabányokkal kapcs.. ODF-re gondolt gondolom. Az meg létrejött 2005ben.

Ergo, mindenki igazodjon ahhoz.

Csoda világ lenne, ha mindenki egy, kettő.. három, várj.. négy... ja nem, ahányszor forkolták a cuccost... "szabványhoz" igazodna. :)

"Szabvány" esetén nyilván nincs fork, ja de.. van.. Bocs. :(

teljesen mindegy melyik ms projektre, programra leányvállalatra gondolsz, mindegyiknek ugyan az a filozófiája.

senkihez és semmihez nem igazodnak, igazodjon a világ.
ha meg nem akar, az a világ baja :)

ha meg véletlenül elszalad mellettük a világ - lásd mobil oprendszerek stb - akkor becsukják az ablakokat, leeresztik a rolót, és úgy tesznek mint ha világ maradt volna le, nem ők..

nem, akkor félreérhető voltam. Itt a nagy "Opensource" szabányokra akartam helyezni a hangsúlyt, hogy milyen jó is az. Meg hogy mennyi ilyen szabvány is van .. 1+1+1+10+100.

Mihez kellene igazodni? :)

Jó a mobilos példa lehet megállja a helyét, de egy dokumentum formátum? Miért kellett volna az MSnek egy ODF -et követnie standardként ami 2005től jött létre ?
Azért mert opensource ? (ps, szabadon terjeszthető, stb, etc* rakjuk hozzá a megfelelő jelzőket)

talán azért, hogy 2016-ban is el lehessen olvasni azt, amit 2005-ben beleírok egy dokumentumba, és ne kelljen 2009-ben az összes dokumentumot átkonvertálni doc-ból doc-ba, mert egy új verzió jelent meg az msofficeből :)

és senki nem mondta, hogy ne legyen zárt a programja, csak azt, hogy a dokumentumok amiket létrehoz, legyen értelmezhető adott esetben más programmal is, v. 20 év múlva is, meg akkor is, ha már nem is lesz ms..

más oka nem igen van :)

őő, elnézést, de én nem találkoztam olyan .doc-al amit .doc-ba kellett volna átkonvertálni és 2005ben készült volna.

Lehet nekem kicsi a "mintavételem" (300+ kliens + doc ezer féle formátuma).

Olyannal már találkoztam, hogy anno a '92-3-4 -ben készült .doc -okat (ami nem is Word-el készült, hanem valami specific programmal) nem lehetett már office 2007ben (2003 vitte) megnyitni, csak és kizárólag konverzió után (external program, vagy tádááám Libreoffice + save as kombó) .

Amúgy tényleg nem tudom mit nem tudsz elolvasni amit 2005-ben leírtál egy .doc-ba most így 2016ban :)

Pár példa .doc jöhetne, hogy le lehessen ellenőrizni :)

No offense :) ^^

A [, azaz a /usr/bin/test az mióta shell-internal? Az egy tök külön bináris a POSIX szerint AFAIK, sőt, elvárás is a spec szerint, hogy a [ az egy alias legyen a test-re.

Az, hogy egyes shellek internalként implementálják, attól még nem indulhatsz ki abból, hogy a [ internal eszköz. Bizonyos shelleken az, de a szabvány szerint nem.

Amennyiben POSIX-ról beszélünk, akkor [ helyett írjunk [[ -t (meg ugye ugyanígy a záró párjánál is) és készen vagyunk. Igaz, abban az esetben már nem lesz jó csh alatt :-)

Amúgy most kicsit meglepődtem, mert bash alatt a "type [[" aszonta, hogy nem parancsértelmező kulcsszó (de azért tudta mit kell vele csinálni).

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

A [[ az szerintem bash-specifikus, mármint bash-eredetű.

A SUS-ban (ami a POSIX supersetje) nem találom sehol.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html#tag…

Szerk:
bocs, ksh specifikum, és nem része a szabványnak, le is írják:
The KornShell-derived conditional command (double bracket [[]]) was removed from the shell command language description in an early proposal.

Én nem akarok senkit meggyőzni semmiről, csak azt mondtam, hogy a [ az éppen shell-internal lenne POSIX szerint. Mert nem az. Csak éppen egy utility, aminek elérhetőnek kell lennie a rendszerben.

A Shell Command Language nagyon kevés belső funkciót tartalmaz POSIX szerint, eléggé buta nyelv, a különféle shell scriptek csak a rengeteg elérető utilityt hívják meg.
Sőt, általában a test és társait CSAK a shell scriptek hívják, azonban a megkülönbözteés amúgy azért fontos, mert egy POSIX-ra készülő szoftver, ami mondjuk C nyelven van írva, bízhat benne, hogy a utilityket meghívhatja a standard API-val: exec()-kel, fork()-kal stb.

Amúgy ismerjük a KISS-t? 1 program csináljon egy valamit, de azt jól, a többit megoldjuk pipe használatával.
Nem ördögtől való használni külső eszközöket, ennyi erővel ne húzzunk be külső libraryt, próbáljuk magunk megírni az adott problémára (egy valószínű gyengébb) kódot.

ezzel nagyrészt egyetértek, én is össze szoktam tudni rakni a pipeline, mindössze annyit próbáltam mondani, hogy amikor mégiscsak greppel, seddel, meg hasonlókkal kell "bohóckodni", meg control syntaxokkal csesződni (főleg, amikor nem valami eldobhatót tákol az ember), ott az én ízlésemnek sok a zaj, amikor azzal foglalkozom, hogy jó legyen shellben, nem azzal, amit megoldani akarok. Nyilvánvalóan, mivel ebből kifolyólag ezeket én többnyire már másban csinálom meg, egy csomó dolog, ami rutinosabban gyorsan menne, ráerősít erre az érzésre.

Nem (sajnos :)).
Próbáld ki a PowerShell-t, azt tudom mondani. Valószínűleg nem fog megtetszeni, mert az emberek általában nehezen szakadnak el a jól megszokott dolgoktól, főleg ha alapból úgy állnak hozzá hogy "hátezmegmiaszar". :) Viszonylag sokat kell hozzá gyakorolni (néhány hét), hogy ráálljon a kezed (ez sem könnyű, tudom). Érdemes a verb-noun formában megjegyezni a parancsokat, nem a rövidítetteket. (Egyébként az a gyanúm, hogy így alpha állapotban még, egy új platformon nem zökkenőmentes a működése. ) És érdemes a hozzá adott szerkesztőt használni, az sokat segít.

Most meg ilyen szövegszerkesztőből html-be konvertált csoda van normális irodalom helyett: http://www.powershellkonyv.hu/

Nem baj, megkeresem a hivatalos doksit, vagy angol nyelvű könyvet.

--------------------------------------------------------------------
http://www.kmooc.uni-obuda.hu/
http://www.memooc.hu/
http://www.hbone.hu/hu/hirek/hbone_workshop
http://videotorium.hu/hu/channels/details/814,BME_Villamosmernoki_es_In…

Azt írtam, hogy azt nem tudom. Engem SSH-val kapcsolatban ez zavar kicsit, mondjuk eddig fel se tűnt, hogy egyáltalán van. (ez az Anniversary kiadásnál lett alap, vagy a Developer mód kapcsolta be? Mindenesetre ha meg már van akkor lehetne más shell mint a cmd.exe , vagy legalább el lehetne belőle indítani a többit :))

Szerintem az az SSH úgy van, hogy még nincs, szóval sokat ne várj tőle... :)
Legalábbis két hete Steve Lee még csak ígérte a híreket: https://blogs.msdn.microsoft.com/powershell/2015/10/19/openssh-for-wind…
Nekem olybá tűnik, hogy a szükséges service-ek nincsenek is meg az Anniversary Update-et futtató gépemen.

Üdv,
Marci

Hozzáteszem úgy 2009 táján lehetett, hogy először összeraktam, hogy a cmd és PS ssh-n keresztül menjen. Asszem Windows server 2008R2 volt az oprendszer (ez gyakorlatilag egy win 7). A részletekre ennyi év után már nem emlékszem, az biztos, hogy valami 3rd party ssh daemon kellett hozzá, de alapvetően működött. A cmd out of the box ment, de PS már nem volt teljesen triviális.
De a lényeg, hogy azért nem egy rocket science.
---
Régóta vágyok én, az androidok mezonkincsére már!

( KoGa v | 2016. 08. 18., cs – 23:01 )

Na, mi az úristen van? Az MS csinált egy cross compilert, és most úgy tesztelik hogy mindent lefordítanak Linuxra? :)

( freeoli v | 2016. 08. 19., p – 07:49 )

Erre azért elég kemény ébredni de nagyon örülök neki. A lépés érthető, indokolt és még okos is.

( xc0m v | 2016. 08. 19., p – 08:28 )

Előbb-utóbb hivatalos Ubuntu repo-ból is lehet majd telepíteni meg frissíteni? Az szép lesz.

Én pl. mostanában kezdtem átszokni az Office-ról az Office365 webes felületére. Igaz, én nem vagyok hardcore Office felhasználó, leginkább az Outlookot használom. Egyelőre úgy fest, a webes felület megfelel és felszabadult pár megabyte az Office programok törlésével.

Ave, Saabi.

( LordTutu | 2016. 08. 19., p – 09:08 )

Nekem olyan érzésem van mintha a microsoft kiadogatná ezeket az elemeket, majd lekes felhasználok foltozgatnák javítanák az illeszkedést a Linux kernelhez. Miért lehet jó? Nem feltétlen Linux kernelre épített új OS fejlesztésére de a POSIX kompatibilitást és a testeket megússzák ingyen. A végén meg összedrótozzák és kész az új generációs operációs rendszerük ami valóban stabilabb és megbízhatóbb lesz mint az NT sorozat. Ebben mondjuk én nem is látok semmi rosszat! Új piac és a Linux alapú kiadások is kompatibilisebbek lesznek az ő fizetett megoldásaikkal. De ez csak egy érzés és egyéni vélemény!

( jzola v | 2016. 08. 19., p – 09:35 )

Inkább MSSQL 2016 hez van köze szerintem, nem hülyeség egy olyan script nyelv ami linuxon is működik nem kell 2 különt használni feltétlenül.
(bármennyire fanyalognak a powershell soksok munkaórától szabadít meg, tudom nem bash de használható)

Ha te azt hiszed, hogy attól, h immár Linuxon is használható a PS (és Windowson a bash), és ezért nem kell 2 különbözőt használni, akkor szerintem még sem Windowson, sem Linuxon nem futottál bele igazán nagy gebaszba.

De már várom az időt, amikor a SysV initscripteit felváltó systemd-s (amúgy szintén sh-alapú, de ez semmilyen systemd-hívőt ne zavarjon) scriptjei immár powershellbe lesznek átírva.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Nem ezt akartam leírni. Mindenki mindig valami csoda dologra vágyik. pl. univerzális shell ami minden igényt teljesít, ui. várnak univerzális program nyelvet, és lehetne folytatni végtelenségig. Soha nem lesznek ilyenek.
bash se ilyen mert mint fent is látod aki komyolabb scriptet akar írni inkább megírja python vagy másba.
Valamire biztos jó lesz ez is, ha nem akkor meg majd elhalálozik. ennyi.

( XMI | 2016. 08. 19., p – 11:58 )

Egy dolgot nem teljesen értek.
A powershell nagyon erősen épített a .NET framework-re, tkp az igazan 'power' pont az volt benne, hogy tetszőleges .NET library-ból tetszőleges osztályt példányosíthattál és használhattál bármelyik scriptben. Vagyis olyan dolgokhoz tudsz API-ból hozzáférni, amire amúgy nincs kivezetve command line interfész. A linuxos változatban vajon mi teszi ugyanezt alá? Másik probléma, hogy mit érsz .NET library-kel linux alatt, itt egyelőre a komplett ökoszisztéma hiányzik.
---
Régóta vágyok én, az androidok mezonkincsére már!

Nem hiányzik semmi, a .NET Core elég jól sikerült: link

A .NET library-k úgynevezett IL (Intermediate Language) kódot tartalmaznak, olyan kb. mint a Java bytecode, nem processzorfüggő, ezt a JIT fordítja le az adott processzor utasításaira (induláskor vagy telepítéskor).

Fuszenecker Róbert

Ez oké, de azért a .NET eléggé Windows-specifikus API, ami nem biztos, hogy a POSIX-szerűségekre lemappelhető.

Triviális példa: System.Diagnostics.ProcessStartInfo.

CreateNoWindow
Domain
LoadUserProfile

De ugyanígy a FileSystemSecurity osztály, ami csak az NT szemantikát veszi figyelembe, egy sima POSIX chmod ill. egy POSIX/NFS acl nem mappelhető tökéletesen egyik irányba sem.

Ésatöbbi, ésatöbbi. Gyakorlatilag ami miatt a Java fejlesztők állandóan sírnak, hogy erre miért nincs API és miért kell rendszer-specifikus kódot írni, az itt mind felsorolható :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ugyanez felmerül Mono esetén is :-)

Sőt, egyszer írtam egy tök jó kis démont C-ben (mert akkor még meg tudták/akarták fizetni azt, hogy én C-ban programozzak), és meglepődve vettem észre, hogy a fork() másképp viselkedik Linuxon és Windowson.

Nincsenek illúzióim, amikor oprendszer-specifikus dolgokat használok. Nyilván valamilyen kompromisszumot kötöttek a .NET framework fejlesztők.
Ezért (is) vannak unit és integrációs tesztek.

Fuszenecker Róbert

Igen pontosan erre gondolok. Illetve mégsem teljesen, azt nyilván nem várnám el, hogy a scriptek módosítás nélkül fussanak mindkét platformon, inkább Linux specifikus library-k kellenének. Enélkül szerintem a PS lényege veszik el, akkor marad a hagyományos shell script stílusú string trancsírozás.

A .NET-tel szemben a Java esetében kicsit más a helyzet, mert ott eleve tervezési szempont volt a hordozhatóság. A .NET viszont mindig is Windows-ra volt célozva, és ezt most elég nehéz lenne behozni.
---
Régóta vágyok én, az androidok mezonkincsére már!

( kpocza | 2016. 08. 19., p – 22:04 )

Milyen, jelenleg nem aktuális dolgot rajzol a következő PowerShell kifejezés?

$n=16;(0..$n)|%{" "*($n-$_)+"*"*($_*2+1)};(0..($n/10))|%{" "*$n+"*"}

Erre csak a .sig-emet tudom ellenérvként felhozni :-) 


#!/bin/ksh
Z='21N16I25C25E30, 40M30E33E25T15U!';
IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ ';
set -- $Z;for i;{ [[ $i = ? ]]&&print $i&&break;
[[ $i = ??? ]]&&j=$i&&i=${i%?};
typeset -i40 i=8#$i;print -n ${i#???};
[[ "$j" = ??? ]]&&print -n "${j#??} "&&j=;typeset +i i;};
IFS=' 0123456789 ';set -- $Z;for i;{ [[ $i = , ]]&&i=2;
[[ $i = ?? ]]||typeset -l i;j="$j $i";typeset +l i;};print "$j"

Természetesen nem véletlenül szerepel ott a ksh, bash-sal meg zsh-val nem megy - de itt nem is volt szempont a hordozhatóság :-)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

hello, world!n i c e 2 m e e t U!
Eltaláltam? (manuális megfejtés volt, nincs fenn ksh, szóval lehet, hogy elnéztem valamit. Igazából csak typeset -i40-et kellett guglizni, a többit úgy értelmeztem, mintha bash alatt lenne. Ja meg a számrendszer konverzióhoz muszáj volt bc-t használnom, ahhoz most túl fáradt vagyok, hogy fejből menjen)
---
Régóta vágyok én, az androidok mezonkincsére már!

Majdnem pontos, elvben kéne lennie a kettő között egy sortörésnek meg egy kis sor eleji indentnek. És igen, a typeset -i40 az, amin gyakorlatilag minden más shell elbukik, mert olyanja másik shellnek nincs.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Értem az ellenérved sarokpontjait.

Azonban továbbmennék a következő gondolattal: 


$s=$Host.UI.RawUI.WindowSize;$w=$s.Width;$h=$s.Height-1;$n=3;$d=$h*2/3;$m=$d/2;
while($true){$f=new-object 'char[][]' $h,$w
$o=@();1..$n|%{$o+=@{x=(random -mi $m -ma ($w-$m));y=(random -mi $m -ma ($h-$m))}}
0..$m|%{$c=$_;1..$c|%{$r=$_;1..$n|%{$p=$o[$_-1];0..17|%{$a=($_*20+$r)*[Math]::Pi/180
$f[[int]($p.y+$r*[Math]::Sin($a))][[int]($p.x+$r*[Math]::Cos($a))]="*"}}}
cls;$f|%{$l="";$_|%{$l+=$_};$l};sleep -mi 50}}

Aktualitása vitathatatlan, de azért célszerű lefuttatni a megértéshez.
$n állítja a darabszámot.

A fenti azonban csak a nagytestvéren megy. Open Powershell nem képes megmondani az ablak dimenzióit (Ubuntu on Windows-on próbáltam), ezért Linuxon ez a nyerő: 


$w=100;$h=30;$n=3;$d=$h*2/3;$m=$d/2
while($true){$f=new-object 'char[][]' $h,$w
$o=@();1..$n|%{$o+=@{x=(get-random -mi $m -ma ($w-$m));y=(get-random -mi $m -ma ($h-$m))}}
0..$m|%{$c=$_;1..$c|%{$r=$_;1..$n|%{$p=$o[$_-1];0..17|%{$a=($_*20+$r)*[Math]::Pi/180
$f[[int]($p.y+$r*[Math]::Sin($a))][[int]($p.x+$r*[Math]::Cos($a))]="*"}}}
cls;$f|%{$l="";$_|%{$l+=$_};$l};start-sleep -mi 50}}

100x30-as ablak van a paraméterben.

( BaT | 2016. 08. 20., szo – 15:13 )

Amióta olvastam a hírt azon gondolkozom, hogy ez miért jó a Microsoftnak. Van pár tippem, pl. jzola megoldása, de azt is el tudom képzelni, hogy mivel a PowerShell alapvetően egy elég vékony réteg a .NET felett (sajnos nem emlékszem ezt hol olvastam), jól demonstrálja a .NET Core lehetőségeit egy portolt verzió.

De mint általános scriptnyelv alternatíva, nem biztos, hogy annyira ütős Windowstól eltérő környezetben. Én az alábbiak miatt szeretek PowerShellel dolgozni:

  1. Maga a nyelv modern, deklaratív szemléletű, típusos, így komolyabb feladatokra is tökéletesen alkalmas
  2. Rengeteg hasznos cmdlet, a legtöbb általános feladatra van beépített megoldás, pl. csv import-export, http kérések küldése-fogadása
  3. A teljes .NET elérhető vele, ha a beépített cmdletek kevésnek bizonyulnának, pl. írtam már PowerShell scriptet ami képek EXIF metaadatait módosította 3rd party library használata nélkül
  4. Jól integrálódik a Microsoft termékeivel, ebből nekem eddig leginkább a Windows képességeit kiaknázó cmdletek bizonyultak hasznosnak (pl. event log lekérése, process performance adatainak logolása)

Viszont nem Windows rendszereket üzemeltetőknek nem biztos, hogy a fenti pontok bármelyike izgalmas lehet. Kíváncsi vagyok, hogy azok a cmdletek, amik eddig a Windowsról kértek le adatokat, azok portolásra kerülnek-e (pl. event log lekérése).

A Microsoft nemrég bejelentette, hogy az SQL Server is elérhető lesz Linux-on. Arra számítok, hogy további termékek, szerver alkalmazások esetében is hasonló bejelentésekről kaphatunk hírt a közeljövőben. Ugyanis kisebb efforttal portolhatja őket, hiszen ott a .NET Core.

A PowerShell-el számos termék, szerver alkalmazás managelhető, sőt sokszor alapfeltétel a megléte a management eszközök működése miatt. Gyanúm, hogy a PowerShell csak az első lépések egyike egy jól végiggondolt terv kivitelezése során.