amirol a bash csak almodhat :)

link

ajanlott ertelmezni is a kodot, nem csak fakkolni

Hozzászólások

Szerintem egy Scala alapu shell is eleg jo lehetne, kb. hasonloan magasszintu mukodest ki lehetne hozni a Scala interpreterre alapozva.

Egyebkent meg a Powershell maga 'nem nagy szam' -- eleg vekonyka reteg a .Net VM folott, ami viszont igazan utos anyag. :) Ezt az Add-Type cmdletnek megfelelo funkcionalitast mar 5-6 eve meg lehetett valositani az .Emit meg a .Compiler nevterekben uldogelo osztalyokkal.

Ketsegtelenul jopofa. :)

----------------------
while (!sleep) sheep++;

Ez a Scala scriptelés már nekem is szöget ütött a fejemben, csak azt sajnálom nagyon, hogy még nem megy készségszinten. Van amúgy annak valami hátulütője, amit még nem látok, ha az ilyesmi tipikusan Bashban íródott dolgokat inkább scalaban írom? Tekintsünk el attól, hogy telepítve kell lennie a scalanak, az adott nálam mindenhol.

A PS meglehetősen okos es izgalmas.

Aztán hogy hogyan gondolták, hogy a 2-es verzió még nem képes úgy írni a stdoutra (csak dotnetes trükkökkel), hogy nem emel hozzá sort, azt én nem érem fel ésszel.

Szintén nem értem, hogy ha már elég jó minőségben lekoppintják a regexpes lehetőségeket, miért kell a replace-t úgy megvalósítani, hogy alapból cserél mindent. Hogy lookodavisszákkal kelljen megoldani a triviális csakazelsőt cserét, az nem evilági gondolkodásmódot tükröz.

A foreach és foreach-object kétarcúsága (miközben előbbi az utóbbi aliasa volna) szintén arculcsapás.

De az igazi kedvencem ez:

PS C:\> ls temp\x

Directory: C:\temp

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 1/26/2010 12:05 PM 950 x

PS C:\> ls temp\x | fl

Directory: C:\temp

Name : x
Length : 950
CreationTime : 1/26/2010 12:05:27 PM
LastWriteTime : 1/26/2010 12:05:27 PM
LastAccessTime : 7/9/2011 7:44:49 AM
VersionInfo : File: C:\temp\x
InternalName:
OriginalFilename:
FileVersion:
FileDescription:
Product:
ProductVersion:
Debug: False
Patched: False
PreRelease: False
PrivateBuild: False
SpecialBuild: False
Language:

PS C:\> ls temp\x ; ls temp\x | fl

Directory: C:\temp

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 1/26/2010 12:05 PM 950 x
out-lineoutput : The object of type "Microsoft.PowerShell.Commands.Internal.For
mat.FormatStartData" is not valid or not in the correct sequence. This is likel
y caused by a user-specified "format-list" command which is conflicting with th
e default formatting.
+ CategoryInfo : InvalidData: (:) [out-lineoutput], InvalidOperat
ionException
+ FullyQualifiedErrorId : ConsoleLineOutputOutOfSequencePacket,Microsoft.P
owerShell.Commands.OutLineOutputCommand

Persze van, ahol megmagyarázzák, hogy ez fícsör... de remélem, az *sh soha nem fog ilyen fícsörrel meglepni.

(A fenti hibákra alig párhetes tapasztalattal bukkantam - de nem bukkantam normális megoldásra/magyarázara a mi barátunk hosszas faggatása után sem.)

Ezzel adtál egy ötletet, amit köszönök! - egyszermind meg is erősíti a fentit, hogy ez az elegancia azért még foltos itt-ott.

Mutatom:


$str = "igen nem igen nem igen"

# natív PS - totális marhaság
PS C:\> $str -replace "igen","!"
! nem ! nem !

# amit a háttérben hív, nyilván szintén
PS C:\> [regex]::replace( $str, "igen", "!")
! nem ! nem !

# de próbáljuk meg még egy paraméterrel - ez se az
PS C:\> [regex]::replace( $str, "igen", "!", 1)
! nem ! nem !

# és ami bejött végre - elegánsnak nem nevezném
PS C:\> ([regex] 'igen').replace( $str, "!", 1)
! nem igen nem igen

Nem kérdezem, hogy mosteztígyhogy, - örülök, hogy nem kell még ígyebben - inkább elfogadom, akkor még biztosan jó ötletnek tűnt.

Linuxon azért nincs szükség powershellre, mert van annál ezerszer jobb. Amit shellből nem tudok megoldani azt megoldom gcc-vel.

Akinek nem teccik a C/C++ annak ott van a python, lua, meg a százezernyi más interpreteres nyelv. Még LOL nyelv interpreter is van ahogy múltkor nézegettem.

A powershell egy hype. A winfos abbéli hiányosságát pótolja, hogy nincs benn egy fordító (pölö: gcc). Egyébként meg ha windozos scriptelésre vagyok kényszerítve akkor meg .vbs, az legalább nem csak win7 meg .NET only, és nem kell hozzá semmit telepíteni. (<- ez egy nagyon fontos érv!)

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

Tevedsz, mar nagyon regen nincs DOS-sal valo kompatibilitas. Kevesse van ugyan dokumentalva, de nagyon sok olyan szintaktikai dolog van mar a BAT/CMD fajlokban, ami egesz jo nyelvve lepteti elo, elvesztve ezzel a DOS-sal valo kompatibilitast.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

"Egyébként meg ha windozos scriptelésre vagyok kényszerítve akkor meg .vbs"

Lehet, de kódméterre vonatkoztatva VBS/PS =~ Tcl/Perl

"az legalább nem csak win7"

???

Speciel pont w7-en nem futtatom, pedig futtatom.

"meg .NET only, és nem kell hozzá semmit telepíteni."

Azért libc és python nélkül a bizbaz.py sem fog futni.

Amúgy az vitathatatlan, hogy a PS túlkompenzálása annak, hogy az admin effektíve semmit nem kapott a Billéktől a melója ésszerűsítéséhez.

Én pedig megkérnélek, menj a fenébe, ha azzal az ötlettel állnál elő, hogy akkor most tegyük fel a DC-kre is a pythont, mert Neked XP-n már sikerült lekódolnod a feladatra a megoldást.

Nem azért, mert nem szeressem a pythont, hanem csak mert nem dev környezetben (ma megtanulhattad, hogy olyan is van) a tököm se fog szükségesen felül egyebet feltenni, hogy a kötelező MS-es fixeken kívül másra is figyelhessek.

XP-re hogy felmehessen powershell kell:

1. valamilyen service pack (nem, nem, nem)
2. .NET (nagyon nem, nem, nem)

XP-re soha nem raknék powershellt.

"Én pedig megkérnélek, menj a fenébe, ha azzal az ötlettel állnál elő, hogy akkor most tegyük fel a DC-kre is a powershellt."

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

Hat, regebben ugye volt a 2k3, amihez az R2 gyakorlatilag minden masodik szerviznel kovetelete a .NET 2.0 feltelepiteset (ami amugy is rajta volt az R2 lemezen), igy eleg nehez volt meguszni az ilyesmit.

Ha pedig tisztan MS alapu a ceg, akkor meg ugye ott vannak a System Center megoldasok, gyakorlatilag tisztan .NET-ben.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

> Production binugz (csak hogy a te szinteten mozgó nevezéktant használjak) környezetben mióta része egy normális rendszernek a c-fordító? És mióta scriptnyelv a gcc?

1. Nem tudom nálad mit jelent a "Production binugz", nálam tizenöt éve linux csak gcc-vel együtt megy fel. Programozok sajnos így járnak, nekünk alapfelszerelés a gcc.

2. Senki nem mondta, hogy a gcc egy scriptnyelv. Pláne én, mert ez a kérdés már önmagában is egy faszság lol.

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

Ahol fejlesztés történik az a devel környezet, ahol a tesztelés az a testing, ami éles kiszolgálást végez, az a production. Az utóbbi kettőben fejlesztőeszköznek (meg fejlesztőnek) nincs semmi keresnivalója.
Itt, most a parancsértelmezők két teljesen eltérő megközelítéséről folyik a beszélgetés, bővebben értelmezve a scriptnyelvekről - te meg jöttél azzal, hogy akkor inkább a gécécé.

Na látod, ez a te olvasatod, mert te valószínűleg csak egy végfelhasználó lehecc.

Nekem a "devel környezet" Linus gépe, "production környezet" meg az én gépem, ahol nagyon is van keresnivalója fejlesztőeszközöknek.

Alapvetően a thread célja hogy a powershell-t ajnározza egy unixos oldalon. Erre jött a sok válasz, hogy a bash jobb. Ha a bash kevés akkor vannak az egyéb scriptnyelvek ala python, perl etc. Ha mindez kevésnek bizonyulna akkor ott a gcc, amivel mindent meg lehet oldani.

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

"Na látod, ez a te olvasatod, mert te valószínűleg csak egy végfelhasználó lehecc. "

Akkor tájékozott végfelhasználó, aki tudja, hogy (miért) létezik szeparáció.

Te meg eszerint alultájékozott, vagy fegyelmezetlen fejlesztő vagy, aki azt hiszed, hogy mindenhol eltűrik, hogy a devkörnyezeten kívül fixelj bármit -- hacsak nem redhoturgentorloseallrevenue kvikkfixről van szó.

Semmit nem akarok fixelni. (Ezt hol olvastad, hogy írtam?) Mindössze azt mondtam, hogy powershell helyett én inkább mást használnék. (python, perl, etc.)

(Egyébként tovább menve. Ha valahol ahol a programomat használnák és hirtelen feltennének egy powershellt (+ szükséges szarokat hozzá XP-re) akkor azonnal lezárnám a support ticketet kérdés nélkül VAGY ha nagyon jó napom lenne azt mondanám szedje le és írjon majd vissza akkor ha ezt megtette.)

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

Akkor ugorj vissza zeller kartácshoz: ha nem kivételesen fixelni akarsz egy élesebb rendszeren, akkor ott semmi keresnivalója gcc-nek, sem egyéb vendégkódnak.

Hogy Te olyan szerencsés vagy, hogy a legkomolyabb támogatott rendszered az XP, amit a komolyságát növelendő pythonnal egészítesz ki, azért csak irigykedni tudok.

Az általam támogatott OS-ek jelentős hányadát teszi ki az XP (bárcsak ne így lenne). DE sehol nem mondtam, hogy az lenne a legkomolyabb.

Nem ajánlom a powershell (plusz a kötelező szarok amiket kér) felinstallálásat, ezt már egy előző posztombam leírtam miért. Ha már szüksége van a felhasználónak egy plusz shellre akkor python, perl, etc. végszükség esetében gcc-t (ami mindenre jó) ajánlanék. (Ezt is leírtam már párszor ebben a threadben.)

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

Így van, nem. (Már ha a visual studiót egyáltalán shellnek tekintjük. Sztem ezzel a világon csak te vagy így ezzel.)

(Sok a szopás a szupporttal, az ember mindig keresi hol tud azon rövidíteni. A powershell, service pack, .NET etc. egyéb faszságok kiváló indokként szolgálnak ehhez.)

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

Amit leírtál az egyik sem alapja. Mindig szakmai alapon vitázok szakmai kérdésekben. Ha vallásháború van akkor néha más alapján is lol.

Akárhogyis, majd ha kikerülsz az életbe és esetleg fejlesztő lesz belőled meglátod, hogy userek iszonyat kreatívak. Minden téren.

De a thread témáját ez nem érinti.

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

Ki lát előre 4 évet az ámítástechnikában? XP-t kell támogatnom 2011-ben lol. A 2.6 és a (pölö) 3.2 között elég nagy különbség van. Nem akarok folyamatosan python szkripteket barkácsolni. Nem ezzel keresem a kenyerem.

De a thread témáját ez nem érinti.

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

"A 2.6 és a (pölö) 3.2 között elég nagy különbség van."

Pont erre gondoltam. Ha vmi kell a 3.2-ből, nyilván szemrebbenés nélkül felteszed - kb. akkora erőfeszítéssel, mint egy .net frissítést. Kétségtelen, az sp tovább tart - viszont ez nem az sp ellen érv, csak a lustaság és trehányság mellett.

Alapvetően mindig egy problémára keresek megoldást. Pölö shell hiányossága. Lehetőleg crossplatform, lehetőleg a legkevesebb belenyúlással a rendszerbe (ne fájjon a usernek: no bloat). Így tudok visszacsatolni a thread témájára. Ebben a relációban: python > vbs > powershell. Így érthető?

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

Amúgy melyiket érdemes manapság tanulni? Tervezek belevágni, de elég kevés könyvet találtam még a 3.x-hez, illetve ahogy elnézem, a külső library-k sem nagyon mennek még vele.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Igen, ezt én is megtaláltam. Mivel a dolog nem sürgős, ezért valószínűleg a 3.x-et fogom választani, egyelőre úgyis konzolos alkalmazásokhoz lenne rá szükségem. Esetleg ha tudtok ajánlani jó irodalmat, akár angolt, akár magyart, azt köszönöm.
És bocs, hogy teljesen offtopic módon beleböfögtem a témába. :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Külön szimpatikus, hogy az általam - e topicban is idézett - felvetett probléma kapcsán nyitott topic szerepel a lámalistában, miközben értékelhető megoldás egy sem született (a listázó részéről sem), ill. ami született, arról kurta dablcsekk után elismerték a beírók, hogy nem megoldás.

Mindegy, az a fontos, hogy valahol megörökítsenek, mindegy, hogy hol és mivel. :)

Nos, akkor bátor ember lehetsz. :)

Remélem amire "supportot" vállalsz, azok nincsenek a netre kötve.
Egyébként nevetséges ez a hozzáállás, így 2011-ben, még ha csak egy nem szupportált XP-ről is van szó.
Ehun-e: http://support.microsoft.com/lifecycle/?LN=en-gb&C2=1173

Namost, én nem szeretném, hogy egyetlen egy általam üzemeltetett rendszerbe személy szerint te szállíts valamilyen "megoldást". Mmmmkay?

ps: Mond neket valamit kedves "GPLv3-as hozzászolás", hogy mit jelent az a szóösszetétel, hogy "vérpistike"? :)

ps2: és aki a szekuriti peccseket "Minden eltérés plusz költség (és idő)." oldaláról nézi, az nemtudom hogy hol él, de hogy ezzel a valósággal diszjunkt halmazokat képez erősen, az is biztos.

Ühü,tehát tesztelni kell.
Zsenikém, megfelelő tesztelési tervvel és megfelelő eszközökkel is lehet ám tesztelni, fillérekből összerámolt tesztrendszeren. Automatikusan.
Ha ezért a peccsek ignorálására kötelezed a megrendelőidet, akkor sajnálni tudom őket.

Láthatóan azért üzemeltetési tapasztalatod sincs, de legalább magabiztos vagy. Ami hülyeséggel kombinálva már azért komolyan veszélyes. :)

... és továbbra is fenntartom, hogy a gyártói peccsek - tesztelés utáni - alkalmazása több mint kívánatos - sőt, kötelező -, amennyiben a teszten nem okozott váratlan side-effectet, és nem szűrhető ki másként a rendszerben máshol. Pl. tűzfalon. Tudom, neked az is ismeretlen fogalom. :)

Tehát nálad az üf. választhat: vagy a te supportodat, vagy a Microsoftét szeretné... (az aktuális SP nélküli oprendszerrel kapcsolatban a Microsoft, meg az OEM partnerek is elhajtanak support kérdéssel a búsba)
Ha én üf. lennék, szerinted mennyi idő kéne, hogy az ajtó előtt találd magad? (Ha szükséges adatokat migrálni, akkor annak a költségét természetesen rajtad leverve)

Ha a megrendelőknek jó, én le nem beszélnélek erről, csak meglep, hogy - az általam is leírt kellemetlen meglepetések mellett, de - végre van valami natív, amivel adminitrálni lehet a wint, és akad, aki olyan nyelvhez ragaszkodik, amely doksijának *for Windows user* fejezete hosszabb, mint a nyelv ismertetője.

De vásárló van egypúpú, van kétpúpú, és van, aki venne még.

Hadd idézzem be az első hsz-emet:

> "Linuxon azért nincs szükség powershellre, mert van annál ezerszer jobb. Amit shellből nem tudok megoldani azt megoldom gcc-vel.

Akinek nem teccik a C/C++ annak ott van a python, lua, meg a százezernyi más interpreteres nyelv. Még LOL nyelv interpreter is van ahogy múltkor nézegettem.

A powershell egy hype. A winfos abbéli hiányosságát pótolja, hogy nincs benn egy fordító (pölö: gcc). Egyébként meg ha windozos scriptelésre vagyok kényszerítve akkor meg .vbs, az legalább nem csak win7 meg .NET only, és nem kell hozzá semmit telepíteni. (<- ez egy nagyon fontos érv!)"

Minden hsz-em ezzel a állításommal konzisztens.

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

Talán Bödöcs Gergelyé a poén a városban felvonuló gazdákkal:

- Miért vonulnak ide?
- Taaargyalni?
- Jön a miniszter, fognak vele tárgyalni?
- NEM!

... vagy ilyesmi. Amiről ez eszembe jutott az az, hogy kb. így tudnálak interpretálni.

M$: Mi a bajod?
b: Nem adsz fejlesztőezközt.
M$: Igazad van. De csináltunk, itt van: PowerShell a neve.
b: Hype!

Nincs szükségem a sajnálatodra - tippelem, hogy a WIndows-os vackaidnál pöttyet komolyabb dolgokhoz volt eddig szerencsém, és nem kell hozzád hasonló ... beszállítókkal a jövőben sem összefutni. Bár volt korábban hasonló hozzáállású társulathoz szerencsém - nulla idő alatt ki lettek hajítva a lomjaikkal együtt.

Keine panik. Csak betöltök egy másik imaget: :P

C:\>gcc -v
Using built-in specs.
COLLECT_GCC=D:\PROGRA~1\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/progra~1/mingw/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapp
er.exe
Target: mingw32
Configured with: ../../src/gcc-4.5.2/configure --build=mingw32 --enable-language
s=c,c++,ada,fortran,objc,obj-c++ --enable-threads=win32 --enable-libgomp --enabl
e-lto --enable-fully-dynamic-string --enable-libstdcxx-debug --enable-version-sp
ecific-runtime-libs --with-gnu-ld --disable-nls --disable-win32-registry --disab
le-symvers --disable-werror --prefix=/mingw32tdm --with-local-prefix=/mingw32tdm
--enable-cxx-flags='-fno-function-sections -fno-data-sections' --with-pkgversio
n=tdm-1 --enable-sjlj-exceptions --with-bugurl=http://tdm-gcc.tdragon.net/bugs
Thread model: win32
gcc version 4.5.2 (tdm-1)

C:\>

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

Szerintem a valamilyen Linux disztribúciót használók mérhető százalékának volt már dolga mondjuk a bash-sel, és még mindig mérhető százaléknyi valamilyen szinten szkriptelni is tud benne. Vajon mennyi lehet ez az arány a Windows akármi.x/Powershell viszonylatban? (De kérdezhetnénk akár csak azt, hogy mennyien hallottak már a PS-ről a Windowst használók körében és mennyien a bash-ről a Linuxot használók között, azt már nem is említve, hogy a Windows használók között mennyien tudnak a bash-ről és a Linux felhasználók között mennyien hallottak a Powershell-ről.)

"a valamilyen Linux disztribúciót használók mérhető százalékának volt már dolga mondjuk a bash-sel, és még mindig mérhető százaléknyi valamilyen szinten szkriptelni is tud benne. Vajon mennyi lehet ez az arány a Windows akármi.x/Powershell viszonylatban?"

Valószínűleg ez a tendencia eltolódik a PS-t ismerő winhasználók irányába a júzerfrendli linuxoknak és a növekvő PS repónak köszönhetően. Átbillenni persze nem fog.

Öcsém azt se tudja, hogy mi az, pedig ubuntun böngészget és írja a lemezeit - totál autszajderként.

Amúgy jó erős az a cellux, kibírt már pár évtizedet.

A programozáshoz kb. pont annyira kell tudni, és - a feladattól függően - a rendszerhez is annyira érteni, csak egyikben azt kell tudni, hogy milyen ojjektumok, milyen tulajdonságokkal szállnak, és mitől, a másikban meg sztringekkel ugyanez.
Hogy aztán ha ezt nem tudod, akkor melyikhez találsz előbb korrekt és használható dokumentációt, az is minősít valamit.

> ajanlott ertelmezni is a kodot

Mesélj: te mit értelmeztél ki belőle?

Vargya': En bash-t hasznalok, es van, hogy js-ben irok hozza "CmdLet"-et, van hogy pythonban, teli vagyok sed es awk inline scriptekkel, es meg csak :: -okkal se kell foglalkoznom.

Akkor most en vagyok a hulye?

Azt, hogy az übermagasszintű szkriptnyelvben időnként (pl. a nem éppen advanced feladatnak számító soremeléstelen stdoutra íráshoz) közvetlenül kell dotnetet cseszegetni, az elegancia sajátos definíciójának foghatjuk fel.

Nem mondom, az tényleg szép, hogy lehet ilyet csinálni - böcsületére válna a *sh-nak is, ha rendszert lehetne hívni belőle, de az kevésbé, ha banális művelethez egyenesen kellene.

Sot, kepzeld, a .NET kezdeten (es talan ma is) windows API hivasokat kellett eszkozolnod string formaban. Ez levon barmit is az elmeleti megkozelites helyessegebol? Nem. A gyakorlati oldal rohejessegeben egyetertek. Ciki. Tenyleg az.

De az is, hogy a kozosseg altal annyira szakmainak szeretett portalon (holott nem az) olyannal buszken eloallni, hogy a korrekt objektum kezeles, a tipushelyesseg es ugy altalaban minden ami egy olyan magas szintu munkat lehetove tesz - nos hogy mindez gagyi es szar legyen, mert a unix shell az etalon (eletmudij! omfg); hat, latod erre celoztam hogy itt ugysem lesz ertelme kifejteni.

A mai friss emberkek kozul mar annyian agymosottak, hogy azt se tudjak mirol van szo. Tenyleg kar.

A Unix shell az etalon, welcome. Szerinted powershellnek hivtak volna ha nem az lenne?

De tudodmit, nem megyek le a te szintedre. Ha te komolyan azt hiszed, hogy tipushelyesseg meg OOP nelkul nem lehet rendszert epiteni, es ezek utan engem nevezel agymosottnak, akkor szerintem sincs nagyon mirol beszelnunk, nem egy kategoria.

Manapsag mindent lehet. Futhat OS javascriptben, lehet 10 wrapper reteg egymason egy sima serialization megvalositashoz, lehet 4 meta nyelv egymas tetejen amik mind az alatta levok hianyossagait foltozgatjak, futtathatsz kulon virtual gepet programonkent es lehet scriptben is rendszert epiteni (akarmit is jelentsen az). Igazad van.

Szvsz te vagy ovis.

De tudodmit, mondok neked valamit, bar nem hiszem hogy a te szinteden lenne az erveles, csak epp mashonnan nezzuk.

Ket fuggveny kozott a kommunikacio mindig egy adott memoriablokk atadasaval zajlik. Egy pillanatra hanyagoljuk a streameket, tegyuk fel, hogy azok mindig vegigolvasottak.

A tipushelyesseg ennek a memoriablokknak az ertelmezeserol szol.

Statikusan tipusos nyelveknel az ertelmezes egy reszet implementalasi (forditasi) idoben, automatikusan lehet ellenorizni. Ez a vedelem nem teljes (pl. egy integer lehet, hogy meter, lehet, hogy lab mertekegysegben van megadva), tovabba nem ez az egyetlen dolog, ami ellen vedekezni kene, es nem is feltetlenul a legfontosabb.

Viszont ennek az ara az explicit jeloles es konverzio.

Amikor te scriptet akarsz osszedobalni, ezt nagyon nem szeretned kerulgetni, az, hogy neked ezen gondolkoznod kell, lassitja a programozasi folyamatot.

Abban teljesseggel igazad lenne, hogy ez egy bizonyos meret utan viszont atlathatatlanna teszi a rendszert. Nade nagy meretben nem is hasznalunk bash-t! Ahhoz kialakultak a specialis esetre a make fajlok ill. az autoconfigure, ahhoz kialakultak a scriptnyelvek mint pl. a szinten atlathatatlan perl, vagy a ruby es a python.

Jellemzoen viszont ezek is kerulik a tipusossagot!

Ez itt feature.

Vannak grafikus pipe rendszerek - pl. Yahoo Pipes - ahol neha nincs automatikus konverzio, de ezek nem tul sikeresek, foleg ha amugy lehetne (pl. Apple Automator)

Igy aztan ugy nez ki, hogy a scripteknel, amik rendszerint csak 1-1 feladatra, egyszer, eldobhato jelleggel kellenek, a legegyszerubb abszolut kerulni a tipusossag kerdeset, es az atadott memoriablokk - stdin - ertelmezeset teljes egeszeben a programozora bizzuk, implicit.

Scripteknel rendszerint az kell, hogy legyen egy vagy tobb adatforrasom, majd ezek kulonbozo szuresevel egy vegeredmenyt tudjak eloallitani, akar egyetlen sorban, interaktivan begepelve. Erre lett a bash, ezzel a feature-rel adtak el anno a UNIX-ot "szovegszerkesztonek" (troff) es programozoi kornyezetnek, es ezzel bizonyit idestova 46 eve.

A shell egyebkent nem lassu: majdnem minden muvelet C-ben zajlik, kizarolag vezerlesert lep ki az "interpretalt terbe", jellemzoen C programokat kotogetsz ossze, akik egy nagyon rovid utasitast - pl. regex - kapnak es jellemzoen agyonoptimalizalt parser facade elemzi oket.

Az OOP-rol pedig annyit, hogy sokan a strukturalis programozas utodjanak, levaltojanak tekintik, holott ez egyaltalan nem igaz: egyfelol a Strukturalt Programozas c. konyv egyik szerzoje Dahl, az OOP atyjainak egyike; foglalkozik is az osztalyokkal rendesen. Ellenben az Alan Kay-tipusu elmeleti OOP tarthatatlannak bizonyult, ma mar sehol nem latjuk nyomat, a class tulajdonkeppen modulszervezest jelent. De errol ne kezdjunk el vitatkozni, mert konnyen kiderul, hogy tenyleg nem vagyunk egy szinten.

Nyilvan letezik egy elegancia az onreflektiv rendszerekben, es nyilvan szep megoldasnak tunik, hogy egy teljesen .NET rendszered legyen shellel. Na de ez UNIX-on nem igeny, itt masrol beszelunk.

"Na de ez UNIX-on nem igeny, itt masrol beszelunk."

Valóban nem igény még csak teljesen véletlenül sem az, hogy amit a saját gépemen összeharácsolok scriptet, az működjön akkor is, ha a kedves r00t user másnaposan felkelt és úgy döntött, hogy neki mostantól más formátumban írja ki az stdout-ra a kontentet.

"Igy aztan ugy nez ki, hogy a scripteknel, amik rendszerint csak 1-1 feladatra, egyszer, eldobhato jelleggel kellenek"

Szerintem te is tudod, hogy mit jelent az IT-ben az "eldobható jelleggel kellenek" kifejezés...

----------------
Lvl86 Troll

Mit akarsz, 35%-at tenyleg eldobjak :)

A bash-nek azert az is funkcionalitasa - es itt azt ertettem bele eldobhatonak - ami egysoros. Nem hiszem, hogy a cat file |grep regex| sort kombot nagyon ujrafelhasznalnad, bar en is gyakran nyomok ctrl-r -t.

Tipusellenorzest (formatumellenorzest) meg nem olyan nehez berakni, csak jo helyen ellenorizd.

Ott a pont... Ha egy objektum valamely tulajdonságát szeretnéd megtudni, és az létezik, akkor azt használod fel a cső következő elemében. Ha hasonlót szeretnél alkotni shell scriptben, akkor először megnézed a megfelelő cumó outputját, kitalálod, hogy sed/grep/awk hogy tudja azt neked megfelelő formára hozni, és bízol abban, hogy az a cumó, aminek a kimenetét szépen feldolgoztad, az a következő verzióban, más környezetben ugyanilyen formátumú kimenetet fog produkálni. (Murphy megmondta, hogy nem...)

Hogy nekem hogy beleállt ebbe jópár éve egy magyar nyelvűre konfigurált AIX-on egy Oracle installáció! Csóri, angol nyelvterületen írt install script nem tudott mit kezdeni az "1996. szeptember 13." szerű kimenettel. :-D
Ilyen szempontból tényleg jobb az objektum átadás.

Ave, Saabi.

Végül is amióta a Sun-t lenyelték, talán akad már egy-két olyan emberük is, aki tud normálisan shell-scripteket írni... Bár a 4.3-as AIX régen volt, és tippelem, hogy 8.valami Oracle lehetett, mert az után már minden telepítőjük Java-s, grafikus felületű szutyok, ha jól tévedek...

Akkor eloveszel egy python-t, erted. Hol a francba mondtam en azt, hogy mindenre ugyanazt kell hasznalnod? Az ilyen .NET-es gondolkodas, hogy van egy kalapacsom, nosza, farigcsaljunk mindent szognek.

A masik oldal meg az, hogy attol meg, hogy compile time fog lehalni neked egy interfeszcsere ekkor, az rajtad sokat nem segit (abba mar nem is megyek bele, hogy javanal rendszerint egy ilyen interfeszcsere runtime fog lehalni, hiaba van Date osztaly 3 is)

Merthogy ha a tudtod nelkul tudjak igy cserelgetni az interfeszt, az azt jelenti, toled fuggetlen komponens. Ha te csak .NET komponensekkel akarsz jatszani, te dolgod, csak nem a nyelvbol kovetkezo kovetkezmeny, hanem a helyzetbol.

De nincsenek se szerializalasi, se adatformatum-cserek jellemzoen kulso interfeszeken, ez egy mondvacsinalt problema, amit a statikus nyelvesek azert nem erzekelnek, mert ott nem lehet, a dinamikus nyelvesek meg azert, mert egyszeruen ilyen nem szokott elofordulni, ill. az esetek annyira jelentektelen szazalekaban, hogy effektiv tokmindegy... Nah mind1. Ha a kulso interfeszed mar tipusos, akkor platform-dependens, ami azt jelenti, hogy API. Ha HTML-t scrapelsz akkor .NET-ben is ki fog halni redesignkor, nem kell hozza bash.

"A karakter az fontos."

Persze, karakteres adatoknál. Számokat meg tessék számként kezelni.

"Mit szerettél volna mondani?"

Ha ennyiből nem vagy képes megérteni, akkor igazából olyat mondanék, ami csúnya, sértő, személyeskedő, de mivel te esetedben felesleges, így inkább nem folytatnám.

----------------
Lvl86 Troll

40 éve működik... még a CMD-ben is.

Egyébként normálisnak tartod azt, hogy a kimenetben nem tudod az a piszokegyszerű dolgot a szkript natív eszközeivel megoldani, hogy kiírsz valamit, aztán amit legközelebb kiírsz, az ugyanabba a sorba kerüljön?

Piszok nagyott változott a világ, ha ez a rendkívüli eset kategóriája lett.

Oke, akkor a bash eleganciajarol olvassunk az Architecture of Open Source Applications-ben: http://www.aosabook.org/en/bash.html

A vilag legszebb pipes-and-filters implementacioja a unix shell, ami alapjaul szolgalt az architekturalis mintakon valo gondolkodasnak; csak a mult heten ezert eletmudijat vett at ket ember: http://www.infoq.com/news/2011/07/garlanshaw

Van meg kerdes az eleganciarol?

Bevallom, én rendkívül vonzódom a maximálisan koherens, az elveiket nem beáldozó rendszerekhez/nyelvekhez, főként ha ezt végig viszik a lehetséges maximumig. (Haskell, Smalltalk stb... )

Ezért pl. szimpatikus a powershell is, és emiatt tudtam néha kicsit idegenkedni a Unix hozzáállásától:

DE aztán rájöttem, hogy mindazoknak a rendszereknek és nyelveknek amikkel olyan remekül elszórakozom, töredékével ismerkedtem volna meg, és használtam volna fel bármire is bármikor, ha nem lett volna alattam egy ilyen sárlabda szerű (bármit bármihez egyszerű elvek mentén hozzáragaszthatsz) kombinálható és befogadó a változatosságot nem diszkrimináló alaprendszer

A shell "gyengeségei" és fent említett befogadóképessége együtt ráadásul szerintem egy külön motiváció minden unixot használónál, hogy egyre több, az éppen adott céljaihoz minél jobban passzoló eszközt megismerjen.
Hát szóval ennyit minimum fel tudok hozni ennek a "dizájnnak" a védelmében...

Ööö... izé... én értem, hogy ez annyira-de-annyira jó dolog, hogy nagyon, de nálam a shell programozás két szinten szokott történni:
- bash + awk, grep, egrep, sed, tr, ...
- perl

Amit nem tudok perl-ben megírni és shell-ben kell fusson, ahhoz a C# is kevés lesz, ráadásul többet kell írni ugyanahhoz az eredményhez, mintha perl-ben írnám. Egyébként eddig még nem futottam bele olyasmibe, amihez a perl kevés lenne, de ha bele is futnék, akkor Java-ban írnám meg... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

És tegyük hozzá, hogy az awk/sed/grep a legtöbbször arra kell, hogy a programonként egyedi formátumú, sima szöveges kimenetből saját szájízednek, vagy a következő alkalmazásnak megfelelően kinyerd a lényeget - ráadásul ezek a részek azok, amik (a csőben előttük/mögöttük lévő program verziójától, platformtól, etc. függően) platfrom és verziófüggőek tudnak lenni...

Linux alá (is) egy rakat objektumorientált interpreteres nyelv létezik. Az hogy a bash pont nem az az szerintem a világ egyik legnagyobb vihar a biliben problémája.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Olyannyira, hogy nem is mindenki tud ojjektum orientáltan programozni. A bash lényege, hogy mindent ész nélkül helyettesít. Így aztán az ember eleresztheti a fantáziáját, remek olvashatatlan kódot lehet írni, ami még lassú is lesz, mégis elégedettek vagyunk az eredménnyel. :)

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Szóval mondom, lehet kedvelni, de ha ilyeneket kell csinálni (pl. egy DNS HOST rekord frissítésekor), akkor a leborulással még várok pár verziót:


$ErrorActionPreference = "SilentlyContinue"

$cnt = 0 # Do it again if it fails as there is a bug with Powershell/WMI
DO

{

$cnt = $cnt + 1

$newPool.Put()

} WHILE (!$? -AND ($cnt -lt 10))

Akkor kérlek - valszeg a hupos tagságom alatt (de talán előtte sem) kértem ilyet - dobj össze nekem egy kódocskát, amely

- win2008 vagy win2003 alatt futva,
- adott domain,
- adott nevű/című hosztját
- adott másik címmel ruházza fel.

Elárulom, hogy órákat töltöttem azzal, hogy olyan megoldást dobjon ki nekünk a mi barátunk, ami nem törlésen és újra létrahozáson alapszik, de amit egyáltalán találtam, abból a legjobbat látod itt - más kérdés, hogy az se csinálja meg.

Végül elfogadtam volna egy VBS megoldást is, is itt kezdtem el dobálni a hajtűimet: a http://msdn.microsoft.com/en-us/library/ms682130.aspx címen fellelhető szkriptet első körben szintaxhibamentessé kellett tennem (ok, ajándék ló) - aztán a tisztított szkript aszondja, hogy ő ugyan nem ír át semmit, mert az általam megadott feltételnek nem felel meg egy rekord sem. A frászt nem.

Szóval hálás lennék bármilyen ötletért, beleértve olyan url-t, amit lemondó apátiámban már meg se néztem a soktucat után.

Kis híján azt válaszoltam, hogy picit elkeserít, ha az eddigi hozzászólásaimból az jött le, hogy lusta és/vagy hülye vagyok - még a mi barátunk kezeléséhez is... aztán előjött bennem a jóhiszem, hogy az egy dolog, hogy nekem ezzel nem (sem) ment ezért:


Exception calling "Modify" : "Generic failure "
At Z:\home\sgombai\scripts\updateip.ps1:14 char:18
+ $oldRecord.Modify <<<< ( 3600, $newip)
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : WMIMethodException

... de, ha ennyire állítod, csak kell legyen benne valami, és megcéloztam egy másik DC-t a gwmi-jal... és voilá, az elhitte, hogy rendben van, amit kérek tőle.

Meg is kapták a labdát a winadminok, derítenék már ki, melyik patch maradt le az elsőként kiszúrt gépről.

Szóval köszönet, amiért a Holmes-féle pályára állítottál!

Lehet Miguel már csinálja a monoshell-t :)

A bash a "cd foo bar" okosságról is csak álmodhat, az pedig nem is egy nagy kunszt...

Nekem néha nagyon kellene, van egy rakat olyan feladat, ahol oda-vissza kéne mozogni tizensok szint mélységű könyvtárstruktúrában, ahol mondjuk a harmadik-negyedik szint különbözik csak. Bash-ban picit horror, más shell-t feltelepíteni a rendszer felépítéséből adódóan dettó, úgyhogy maradt egy statikusra fordított zsh felmásolása a gépre...

A PowerShellel őszintén szólva kettő problémám van. Pedig jóval előremutatóbb, mint egy karakteres maszlagban való turkálás:

- Mivel nincs meg az adott mélységű tapasztalatom PS-ben, ezért még mindig hamarabb összeütök egy PHP scriptet vagy egy C# programot (VS indítással és mindennel együtt), mint mialatt megírom a PS scriptet. Utóbbi esetben még jó eséllyel hatékonyabb is lesz.

Persze, ezen lehet változtatni, tanulással, viszonylag gyorsan.

- Másik probléma, hogy a legtöbb admin nem, hogy nem tud programozni, de eredendően rühelli is. Egyetemen is egy csomó emberrel beszéltem, aki rendszergazda/rendszermérnök beállítottságú ember kérdezi, hogy mégis minek szívatják őket ennyire a programozással. Nah, pont ezért.

Amit a legtöbb rendszergazda produkál "script" címszó alatt (és nem feltétlen PS-re kell gondolni, bash-ban is vannak ám olyan szinten rettenetek), hogy a hajam leteszem, mikor néha látom, hogy mit csinálnak.

És mivel hiányzik az elméleti háttér (mert az fúj, undorító programozás, különben is sokan örülnek maguknak, hogy megértették, hogy működnek a pipek UNIX-on) inkább csuklóból elleneznek mindent, ami picit is újító irány.

Mert minek, mert a régin is össze lehetett taknyolni...

----------------
Lvl86 Troll

Szerintem igazuk is van. A shellnek nem objektum-orientáltnak kell lennie, nem kell felvonultatnia mindenféle, egyre magasabb szintű absztrakciót. Aki erre vágyik, az talál erre nyelvet, mindenféle C++, C#, illetve bármit. Shell scriptben nem alkalmazásokat, s nem is függvénykönyvtárakat ír az ember, arra alkalmatlan, ahhoz lassú, interpretált nyelv. Nem ez a célja.

A shell arra jó, hogy ha hirtelen össze kell szögelni valamit kevés gondolkodással, akkor ehhez ő egy hatékony eszköz legyen. Tehát működjön a "józan paraszti ésszel" történő algoritmizálás. Ne elvont fogalmakban kelljen gondolkodni. Sőt, kifejezetten előnyös itt, hogy a bash egy gyengén típusos nyelv, vagy hogy is mondják ezt a nagyok. :) Szóval nincs szükség deklarációra, mert minden string, adott kontextusban legfeljebb egész számként értelmeződik.

Ha típusos lenne, mire az ember megálmodná az adatstruktúráit, leírná a deklarációit, el is menne a kedve az egésztől.

Bashből a lebegőpontos aritmetikát fájóan hiányolom. Ami szintén kellemetlen, az az, hogy egyes esetekben elég körülményes kimenő paramétereket átadni. Ugye, pipe esetében a cső két oldalán független process-ek futnak, így független a változóterületük. Én úgy szoktam ezt áthidalni, hogy a pipe-ból stdout-ra írok, s az egész csövet, vagy függvényt, amely pipe-ot használ, egy változó értékadásában hívom $() helyettesítéssel. Így akármilyen sok változó átadható, hiszen csak ki kell találni egy delimitert. Ami meg terminálra menne, esetleg el lehet küldeni stderror-ra.

Egyébként erre van szebb megoldás? Tudom, lehetne még ideiglenes file esetleg, bár valamiért nem tetszik.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Látom, a lényeg nem jött át.

A PS pont ott egyszerűsít sokat, hogy nem kell annyit az adatstruktúrákkal foglalkozni, hiszen az már jön a nyelvből. Ha meghívok egy függvényt, akkor annak a visszatérési értékét tudom. Ráadásul többnyire egy gyűjtemény valamilyen típusokból.

Az, hogy OOP vagy csak structok/rekordok halma, az most jelen esetben majdhogynem lényegtelen. Kitalálhatták volna az egészet egy SQL-s felület mögé rejtve is.

A paradigmális váltás csak annyi lenne, hogy ezeket a kész szerkezetet használjuk az egyes toolok között és nem a karaktereket lapátoljuk. És ez egyáltalán nem nagy dolog, nem kell ehhez kitalálni adatszerkezeteket csak egy alapszintű programozói tudás kell hozzá. Messze nem elvont és megtanulható mindenki számára, aki egy receptet képes értelmezni.

A probléma inkább ott gyökerezik, hogy sok rendszergazdának vagy a legminimálisabb programozói tudása sincs meg (és mint írtam, ez a bash szkripteken is nagyon-nagyon-nagyon meglátszik) vagy szimplán mereven elzárkózik attól, hogy tanuljon valami újat.

"Ha típusos lenne, mire az ember megálmodná az adatstruktúráit, leírná a deklarációit, el is menne a kedve az egésztől."

Aki meg már írt .NET-ben ilyesmi jellegű "ragasztókódot", az tudja jól, hogy sok esetben semmi ilyennel nem kell foglalkozni, a deklarált változók is sok esetben var-l vannak megadva, a típus úgy is jön a függvény visszatérési értékéből.

Másrészt viszont egy kis programozói szemlélet nagyon nem ártana egy normális, nem egy soros bash szkripthez.

Az eldobhatóságot meg hagyjuk már... Mindenki tudja, hogy tonnaszámra készülnek olyan szkriptek, amik nagyon nem egyszer használatosak és több évig lesznek üzemben azért, hogy valamit összecelluxozzanak. Értem én, hogy lehet ez MacGyver stílusban is tolni, de attól még egy szigszallaggal összetákolt izé nem az igényesség és a megbízhatóság csúcsa.

----------------
Lvl86 Troll

Attol fugg. Ha nagyon durvan veszem, akkor a jelenlegi shellek olyan adatstrukturat mozgatnak a csovon, ami gyakorlatilag egyetlen szoveges mezoje van, ami alapertelmezett. Ebbol a szemszogbol mar csak egy lepes a komplex adatstrukturak mozgatasa.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Nem. A kategoriak hatarai eleg elesek, ha nem elesek a kategoriaid, akkor te epp valamit elcseszel, az remelem megvan ( http://www.objectmentor.com/resources/articles/srp.pdf )

A shell feladata elsosorban az, hogy a platformra epitett alkalmazasokat el tudd inditani. Ezert hivjak a windows-ban a shell-t explorer-nek; ez biztositja az alkalmazasok inditasahoz szukseges kornyezetet. Az, hogy az alkalmazasok inditasat makrozhasd, ez egy nice extra. A pipe-and-filter rendszer is az.

A szakma szabalyai eleg elesek, es nem te hatarozod meg oket. Nem is en, ellenben nekem van annyi eszem, hogy nem szolok be ertuk.

Háát. Az srp működéséhez nyilván elengedhetetlen a kombinálhatóság, hiszen anélkül értelmetlen az egész.

Az alap (fájlfeldolgozó) Unix világban pedig a különféle filterek adják az alapvető komponenseket, a shell meg biztosítja a kombinálhatóságot, azt a ragasztóanyagot ami nélkül az egész kb. használhatatlan lenne.

Ilyen szempontból nézve, sem a "makrózás" sem a pipe-ok nem elhanyagolhatóak: azaz ha az srp felől nézed, akkor épp pont ezek a legfontosabb funkciói a shellnek (persze nyilván lehetne ezt máshogy is, még jobban elszeparálva megvalósítani, de valahová akkor is be kell kerülni a kombinálhatóságnak...)

Az SRP nem feltetlenul vonja magaval a kombinalhatosagot, nem zarja ki monolisztikus rendszerek letezeset, de mindegy, fogadjuk el.

(Amirol te beszelsz, az a Coupling & Cohesion, ami az SRP inverze, de nem teljes inverze)

En itt nem a Unix vilagrol beszeltem, arrol beszeltem, mit jelent az, hogy user shell.

A PowerShell-nek - eszerint az elkepzeles szerint - viszont nem celja az interaktivitas - interaktiv kornyezetben tipushelyes kodot irni, hajra - hanem egyszeruen valamifele .NET szabvany orchestration-re. Ez biztos egy nagyon szep es fontos dolog ott, azonban a UNIX shellnel mas az elsodleges cel.

"interaktiv kornyezetben tipushelyes kodot irni"

Annak a kódnak is típushelyesnek kell lennie, ahol nem az eszköz hanem csak te felelsz az adatok típusáért. Persze gyenge típusok esetén nem kapsz runtime errort a "2"+3-ra hanem 5-öt vagy "23"-at de ettől még neked kell rá figyelni, hogy mi lesz... (ráadásul - azonnali hiba hiányában - jobban is mint erős típusok esetén)

Tehát szerinted élesen elkülöníthetőek a kategóriák, úgymint shell, scriptnyelvek, XY programozási nyelvek (XY értsd: "hagyományos" vagy valami hasonló). Szerintem akkor te egy nagyon szar szakember vagy. Személyeskedés nélkül, pusztán szakmailag. Pont ebben az iparban minden annyira átfolyik össze-vissza egymásba, hogy hihetetlen, hogy 2011-ben ilyeneket tudsz írni.
----
Hülye pelikán

A shell is a piece of software that provides an interface for users of an operating system which provides access to the services of a kernel

(Forras: http://en.wikipedia.org/wiki/Shell_(computing) )

Nezd, ebben az iparban nem folynak a dolgok ossze, de ezt a kritikat soha senki nem merte megfogalmazni meg, aki velem dolgozott akar egy napot is. Ennek az ellenkezojet viszont azok a mernokok is megfogalmaztak, akik adott esetben az allasukat veszitettek el egy hosszu folyamat eredmenyekent, amiben a vegen en dontottem. Nem gondolom azt, hogy ezt toled, egy nicknev moge bujva el kene fogadnom.

Természetesen semmit nem kell senkitől elfogadnod. Ettől még végiggondolhatod, hogy mekkora hülyeséget írtál le, és milyen látókörre vall. No meg hogy kívülről sokszor könnyebb helyes ítéletet mondani (és persze kevés információ alapján téveset is).
----
Hülye pelikán

Nezd, architect vagyok. Az a dolgom, hogy a szeleburdi ifjak teveszmeit irtsam. Az egyik ilyen, hogy minden atfolyik egymasba. Nem osztok maflast, ha valaki ezt kodba meg meri tenni, de hogy ha rajtam mulik, productionig nem jut el egy ilyen kod, az biztos. Volt mar hogy a gyerek addig eroskodott amig az ajton kivul talalta magat az alternativ felfogasaval a vilagrol, de akkor se szolt ilyet mint te.

Use case-ek vannak, ezekre a use case-ekre megoldasokat nyujtunk, ill. a use case-ek kozott prioritasok vannak. Egy shell prioritasa elsosorban az operacios rendszer cseszegetese, mint azt a wikipedia is szepen leirta (az elso mondatban, ami fontosabb mint a tobbi altalaban.) Hogy emellett meg mit kell tudnia a shellnek, nyilvan interaktivitast: a viccessen python-shellnek meg mittomminek hivott REPL-ok ( http://en.wikipedia.org/wiki/REPL ) celja az, hogy interaktivan, gyorsan ki lehessen probalni valamit.

Ezek azonban nem shellek, nem nyujtanak futtatasi kornyezetet az alkalmazasok szamara; a webbongeszo sokkal inkabb shell.

A PowerShell se nyujt futtatasi kornyezetet a .NET alkalmazasok szamara, nem teszi lehetove egy .NET komponensnek, hogy masikat nyisson; a PowerShell egy REPL funkcionalitassal rendelkezo nyelvi kornyezet.

Amit en alllitottam, hogy ez nem az a versenyzo, akinek a bash-sel versenyeznie kene, hiszen se operacios rendszer feladatokat, se alkalmazasinditast nem celja tamogatni, elsodleges celja mindenfele tipushelyes CmdLet-ek irasa, es amit meg allitottam, hogy az interaktiv es a tipushelyes a sokevtizedes tapasztalatok szerint nem jon ossze jol; evek ota vannak ilyen probalkozasok. Lehet, hogy azonos funkcionalitast nyujt, de teljesen masok a prioritasok, es ez itt a szempont.

Amit meg ezen kivul allitottam, hogy a tipushelyesseg a 70-es evek vegen, 80-as evek elejen tul lett ertekelve, a hibak nem ebbol szarmaznak. Ugy gondolom, ha nem lett volna tulertekelve, akkor nemes egyszeruseggel megszuntek volna a nem statikusan tipusos nyelvek, ehhez kepest ezek eloretoreserol szolt az elmult 10-15 ev, a PHP-tol a pythonon, ruby-n at a javascriptig.

Ez utobbi kijelentes sajatos helyzetembol is adodik, miszerint dynamic language architect vagyok, tehat amolyan sivatagi madar: kevesen hiszik el hogy dinamikus nyelvekhez kellenek architectek, ill. hogy ha valakinek elsodleges terulete a dinamikus nyelvek, rendelkezhet architect tudassal. Ezert rendszeresen durva java felveteliken kell atesnem, hogy aztan ismet elfelejtsem azt a borzalmat amig annal a cegnel vagyok. Na de ennyi.

De sok mindent belelátsz te itt. Gondolom megszoktad, hogy menedzserekkel kell beszélgetni.
Azt állítottad, hogy nem shell feladat az objektumok átadogatása processek között. Ennyit, és nem ezt a sok szöveget itt fent. Erre mondtam, hogy ez igen hülye hozáállás, mivel ez nem a shell FELADATA, mintahogy a bashes pipeolás sem FELADAT, pusztán ESZKÖZ, amivel végre tudja hajtani a feladatát. Ez egy másfajta eszköz, jobban hajaz más nyelvek megoldásaira, de ettől még a feladat elvégzését nem akadályozza meg.
Az igaz, hogy a PS nem olyan igazi shell, például nem az a default parancsértelmező, ami igencsak megcsapja ebben a törekvésben. De ugyanúgy alkalmas shell célokra.
----
Hülye pelikán

Szerintem az akadémiai definiálgatás helyett maradhatunk az Einstein-féle idődefiníció talaján és mondhatjuk, hogy shell az, amit shellként használunk -- aztán hogy mi az számológépnek, vagy éppen tömörítőprogramnak is használjuk, mert tudjuk használni, mert pont úgy írták meg azt a shellt (vagy tkp. nem shellt)... ezen lehet lufit hámozni.

Az architect az a vezeto mernok, ez ne zavarjon. Nem a menedzserekkel beszelgetest szoktam meg, hanem hogy le kell menni neha ha valaki nem erti.

A word is alkalmas tablazatkezelesre, ettol meg az emberek nem hasznaljak erre, mert masok a hangsulyai.

Azt mondtam, ha objektumokat akarsz dobalni, akkor lepj ki a shell-kornyezetbol egy magasabb szintre. Nem emlekszem, hogy az stdout barmely rendszerben objektum-orientalt lenne. Ha valakinek collectionoket dobalo rendszer kell, erre egy teljesen masik platformo vezettek be, ez a MapReduce. Teli vagyunk ilyen alkalmazasokkal, a google szinte kizarolag erre a platformra - GFS - epit. De ez nem OS shell, egyebkent ez sem teljesen tipushelyes (scheme-free adatbazisok).

1. Nem úgy általában az architektekről beszéltem, hanem rólad.
2. Még mindig nem látom, hol a baj azzal, ha egy shell máshogy oldja meg a dolgait, mint a szerinted etalon, ha a végeredmény ugyanúgy szöveg és programindítások (jelenleg ez a két sarokköve a shellfogalmadnak ahogy nézem).
----
Hülye pelikán

Te mondd, tetra, mitol nem vagyok jo mernok neked? Attol, hogy nem ertek egyet azzal a felveteseddel miszerint a vilag osszemosott? Melyik tanarod mondta ezt hogy az, hol szerepelt a tananyagban?

A PowerShellnel pedig a koztes eredmeny egy marshalling, es erre mondtam azt, hogy ez nem shell funkcio, ha te marshallingot akarsz, kergesd be egy erre alkalmas kornyezetbe. Hol itt a gond?

Asszem sehol nem állítottam magamról, hogy jó mérnök lennék :P

>Te mondd, tetra, mitol nem vagyok jo mernok neked? Attol, hogy nem ertek egyet azzal a felveteseddel miszerint a vilag osszemosott?

Nagyjából igen. Olyan kategóriákban gondolkozol, amik nem léteznek ilyen kategórikusan. A mérnök meg a valósággal foglalkozik.

>Melyik tanarod mondta ezt hogy az, hol szerepelt a tananyagban?

Sehol, ilyesmikről nem tanultunk ha jól emlékszem.

>A PowerShellnel pedig a koztes eredmeny egy marshalling, es erre mondtam azt, hogy ez nem shell funkcio, ha te marshallingot akarsz, kergesd be egy erre alkalmas kornyezetbe. Hol itt a gond?

Ott, hogy a marshalling csak egy eszköz, és nem befolyásolja a shell funkcionalitását. Ez nem funkció, ez az ő logikája, amivel ellátja a funkcióját, és nagyon sok embernek kifejezetten tetszik (én nem vagyok köztük, de csak mert nem foglalkoztam vele túl sokat, így nem tudok róla véleményt mondani), nyílván nem azért, mert nehezebbé teszi a munkát.
----
Hülye pelikán

Nagyon nagy baj lenne, ha a vilagot nem tudnank kategorizalni... Mi a fenet kezdenenk az osztalyrendszereinkkel? Hogy oldanank meg a modularizalast? Mit tudnank kezdeni a mintanyelvekkel?

A mintanyelvek (Pattern Languages) pont ez a "csunya" kategorizalas, amit te kerulsz. Pont mostanaban van egyebkent az eves mintanyelv konferencia, de ugy ereztem, nem eri meg az ezrest (euroban), nem mentem.

Na de viszont a mintanyelvek pont errol szolnak, hogy dolgoknak adunk nevet, es nem pusztan a reszek, de a hangsulyok is szamitanak benne. Nagyon sokan nem ertik, mi kulonbseg a decorator meg a proxy kozott, meg a delegacio egyeb formai kozott, hisz ugyanolyan kodot adnak; na de hisz mashol van a hangsuly!

De nezzuk teny szerint: a bash, ill. A bourne es korn shell leszarmazottjai minden hianyossaguk ellenere rendkivul nepszeruek. A PowerShell viszont legfeljebb kuriozum; ugy alakult, hogy egyre ismertebb lesz, de nem latjuk hogy terjedne; persze lehet, ez a windowsos vilagban nem ilyen, .NET-es barataim speciel nekem nem hasznaljak, nem latjak sok ertelmet.

Az eles kategorizalas az informatikaban "szukseges rossz": egy osztalynak, egy modulnak nem lehet ket neve. Persze figyelnunk kell arra, helyesek-e ezek a kategoriak, en azt allitottam, hogy a PowerShell mint shell bekategorizalasa nem az. Persze az ido eldonti, na de kedves tetra, azert, mert ezen mas velemenyen vagyok mint te, azert lennek en rossz mernok?

A PS programozóknak nem is kell - ellenben üzemeltetőknek hasznos. Exchange-et, Lync-et túrni bizonyos esetekben sokkal jobb ezzel, mint a GUI-n.

Az meg, hogy van-e 5 éves távlatban jövője szerintem most megtippelhetetlen. Azon múlik a dolog, hogy az MS hogy dönt, marad a .NET világnál, vagy vált HTML+JS (vagy valami hasonló) világra. Ezt meg (tudtommal) most még ők maguk sem tudják, előbb várják a piaci reakciókat.

Mondjuk azon azert erdemes lenne elgondolkoznod, hogy miert kell majdnem minden topicban elmondanod, hogy te architect vagy.

Az ex-csapatomban volt olyan szabaly, hogy aki eroskodik a felvetelin, hogy o architekt, az nem vesszuk fel, ugyanis jo esellyel hatalmas lesz az arca. (Ehhez hozzatartozik, hogy Oxbridge-es A+ diplomakkal rendelkezo emberek sem emlegettek allandoan, hogy ok architektek, meg csucskoderek, meg nagyonertenekhozza, siman megcsinaltak a feladatot, es ha ervelni kellett, szakmai ervekkel tettek, nem pedig azzal hozakodtak elo, hogy ok tudjak, mert ok az architektek, vagy mert ok az MIT-n szereztek diplomat, vagy mittudomen.)

----------------------
while (!sleep) sheep++;

Na varjal. Azt, hogy ti ilyeneket nem vesztek fel, az nagyon helyes, nem egymast keressuk, ez egy jo szuro.

A foiskolai topicban akkor hoztam ezt elo, amikor jott, hogy ez nem PM feladat; itt mar nem en hoztam elo, hanem valoszinuleg a masik topicbol olvasva tetra, es erre reagaltam, hogy de szerintem en igenis jo architect vagyok, senkitol soha nem kaptam negativ feedbacket a szaktudasomra vonatkozoan, a stilusomat nem csiptek sose (pl. azt, hogy igen, hajlamos vagyok lezarni az akadekoskodast, hogy dontsuk el, ki a fonok, es ervek nelkuli vitakat se szeretek vegigcsinalni.)

Az, hogy miert hangsulyozom ezt, ez szemelyes problema, illetve hat korszakos: utalok beosztott programozo lenni, de kevesen ismerik manapsag ezt a fogalmat. Szerintem a tobbi programozonak is ego, ha nem egy forumtopikban hangoztatom hogy en architect vagyok, hanem miutan a karukra bizonyosodott be, hogy nagyon nem vagyunk egy szinten. Soha tobbe nem akarok elmenni "sima" fejlesztonek, senkinek nem jo ez.

Megis mire? Arra, hogy te itt kijelentetted, hogy nagy arcod lehet? Hagyjal mar.

Oszinten szolva megkerdeznem a veled dolgozok es a volt kollegaidat is errol. Persze, lehet, en talalkoztam tobbsegeben rossz emberekkel, de a kemeny tapasztalat bizony azt mutatja, hogy aki ennyire a magas lorol lenezoen, szemellenzosen beszel.. nos, annak a legritkabb esetben kellene, hogy akkora arca legyen, mint amit te mutatsz itt.

----------------
Lvl86 Troll

Ebből nekem az jön le, hogy nem architect (vezető) vagy, hanem főnök.

Architect és/vagy vezető olyan személyből lesz, akit a többiek vezetőnek tartanak és akinek a tudását, munkáját elismerik. Főnök abból lesz, aki kiköveteli magának az elismerést, illetve hangerővel és arrogáns viselkedéssel pótolja a tudása hiányát. A főnök soha nem kap negatív visszajelzést, egy vezető kap kritkát és figyelembe veszi azt.

Attól, hogy utálsz beosztott programozó lenni, attól még nem leszel architect... csak főnök.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Mert szerinted en hogy lettem az?

A bajom az, hogy mostanaban ilyen flat informatikai strukturakat akarnak (ohne teamlead, ohne barmi), na ez nem jo, mert igy nem tudom korrigalni a teammate-ek hulyesegeit, anelkul, hogy ne legyen belole botrany. Mert osszeterelnek 10 programozot, aki persze elozo eleteben mind senior meg teamlead volt, csak aztan valahogy megis lesz egy szintkulonbseg.

Pontosan. Illetve en leulok programozni, frameworkot, meg atbeszelem barkivel hogy hogy kell leimplementalni valamit, meg atnezem a kodot, es - bar amikor felb.szom az agyam es flame-elek, epp nem, de egyebkent - a devianciat korlatos mertekig hagyom (pl. az SQL injection nem tartozik ezen korlaton belulinek)

Az atlag nagyvallalat viszont ugy mukodik, hogy _mindenki_ egyenrangu, aztan kiosztjak a modulokat kb. Na ebbol hogy mekkora f.s keletkezik, arra nincs kifejezes. Ismert, hogy minoseg-buzi vagyok, es szivemen viselem a szoftver mukodeset. Azok a szoftverek, amik kikerulnek egy ilyen kornyezetbol, nem kivul szepek belul nehol foltokban rohadnak, hanem konkretan szarkupacok, legaljatol a UI-ig.

Nyilvan ebbol veszekedes van. Nyilvan veszekedes van belole, ha azt mondom, hogy ezt meg lehetett volna feleennyi ido alatt normalisan irni, akkor ha letromfol hogy "akkor ird meg b.zdmeg" es delutanra egy olyan kod van az SVN-ben amin maszturbalhatsz, ez feszultseget okoz. Vagy ha lerajzolom neki abran, hogy miert nem jo az elgondolasa, akkor a "hagyja' beken az UML-es fassagaiddal" megy, es QA-n dol be a f.szba az egesz, ket hettel kesobb,hatarido elott fel nappal. De ez nem szemelyfuggo, altalaban a code monkey szerep fost eredmenyez, az egysegesites meg csak azt, hogy mindenki code monkey lesz, mert nem vallalja fel a konfliktust. En meg de.

Igazabol engem nem erdekel, hogy mi szeretsz lenni es mi nem. Arrol volt csak szo, hogy mindig fontosnak tartod megjegyezni, hogy marpedig te
- architekt vagy
- architekt blogot irsz (vicc)

Raadasul annak hangoztatasa, hogy mindig igazad van, nem a pozitiv feedback hatasa (hiszen mindig is igy volt).

De nem osszeveszni jottem ide, csak folyamatosan es konzisztensen a beleesel a http://en.wikipedia.org/wiki/Argument_from_authority#Appeal_to_authorit… kategoriaba, amit szamomra zavaro olvasni idonkent.

----------------------
while (!sleep) sheep++;

Újabb logikai baki. Az, hogy valami jó-e avagy sem, illetve hogy shell-e avagy sem, nem jellemzi igazán jól az elterjedtsége, hiszen az számtalan egyéb, hangsúlyosabb tényezőtől függ. De gondolom a te tiszta kategóriáidba nem fér bele az, hogy egy dolog több dologtól is függhet, hiszen az már tervezésileg is bonyolítja a helyzetet.
----
Hülye pelikán

Na most ez alapvetően ez egy manageri (tehát nem beosztotti) hozzáállás. Ez konzisztens a "nem szeretek beosztott lenni" kijelentéseddel. A mérnöki az lenne, hogy próbáljuk ki hátha jó és utána használja. A troll meg csinál egy topikot "amirol a bash csak almodhat :)" címmel. A gyengék (+ oskolaszünetes diákok, trollok, agitátorok) meg bekapják a flame-baitet. :D

Úgyis mindenki azt használ amit akar. Vagy amit mondanak neki hogy használjon, vagy amiből meg tud élni (ez volnék én).

Na mindegy is, jó kis flame thread lett ebből. De legalább mindenki elmondott mindent, ami a lelkét nyomja.

/exiting thread.

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

Nem azt mondtam, hogy az a tokeletes, azt mondtam, hogy a trendek szerint a PowerShell, vagy ahhoz hasonlo technologia nem fogja levaltani a bash-t, es ennek az oka az, hogy a ket igeny ugy latszik, kulon szalon fut. Mint ahogy az egysegesitett office suite is egy idoben meno volt, de azota az openoffice is kulon-kulon szoftvernek alcazza magat.

Nem csuklobol iteltem el, azt allitottam, hogy nem felel meg azoknak az igenyeknek, amik miatt a bash-t hasznaljak emberek. Mindezt azutan, hogy nehany eve mar itt van a piacon, es evente egy-egy ember feltunik villogni vele, hogy marpedig ez "jobb". Ez egy velemeny.

5 ev mulva az derul ki, hogy lesz-e pl. default powershell parancseretelmezo windowson (elkepzelheto), ill. lesznek-e powershell-probalkozasok mint unix parancsertelmezok, es ezek mennyire lesznek sikeresek.

Mert hulye; honnan van ez a statod egyebkent?

A shell soha nem akadalyozta meg, hogy elso mozdulattal bekergesd az inputodat valami rendszerbe, ami onnantol kezdve OOP elmukodgethet. De engem mar az is zavar, hogy nem tudok cat parancsot kiadni konyvtarra linuxon, nem kell nekem hogy megjobban tipusos legyen.

(Rendes UNIX-on cat konyvtarnev parancsra fajllistat kene visszakapnom null-delimiterekkel)

Ha nekem ilyen problemam volt, hogy strukturalt adattal akartam dolgozni, bekergettem mindig pythonba (ujabban node.js-be) aztan kesz.

Szerintem higgyük el, hogy aki igényes kódot ír(na) PS-ben, az igényeshet ír sh-ban is, és így az sh-nak se lesz szigszalagabb tulajdonsága, mint a libc-nek.

Ráadásul mindez független attól, hogy admin, fejlesztő, vagy ébben tesztelő-e az illető.

Amióta a programozás egynyelves betanított munka lett, bízhatunk abban is, hogy a java-only fejlesztő semmivel sem áll(na) kevésbé fejre a PS shelles paradigmáitól, mint a bashonly admin az OOP-sektől.

Ati ipatoi, madáta ipatoi.

Azt azért vegyük észre, hogy pinyo_villany bedobta a májkrémmel bekent macskát az éhes kutyák közé, azok meg rávetették magukat.

Ehhez a topikhoz 3-4 alkalommal akartam hozzászólni, de mindig meggondoltam magamat, mert úgy éreztem, hogy inkább flame (lenne) az egész.

Nekem mondod? Finoman éppen arra utaltam, hogy mi a fenét keres a HUP-on a Power Shell, s miért trollkodnak egyre többet itt windows-os arcok, akiknek sok vonatkozásban még csak igazuk sincs, csak a hangulatot szítják?

Tény, hogy ígyjárás, lehet, treynek kellene szétcsapni köztük.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

"Finoman éppen arra utaltam, hogy mi a fenét keres a HUP-on a Power Shell"

Megoldásától függetlenül a PS puszta léte ékes bizonyítéka annak, hogy a wines táboron belül sem tud vagy akar mindenki minden apró hülyeséget vagy minden iteratív terjengősséget az egérhez kötve megoldani - és hogy ez a résztábor korábban a jellemzően nix-ből kölcsönzött és jellemzően GPL-es cuccok nélkül vastagon magán érezhette a M$ áldását.

A szöveges adatfolyamok ide-oda pipe-olgatása és feldolgozása olyan szinten ineffektív hogy az ilyen megoldásokat illik elvi alapon elutasítani.

Egyébként szerintem a Unix "filozófia" is egy nagy baromság: "Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."

"olyan szinten ineffektív"

Attól függ milyen szempontból. A streamelgetés pl. memóriaszempontból nagyon is előnyös: több száz gigabájtos adatokat kezelhetsz tökéletesen ugyanazzal a kóddal és mentalitással mint a pár soros szövegeket

Bevallom nem értek igazából a PS-hez, de pl. látatlanba lefogadom, hogy még olyan alapvető memória takarékos algoritmusokhoz mint mondjuk egy egyszerű disk-en rendezés is meg kell izzadni...

szerk: kihagytam az automatikus párhuzamosíthatóságot: szóval mivel ez a pipeolás egy elég egyszerű dataflow programozásra hajazó megoldás, ezért elég jól párhuzamosítható mindenféle külső programozói ráhatás nélkül (nemtom persze a PS mennyire párhuzamosít automatikusan, tényleg mennyire?)

Nahát... mit látok a link közepén: közönséges XML-t... :)

Azt tudtuk már, hogy az XML encoding az ASN.1 szabvány része, ahogy azt is tudtuk, hogy mi előnye és hátránya van az egyéb szerializációs megoldásokkal szemben. Persze megértem, ha személyes ellenérzésed van az XML-el szemben, de attól az XML még létezik, széles és egyre szélesebb körben használják, és mint magadnak bizonyítottad: része az adatkommunikációs szabványoknak. Szóval?
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Hat persze hogy tudtad, azert volt a leghalvanyabb fogalmad sem mirol beszelek es kerdeztel ra 2x. Annyira tudtad, hogy mar fel sem merul benned hogy mast is lehet protokoll leirasra hasznalni mint XML. Az XML encoding btw utolag kerult az ASN.1-be (de nyilvan ezt is tudod) pont az elterjedtsege miatt. Semmi gond. En sem ismerek minden technologiat es ezt nem beszolasnak mondom.

Attol hogy elterjedt, lehet foshalom. Az hogy valamit konnyu hackelni es emiatt gyorsan terjed valamint hogy az mennyire fos, nos, ezek fuggetlen tulajdonsagok. Ez gondolom vilagos. Csak azert kerdezem, mert a postodbol nem ez jon le: elterjedt -> sikeres -> jo -> nem lehet szar.

En ertem, hogy mast jelent szamunkra a "jo" fogalma. Nem is akarlak meggyozni a velemenyemrol (ennel sommasabbak is vannak), ez az en velemenyem. Nem kell szeretni, sot egyeterteni sem. De azert ne feledkezzunk meg a korabbi, bevalt es jol megtervezett rendszerekrol sem a nagy hype kozepen.

Attól, hogy egy kérdést felteszek, még ismerhetem a választ. :)

Bármennyire is fura dolog lehet számodra, de ismerek és használok egy csomó protokollt, mindegyiket tudom használni, akkor és arra, amikor és amire kell. Neked valamiért nem tetszik ebből a halomból az XML, de ettől még rettentő sok feladatra a lehető legjobb választás, bármennyire is szeretnéd ezt elkendőzni azzal a felkiáltással, hogy amit sok helyen használnak az csak rossz lehet. :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Na és azt tudod, hogy miért terjedt el mostanában annyira az XML, amikor már évtizedekkel ezelőtt is volt megoldás ugyanerre a problémára (lásd még: http://en.wikipedia.org/wiki/Standard_Generalized_Markup_Language )? Mert ugye nem gondolod, hogy mindenki hülye volt, és inkább újra feltalálták a spanyolviaszt, amikor ott volt a mindenre jó megoldás?

Ha-ha!! Bash mellett létezik Ruby is.
Azt is megnézném mikor fog a PS beleférni egy routerbe. Kábé soha. :P

Abban a szerencsés (?) helyzetben vagyok, hogy az elmúlt két évben rengeteg lehetőségem volt különböző Microsoft termékeket adminisztrálni Powershell segítségével. Amit mindenképpen érdemes kiemelni, hogy a Powershell NEM linuxos shell és nem is ugyanarra való.

Példa 1:

Levelezőrendszer, a DMZ-ben van egy postfix, a belső hálózaton van egy Exchange hub transport és egy mailbox szerver. A feladat a levelek életútját végigkövetni a rendszeren, kigyűjteni a logokból, hogy melyik node-ra mikor érkezett meg a levél és mikor hagyta el.

A postfix esetében a következőkkel fogsz küzdeni:

A postfix több sor logot is ír ugyanarról a levélről, és nincs összefoglaló sor. Emiatt csinálnod kell "valamit", amivel az első és az utolsó sort ID alapján összekötöd. Ez az ID nemhogy nem uniq, mégcsak nem is túl hosszú, simán lehet akár egy logfile-on belül két levélnek ugyanaz az ID-ja. Távoli logolás esetén sajnos előfordulhat, hogy előbb van a logban a "kiment a levél", mint a "bejött a levél" üzenet. Emellett a syslog formátum esetében több awk és cut kell ahhoz, hogy mindezeket ténylegesen megvalósítsd, úgyhogy túl optimálishoz közeli sem lesz a kódod.

Ezt shellben összereszelni nem túl egyszerű, én inkább neki sem állnék, írnék egy kis programot python-ban (vagy bármi másban).

Az Exchange esetében a következőkkel fogsz küzdeni:

Ööö... Hát, sokmindennel nem. get-messagetrackinglog, 2 paraméter, kész.

Példa 2:

Ugyanitt statisztikát kell készítened arról, hogy melyik rendszeren hány e-mail érkezett nem létező címzettnek.

A postfix esetében egy grep és egy wc megoldja a problémát.

Az Exchange esetében készítened kell egypár Powershell scriptet, ami:
- lekérdezi az Exchange organizációd struktúráját (hogy tudd, hogy mégis hányszor e-mailt hányszor próbálj megszámolni)
- ehhez rossz esetben kell írnod AD lekérdezéseket is
- miután megvan a struktúra, a message tracking logot kb. úgy ahogy van be kell rántanod a memóriába
- ott szűrsz így és úgy, nem is olyan egyszerű algoritmusokkal
- majd a végén kipottyan egy szám, amit még kézzel ellenőrizni sem nagyon fogsz tudni.

Nem szar ez, nem szar ez csak másra jó! :-)

Ööö... Hát, sokmindennel nem. get-messagetrackinglog, 2 paraméter, kész.

Bocsánatot kívánok, de ez nem a PowerShell erőssége, hanem ez Exchange-ből egyszerűen kinyerhető információ. Ha ilyen dolog kell és erősen kell, akkor a postfix megtanítható ilyen logolásra és akkor ugyanott vagy.

A PowerShell erősségét az támasztaná alá, ha az említett Postfix Windows-on futna, és PS-el egyszerűbben kinyerhetnéd az információt, mint Unix alap parancsok segítségével - de ugye ez nem igaz, lásd a második példád.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Mert? Szerintem van mar olyan tool a piacon, ami kivant formaban dumpolja neked az eventlog es/vagy az IIS log megfelelo reszet. Onnantol azt csinalsz, amit szeretnel az Exchange logjaval.
De ha nem, akkor se tart tul sokbol osszeutni egy ilyen toolt.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

"Once we were talking to a Unix programmer about how nice it would be to have a utility that could examine a program and then answer questions such as: “What functions call function foo?” or “Which functions modify the global variable bar?” He agreed that it would be useful and then observed that, “You could write a program like that.”

:)

Mondjuk Exchange esetében:

Get-MailboxServer |Set-MailboxServer -SubmissionServerOverrideList hub1,hub2

Úgy működik, hogy a Get-MailboxServer visszaad egy listát, amelyben mailbox szervereket reprezentáló objektumok vannak. Ezeket az objektumokat egyesével átadjuk a Set-MailboxServer parancsnak, aholis a kapcsolóval beállítjuk, hogy a megfelelő hub transport szervereket értesítsék ezek a mailbox szerverek levélküldés esetén arról, hogy helló, itt a levél. Mint a relayhost, csak pepitában.

Mondjuk postfix esetében:

sed -i 's/^\ *relayhost.*/relayhost=relay/' /etc/postfix/main.cf

Ez meg úgy működik, hogy a postfix konfigjában szereplő, relayhost-tal kezdődő sorokat kicseréli másra.

Szerintem nagyjából azonos kaliberű a két parancs. Ami viszont eltérő:

- powershell esetén lényegében az összes átkonfigurálás tök hasonló szintaktikájú lesz - bash esetében pedig pl. egy eximet jelentősen máshogy kellene konfigurálni

- a bash-es megoldás sokkal inkább error-prone, a regexp, amit írtam nem is biztos, hogy minden esetre jó - a powershell esetében ilyen nyűg nem fordul elő

- hogy szidjam egy kicsit a powershell-t is: néha (sokszor) túl okos próbál lenni, és pl. quotaállításkor nem igazán egyértelmű, hogy a 28 az most 28 kilobyte-ot, vagy 28 megabyte-ot is jelent (ráadásul olyan is van, hogy más mértékegységben gondolkodik a GUI és másban a PS...) - ezzel jópárszor megszívatott, és linuxon nem jellemző ez a hülyeség

Nem jobb egyik sem, mint a másik - csak más...

powershell esetén lényegében az összes átkonfigurálás tök hasonló szintaktikájú lesz - bash esetében pedig pl. egy eximet jelentősen máshogy kellene konfigurálni

Pontosabban: Powershell és Exchange esetében az átkonfigurálás hasonló, ahogy Bash és Postfix esetében is. Az már érdekesebb kérdés, hogy miként konfigurálsz Exchange-et Bashból vagy Postfixet vagy Eximet Powershellből! :-)

Ave, Saabi.

Igen, az interpreter jellegű MSIL emittálás és futtatás jól hangzik :-)

Mindazonáltal azért örülnék, ha powershellből nem lehetne pl webszervert indítani pusztán azzal, hogy bepipeolom a forráskódot... érted :-)
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Erről is csak álmodhat a bash:


1
switch ($null) { "valami" { "ide nem" } default {"de ide igen"} }
2
switch ( (ls | gm semmi) ) { "valami" { "ide nem" } default {"es akkor ide miert nem?"} }

(ls | gm semmi) -eq $null

Eredmény:


1
de ide igen
2
True

Amennyiben Gabucino úgy véli, hogy ezen hozzászólásommal is ki kell egészítse a mémtárát, külön megkérem tisztelettel, hogy magyarázatot is fűzzön hozzá (nem a listázáshoz, az az ő dolga: a problémához).
Köszönöm!

És még egy

"'The provider does not support the use of credentials. Please perform the operation again without specifying credentials.'

The documentation states that you can provide a PSCredential object but if you look closer the cmdlet does not support this yet. Maybe in the next version I guess.

...

There's an open bug for this: connect.microsoft.com/feedback/… – halr9000 Nov 20 '08 at 21:21

Actually, I think the cmdlet supports it just fine - it's the underlying PSDrive provider that isn't doing anything with it. All the *-Item cmdlets have a generic set of behaviors; they just pass them through to the PSDrive provider, though. -filter is another example. – Don Jones Nov 29 '08 at 17:22

Looking at the docs, you'll notice that it says the parameter is not implemented for the cmdlet. technet.microsoft.com/en-us/library/bb978543.aspx – Scott Saad Nov 30 '08 at 16:01"

B+, azóta eltelt 2.5 év, de az elkúrástól számítva kétszer annyi.

Hát mi a franc volna természetesebb egy wines környezetben, mint a map, felhasználóval, jelszóval?

Szóval picit kevesebb ojjektumorientáltság több működőképességgel jobban meghálálná magát.

... és én nem a juszt is ellenzők közé tartozom...

... és még nincs vége.

Aszondja, ez bugos, hanszáljam a mapnetworkdrive-ot. Legyen...


$net.MapNetworkDrive( "Z:", $SHARE, $false, $id, $pw)
Exception calling "MapNetworkDrive" with "2" argument(s): "The local device name is already in use.

Igaza van, a Z:-t már foglalja ugyanaz a share.
Vallassuk tovább!


get-psdrive z
Get-PSDrive : Cannot find drive. A drive with the name 'z' does not exist.

Szóval még sincs, illetve...


PS C:\Documents and Settings\sgombai\dbmaint\backup> get-psdrive

Name Used (GB) Free (GB) Provider Root CurrentLocation
---- --------- --------- -------- ---- ---------------
Alias Alias
...
Z .14 .61 FileSystem Z:\

... mégis, azaz...


dir z:
Get-ChildItem : Cannot find drive. A drive with the name 'z' does not exist.

... mégsem.

Vitathatatlan, bash-sel a kézben ilyet se csinálok... be biztosan bennem van a hiba.

hello,

Ma egy Win7/Linux dual boot-osítás során szükség lett volna a parancssorba clipboard-ból beilleszteni valamit, persze sem ctrlV sem shiftIns nem működött. Nosza, gondoltam annyi szépet hallottam a powershell-ről, abban talán már megoldották ezt a kemény feladatot. Hát nem! Ott sem működik.

Közben a bcdedit-et kellett volna használni, de azt a powershellből nem lehet elindítani!

Gondolom, biztos van olyan registry beállítás ami ezeket esetleg tudatja vele, de alapból ezt tapasztaltam. A címre reagálva, még szerencse, hogy a bash csak álmodhat erről, de szerintem azt sem...

> És mi is nem működött rajta?
cmd parancssorban ctrlV ill. shiftIns hatasara nem kerul be a clipboard tartalma a parancssorba. Bal felso sarokba menu-belillesztes hatasara bekerul.

> A te hiányzó tudásodért nem a Powershell (vagy az NT Shell) a hibás.......
Biztos hiányos tudású egységsugarú user vagyok, de azt hittem, hogy a clipboard mindenhol használható billentyűkombinációval, de nem.

Tehát _nem_ az volt a bajom, hogy bal felső menüből nem működik, hanem, hogy billentyűkombinációval nem. Ha annyira csilivili és felhasználóbarát, akkor úgy gondolnám, hogy ez minimum igény lenne.

Nem akarnám emlegetni az "egyáltalán nem felhasználóbarát" Linux-os KDE-t, ahol nemhogy működik, de még queue is a clipboard.

A powershell ugyanolyan "konzolablakban" fut mint a sima NT Shell, tehát ne csodálkozz, hogy ugyanazt tudja.

Ez körülbelül a fapados xtermnek felel meg, funkcionalitása is kb annyi. Ha felteszel mást (pl. Console), ahogy Linuxon is feltetted a KDE konsole-t, akkor megkapod a hőn áhított funkciókat.

Jo sokminden eloferdult itt, de erdekes hogy senki nem emlegeti a jo oreg wsh-t :). Na abban aztan lehetett mindnefelet ganytelepelni:) Es altalaban a szukseges holmik is fel voltak teve egy alap win installra, es mondjuk pottynet sem kellett hozza, ha vkit az aggaszt.