A cURL szerzője szerint a wget és curl aliasoknak nincs helyük a PowerShell-ben

Nem sokkal azután, hogy a Microsoft bejelentette, nyílt forrásúvá tette a PowerShell-t, parázs vita alakult ki a PowerShell fejlesztői csapat és a közösség néhány tagja közt. A vita a PowerShell-ben található wget és curl aliasok körül robbant ki. Egyesek szerint azok léte zavaró, mert nem az ismert wget és curl segédprogramok funkcionalitását adják vissza.

A cURL szerzője, Daniel Stenberg (nicknevén "bagder") egy pull request-et küldött be, amelyben azt írta, hogy a szóban forgó aliasokat el kellene távolítani a PowerShell-ből:

They block use of the commonly used command line tools without providing even an attempt to offer the same functionality. They serve no purpose for PowerShell users but cause confusion and problems to existing curl and wget users.

A kérésre reagált a PowerShell csapat egyik tagja, aki visszautasította azt, mondván, az aliasok eltávolítása (funkcionalitásbeli) törést okozó változtatás lenne. A PowerShell csapat problémája az eltávolítással az, hogy a felhasználók már minden bizonnyal rendelkeznek olyan scriptekkel, amelyekben ezeket az aliasokat használják, és ha egyszerűen eltávolítanák ezeket az aliasok, akkor ezek a már meglevő scriptek nem működnének a továbbiakban. A PowerShell csapat szerint az aliasok eltávolítására irányuló kérésnek egy közösségi RFC folyamaton keresztül kellene végigmennie.

A vita itt olvasható.

Hozzászólások

This was a problem already from the day they added these aliases. On Windows. Many years ago. This was just the first opportunity I had to actually try to do something about it.

curl has always worked fine on windows and did so many years before PowerShell even existed.

[...]


This thread shows that Microsoft is dysfunctional.

Whether Powershell was intended to be released for Linux is irrelevant, you do not create programs which intentionally have the same names as well known programs, especially when your programs do not provide exactly the same functionality as the originals. There is no way to view that sort of behavior in a positive light.

Further, the bureaucracy that makes this a lengthy conversation instead of a simple "oops, you're right, let us fix that today" is laughable. "corporate governance" and whatever, good sense has gone out the window.

That is the reason the Microsoft product empire is suffering. The competition does not suffer from these dysfunctions.

--
trey @ gépház

Hosszú az út, míg a Microsoft az opensource-hoz ér... :)

Üdv,
Marci

Oh, van egy ennél sokkal 1xűbb megoldás.
Nem kell PowerShell-t *nix (like) OS-re telepíteni.

eddig azt hittem hogy egy program neve, címe, megnevezése ugyanolyan szerzői jog alá esik, mint maga a program.

amikor az ms-t ér valami hasonló sérelem, akkor irgumburgum, azonnal most, és rögtön, különbem...
és még jó ha nem ügyvédi felszólítással ügyidőben kapod kézhez..

most meg? há' majd megvizsgáljuk a dolgot, és még a közösség, meg a scriptek..

meg mi mi az anyád pi.....

Anno a Windows Commander azért lett átnevezve Total Commanderre, mert többen azt hitték, hogy a Windows része és az MS pert lebegtetett a jogtalan névhasználat miatt.

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

eddig azt hittem hogy egy program neve, címe, megnevezése ugyanolyan szerzői jog alá esik, mint maga a program.

Még csak az hiányozna...

amikor az ms-t ér valami hasonló sérelem, akkor irgumburgum, azonnal most, és rögtön, különbem...

Ugye vágod hogy különbség van egy egyszerű név és egy bejegyzett védjegy között? Ha fenti példák az utóbbi kategóriába esnének, a MS biztos nem használta volna őket.

  • 1. ugye vágod hogy a wget nem olyan mint a dir, v. az ls, mert a wget nem természetes neve a funkciónak.
  • 2. a windowsban használt legtöbb, ha nem mindegyik funkciónév eleve lopott, mert azok mind a unixból jönnek - mivel eredetileg csak az az egy oprendszer létezett - és amikor a dos-t megvette az ms /gates/ valami mukitól $50-$200 körüli áron, hogy ne bukják el az ibm-es szerződést, akkor már mind benne volt :))
  • 3 a wget előbb lett létező parancs..

és ugye vágod hogy szó sincs itt semmiféle védjegyről. szerzői jogról, elsőbbségről van szó.

ha már össze lehet veszni az app/application app-store elsőbbségéről..

"mind a unixból jönnek - mivel eredetileg csak az az egy oprendszer létezett"

https://en.wikipedia.org/wiki/Timeline_of_operating_systems
különös tekintettel: DIR. Ősi Unix parancs.

"amikor a dos-t megvette az ms /gates/ valami mukitól $50-$200 körüli áron"

https://en.wikipedia.org/wiki/Seattle_Computer_Products

Üdv,
Marci

A félreértés elkerülése végett: én azt gondolom, hogy a Microsoft hibázott ezen aliasok létrehozásával a Windows-os PowerShell-ben anno. Nem csak azért, mert evvel "eltakarta" az esetlegesen már telepített segédprogramokat, hanem, mert nem azt a funkcionalitást implementálta pontosan, mint a nevezett programok.
Ezzel több problémát hozott létre semmint megoldott.

Azóta ez a termék nyílt forrású szabad szoftver lett, multiplatform támogatással és közösségi felügyelettel.
Számomra egyértelműen látszik a nyitottság a probléma elismerésével és a megoldásra való szándék kinyilvánításával (lásd Jeffrey idézett hozzászólását.)

Az is látszik, hogy a megoldásba immár a közösséget is be kívánják vonni, ahelyett, hogy gyorsan lépnének valamit.

Az is látszik, hogy a folyamatok és eljárások még nem olyan rugalmasak és főként nem olyan gyorsak, mint más szabadszoftveres projekteknél.
Erre mondtam, hogy ez egy hosszú út a Microsoftnak. Aki elégedetlen a tempóval, az gondoljon abba bele, hogy egy 2016. augusztusi 32-bites Windows 10-en jó eséllyel vidáman fut egy 1993-ban, Windows 3.1-re kifejlesztett szoftver.
Ebből a perspektívából szerintem sokkal érthetőbb a "breaking change"-hez való óvatos hozzáállás...

Fentiek a magánvéleményemet képezik.

Üdv,
Marci
A Microsoftnál dolgozom.

Aki elégedetlen a tempóval, az gondoljon abba bele, hogy egy 2016. augusztusi 32-bites Windows 10-en jó eséllyel vidáman fut egy 1993-ban, Windows 3.1-re kifejlesztett szoftver.

ez most vicc akart lenni? Mert aligha ertekelheto maskent az, hogy egy 26 eves cuccnak (ami boven kimeriti az abandonware fogalmat) win10-en futasa barmi mellett pozitivumkent allithato...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

"ez most vicc akart lenni? "

Példa volt arra, hogy a Microsoft nemegyszer meglehetősen komolyan veszi a visszafelé kompatibilitást.
Az abandonware pedig nem azon múlik, hogy egy szoftver hány éves. Például az 1991. novemberében megjelent 5.5-2-es VMS-re még most is van support. Innen nézve a példám nem annyira földtől elrugaszkodott, szerintem.

Üdv,
Marci

Na akkor nézzük, mit lehet és mit nem. :)

-Telepítettem egy 32-bites Windows 10 Enterprise Anniversary Update-et egy virtuális gépbe.
-Engedélyeztem a Windows Features-ben a Legacy Components alatt az NTVDM támogatást, reboot.
-Telepítettem rá egy Word 6.0 for DOS-t.
-Megnyitottam a TRUETYPE.DOC-ot Word 6-tal, kicsit átszerkesztettem, elmentettem HUP.DOC néven Word formátumban. Ezt nem sikerült modern Wordből megnyitni.
-Megnyitottam a HUP.DOC-ot Word 6-tal, elmentettem HUP2.DOC néven Word for Win v2 formátumban.
-A Word 2016 Trust Centerben a File Block Settings alatt megszüntettem a régi formátumok megnyitásának tiltását.
-A HUP2.DOC-ot duplakattra a Word 2016 megnyitotta, formátumhelyesen. Kicsit átszerkesztettem, elmentettem Word 97-2003 formátumban HUP3.DOC névre. Ezt nem sikerült Word 6-tal megnyitni.
-Word 2016-ban elmentettem HUP3.RTF névre
-Word 6-tal megnyitottam a HUP3.RTF-et, kiválasztottam a stíluslapot hozzá, átszerkesztettem, elmentettem HUP4.DOC néven a fenti formátumban.
-Word 2016-tal megnyitottam, beleírtam, elmentettem HUP5.DOCX és HUP.PDF névre.

Fontos, hogy végig 32-bites Windows 10-ről beszéltem. Személy szerint azt gondolom, hogy ha valakinek ilyen erős visszafelé kompatibilitásra van szüksége, akkor ez egy vállalható kompromisszum érte.

Fentiek fényében nem látok problémát az Általad felvetett kérdésekben, ezek működnek.

És a végére egy kis személyes: a Word 6 kezelése olyan otthonos volt, mint az álom. Az összes általam használt billentyűkombináció működött vele (pl. Ctrl-F4, Alt-F-A, Alt-F4...), így még gyorsan is tudtam dolgozni vele...

Üdv,
Marci

-WinWord 2.0c-t telepítettem Windows 10-re, bejegyezte magát a Start Menübe is :)
-PRINTERS.DOC megnyitottam, beleírtam, egy Snipping Tool-lal készült képkivágást vágólapról beszúrtam.
-Elmentettem saját formátumában.
-Megnyitottam az ingyenes Word Online-nal és online kinyomtattam PDF-be.
-Word 2016 is szépen kezelte.

Természetesen csodák továbbra sincsenek. Ha valakinek van egy doksija, ami régebben szétesett későbbi verzióban valamiért az jó eséllyel így is széteshet.

Üdv,
Marci

Például mert nem vagyok most end user, hanem alkalmazott. Mert nem vettem meg a software licencét, hanem letöltöttem azt az erre szolgáló belső site-ról. Amúgy meg a vonatkozó idézet - értelmezésem szerint - a termékkel anno érkezett nyomtatott anyagokra vonatkozik. De még mindig nem vagyok ügyvéd - legfeljebb a mókusok közé vetnek érte :)

Üdv,
Marci

ugyan, csak a szokasosat :P

btw itt jegyeznem meg, hogy bar az MS legtobb termekevel nem vagyok elegedett, de az mindenkeppen jolesik hogy VMS-en edzodott trollt kuld a HUP-ra szorakoztatni, mert ez egyreszt egy figyelmes gesztus, masreszt emlekeztet arra, hogy ideje lenne mar szereznem egy alpha hobbyist licenszet meg hozza egy hardvert

"-WinWord 2.0c-t telepítettem Windows 10-re, bejegyezte magát a Start Menübe is :)"

az olyan. sot meg a windows konyvtarba is szeret pakolni egy-ket dll -t es hasonlokat, nemtom a w10 ezt hogy vedi ki, de nem is erdekel; nomeg ujabb word a regi makrokat alapbol tiltja meg hasonlo restrikciok is vannak, de ha megy a 2.0, 6.0, word95 ; akkor nem kell ezekkel matekolni. az a lenyeg, ha ugyvedur eloveszi a doksijat, mert eppen fejlemeny van egy ugyben, akkor tudjuk elolvasni.

Erre mondtam, hogy ez egy hosszú út a Microsoftnak. Aki elégedetlen a tempóval, az gondoljon abba bele, hogy egy 2016. augusztusi 32-bites Windows 10-en jó eséllyel vidáman fut egy 1993-ban, Windows 3.1-re kifejlesztett szoftver.

Azt egy random mobilos böngésző is tudja, lásd pl. az archive.org szoftvergyűjteményét (emscriptennel JavaScript-re fordított DOSBox-szal, de futnak :) )

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

  1. Miért nem? "Web get", röviden wget. Mi lenne természetesebb neve a funkciónak?
  2. Függetlenül attól, hogy ez mekkora hülyeség – még ha igaz is lenne – mennyiben invalidálja, amit én írtam?
  3. És ez mit számít? Őszintén, fogalmam sincs ki alkalmazta legelőször a "dir" parancsot. De akkor is természetes neve a funkciónak.

és ugye vágod hogy szó sincs itt semmiféle védjegyről. szerzői jogról, elsőbbségről van szó.

Ebben az esetben nincs is probléma, hiszen a cURL szerzője nyilván sikerrel venne egy bírósági pert.

PS X:\> Set-Alias curl X:\MinGW\bin\curl.exe -Option AllScope
PS X:\> Get-Alias curl

CommandType Name ModuleName
----------- ---- ----------
Alias curl -> curl.exe

Ha valaki arra adja a fejét (marketingjét), hogy nyílt forrású szoftverré teszi a cuccát, akkor számítson arra, hogy a közösség tagjai ízekre szedik.

Ráadásul itt egy olyan problémát próbált megvakarni a cURL szerzője, ami nem légbőlkapott, hanem állítása szerint régóta viszket. Most volt lehetősége érdemben megoldást javasolni az orvoslására, mivel mostantól lett szabad szoftver.

Most komolyan... tényleg azt hiszi bárki, aki nem troll, hogy nincs igaza az embernek? Faszér' kell wget-nek hívni (vagy meghivatkozni) valamit, ami kurvára nem az?

--
trey @ gépház

Nyilván igaza van, ezzel együtt azt is érti az ember, hogy breaking changet nem szívesen tol le az ember az ügyfeleinek.

Mondjuk ezt egy olyan eset kapcsán, ahol eleve csak olyan fog eltörni, aki a leírt ajánlás ellenére aliast használt a scriptekben igen vicces pont annak az msnek a szájából, aki tonnaszám töri el mondjuk a webcamek drivereit, de ha ettől eltekintesz, akkor maga az érv, hogy mivel most már ilyen, ezért úgy kell vele csinálni valamit, hogy ezt megnézzük érthető, mint ahogy az is műszaki szempontból rendben van, hogy egy olyan ügyben, ami láthatólag messzebre vezet, mint ez a két alias nem kezdünk el agynélkül mergelni ilyesmit.

Ez nem változtat azon a tényen, hogy most már van egy másfajta fájdalom, és míg az egyik oldalon olyanok vannak, akik, bár morogva ugyan, de meg tudják oldani a problémát, addig máshol jó eséllyel silently eltörik valakinek az -- egyébként nyilván kóklányolt -- dolga.

És azon sem, hogy a probléma jól láthatóan szélesebb, mint ez a két alias, szóval lehet, hogy nem úgy érdemes kezelni, hogy ezt mergelik, hogy aztán majd ha hozzányúlnak mégis másképp, akkor meg hallgathassák, hogy mekkora köpönyegforgató köcsögök, hát bemergelik, aztán meg suttyomban vissza akarják tenni...

'eltörik valakinek az -- egyébként nyilván kóklányolt -- dolga'

egyenlőre a microsoft állításán/feltételezésén kívül, senki nem látott, v. mutatott fel olyat, hogy használatban lenne az említett 2 parancs bárhol is.
de ha mégis, akkor már láttuk, hogy scriptben használni aliast amúgy sem ajánlott, ill. hibásnak tekinthető.

"egyenlőre a microsoft állításán/feltételezésén kívül, senki nem látott, v. mutatott fel olyat, hogy használatban lenne az említett 2 parancs bárhol is."

ami nem jelenti azt, hogy ilyen nincs is. le is írták szépen, hogy telemetria hiányában csak tippelni lehet, és ismerve a powershell szokásos useage patternjait az, hogy nem sikerült lendületből ilyet találni a githubon, az még messze nem jelenti, hogy ilyen nincs.

" de ha mégis, akkor már láttuk, hogy scriptben használni aliast amúgy sem ajánlott, ill. hibásnak tekinthető."
Igen, és ezt sem vitatta senki (illetve, nem ajánlott, ha hibásnak tekinthető, akkor nem kellett volna hagyni) -- még külön le is írtam, hogy gányolás, ott van az idézetedben -- ezzel együtt az van, hogy az ügyfeleket, akiknek emiatt behal mondjuk valami mentésük, ez kurvára nem fogja meghatni. Tudom, hogy a szokásos openszósz huszár szemlélettel ezt nehéz megérteni, mert ott meg lehet vonni a vállad, hogy ha nem tetszik, csináld jobban, de ez a pénzes biznisz már csak ilyen, mindeni igyekszik lehetőleg nem kikúrni az ügyfeleivel (vagy legalábbis nem lar pur lart, hanem valami érdekből, és akkor ált nem ilyen apróságokkal, hehe). És figyelj, nem állítottam, hogy jobb, mindkettőnek vannak előnyei, hátrányai.

Nyilván, a kiindulási állapot egy ortónagy elbaszás. Ettől még a megoldást lehet pl gondolkozva is csinálni, nem esetleg lendületből csinálni egy másikat faszságot, mert a slepp -- akiken egyébként tisztán látszik, hogy nagyrészük úgyse használ pst -- nekiállt fröcsögni egy ticketben. Eléggé igaza van a faszinak, aki azt írta, hogy tekintve, hogy ez 7 éve szar, és nem dőlt össze a világ, senkinek nem lesz baja, ha nem most azonnal csinálnak valamit.

Kivéve persze, ha ez az egész nem két szájbarakott aliasról szól, hanem egy teszt, hogy a Microsoft mennyire akarta valóban ezt az open source-osdit. Ha pedig itt a céges szemlélet az, amit tovább akarnak erőltetni, akkor pedig tök felesleges volt forrást nyitni.

--
trey @ gépház

Nem egészen értem, mihez képest kivéve, de igen, ez egy érdekes kérdés, hogy hogyan lehet a kettőt összeegyeztetni, mert azért lássuk be, a céges szemléletnek is vannak előnye (pl. hogy nem kúrunk el dolgokat, bár ez a mostani mst nézve tényleg vicces, dehát nagy cég ez is, lehet, hogy a ps-es srácoknak kicsit jobban földig ér a két lába)

Mondjuk azt meg tudom érteni, hogy egy ilyen izénél kicsit normálisabb döntési mechanizmust szeretnének, mert a linkelt ticket, vagy mi ékes példája annak, hogy mi szokott rettenes lenni a külső bugzillákban. Bazmeg, még félúton se jártam, már gnome vs kde flame volt benne, meg egy rakás istenverte szabadságharoc bohóc, aki ugyan sose használt pst, meg soha nem is fog, de nagy arccal előadni, hogy ki kell venni most azonnal, mocskosms, az megy.

Illetve egyelőre nem látom, hogy ez annyira messze állna az opensourcetól. A kétféle tipikus modell közül először megpróbálták az elsőt (fuck of, jó ez így mert én azt mondom), csak pechére a srácnak nem volt meg az, ami miatt egy ilyennel linust, poetteringet vagy mondjuk teot nem szedik szét egy ilyen godlike kinyilatkoztatás után. Szét is szedték. :)

A másik meg a debian féle, és hát ... szóval az nem gyors. A srácok még a kanyarban sincsenek mondjuk ahhoz az ámokfutáshoz, amit a meritrokrácia nevében az urak mondjuk a systemd kapcsán rendeztek. (És ami egyébként minden hibája ellenére a zaj leszűrése után láthatólag ott is oda vezetett, hogy a project jobban értette, hogy milyen implikációi vannak a dolognak, és összességében valószínű jobban csinálták, mintha csak kicserélte volna a systemds brancs a dolgokat). Szóval még nem temetném, nem tűnik ördögtől valónak, hogy ezeket egy moderált körben döntsék el, kérdés, hogy meg tudják-e oldani, hogy az értelmesebb külsős ebbe bevonódjon.

hogy nem tudom, hogy jön ez most ehhez a topichoz, uh nem egészen értem, mire vagy kíváncsi.

(Illetver azt, hogy még a pull request is a win powershellre jött, mert a curlos faszit az zavarta, uh ha valakit más zavar, akkor küldjön arra prt, vagy nyisson issuet, vagy kontributáljon majd érdemben ahhoz a megbeszéléshez, ahol ezt rendesen körbejárják, és kiderül, hogy igazából ez nem csak a windowsost érinti -- oh wait olyan nem is kell ugye :) )

Így indul az oldal:

"Welcome to the PowerShell GitHub Community! PowerShell is a cross-platform (Windows, Linux, and OS X) automation and configuration tool/framework"

Na most, ha ezt keresztplatformosnak lengetik, akkor tényleg az a fő indok, hogy mi/lesz van Windowson? Hol van itt az egyenlőség?

Egy elbaszott döntésből kifolyólag bekerült funkciót használó hülyék szkripje nem fog működni. OMG.

Ott tartunk, hogy a W10 kékhalálozik egy Kindle-től, a webkamerák nem mennek, a PowerShell egy frissítés miatt félig nyomorék és bizonyos esetekben a gép rommá fagy.

Nem beszélve arról, hogy a Windows 10 úgy tünteti el kedve szerint a telepített programokat a felhasználó gépéről, mintha azok ott sem lettek volna.

És akkor jönnek azzal, hogy "jáááj, de há' a script nem fog működni".

Nem csoda, hogy ez a válasz inkább egy elefántcsont toronyból leugatásnak tűnt, mintsem értelmes, megfontolt válasznak.

--
trey @ gépház

"Na most, ha ezt keresztplatformosnak lengetik, akkor tényleg az a fő indok, hogy mi/lesz van Windowson? Hol van itt az egyenlőség? "

Egy windows specifikus problémáról beszélnek, ha jól értem, a linuxoson mintha eleve ott se lennének... Maga a reporter tette ezt, mi a francért kéne egy issue ticketben másról beszélni. Nem egy fórum, hanem egy konkrét pull request.

"[hosszu stuff] És akkor jönnek azzal, hogy >>jáááj, de há' a script nem fog működni<<. "

Igen, mint mondtam is vicces ez annak az msnek a szájából, aki egyébként ebben az ügyben ordasnagy elkúrásokat tesz mostanság. A másik oldalról nézve, ha a te céged ordas nagy elkúrásokat csinálna, akkor te is szarnál bele, vagy próbálnád mégiscsak tartani magad az általad fontosnak tartott műszaki normákhoz?

én itt a ragaszkodást egy dologhoz látom: hogy járjuk körül a témát normálisan (és hiányolom is onnan az itten van az a fasz-se-tudja-minek-nevezett request, ami processzeink szerint ilyenkor kell). Mint ahogy magad idézted, az ötödik bejegyzésben eljutottak odáig, hogy "we need to fix this".

Mégis mi lehet a megfejtés az alábbiakon kívül:
- eltávolítják
- nem távolítják el?

A következmények is ismertek: az első esetben ugye a nem javasolt dolgot használó hülyék ismeretlen (és valószínűleg elhanyagolható) számú cucca el fog törni, a második esetben szájba sz*rják a so called közösséget.

Mit kell ezen körbejárni, pláne rendesen? Itt nincs fájdalommentes megoldás, nincs olyan hogy a kecske is jóllakik és a káposzta is megmarad. Itt hozni kell egy politikai döntést a ms megfelelő vezetői szintjén, aztán beleállni és vállalni a következményeket. Ennyi.

és pontosan mit kell eltávolítani, csak ezt a kettőt, vagy a többit is? És az interaktívból is ki akarod dobni, vagy csak a scriptekből? És mindet ugyanúgy? Nem lehet, hogy van valami értelmes megoldás pl a legacy scriptek megvédésére? Milyen ütemezéssel dobják ki? Csak úgy lendületből, vagy legalább adunk valami esélyt azoknak a balfékeknek, akik ugyan hülyék voltak, és használtak aliasokat, de legalább egyébként lenne esélyük észrevenni, hogy baj van, ha szólna nekik egy release nóta, vagy mondjuk egy installer kérdés?

De persze, ez egy ennyire egyszerű kérdés.

Jelenleg erről a kettőről van szó, én interaktívból is kidobnám.
És könyörgöm: ne nevezzük már "legacy" script-nek azt, ami a ms ajánlása ellenére alias-t használ. Nem, az egy hibás script. És pont ezért tartom fölöslegesnek azt, hogy mindenféle deprecated, you're doing wrong és hasonló figyelmeztetéssel szórakozni, mert jó eséllyel hasonló hatása lenne mint annak, hogy ne használj alias-t script-ben.

ha nem látod, hogy mire akarok kilukadni vele, akkor valóban.

(őszintén szólva kicsit uncsi, hogy megpróbálom elmagyarázni, hogy miért lenne érdemes kissé árnyaltabban nézni a képet, majd jön egy nagy adag ignore, és valami egész másra terelés, nem volt kedvem még egyszer hosszan legépelni)

szori, ha kissé harshnak tűnt, a mondandó lényege az lett volna, hogy szóval véleményed szerint az a jó startégia, hogy ha valaki küld egy pull requestet, akkor az meghatározza a change scopeját, nem kell végiggondolni, hogy milyen hasonló van. Szóval a konkrét példában ha a curlra jött, az ki lesz véve, a wgetre nem, akkor az marad, és ez így jó. Horrible dictu, aztán jövőhéten meg jön valaki, hogy de nekem meg kéne vissza a curl alias, mert eltört valamit, vagy jön valaki, hogy milyen fasza lenne, ha lenne egy lftp alias az invoke-webrequestre, mert ő ahhoz van szokva, akkor azt is be kéne venni? miért olyan nagy baj az, hogy ezt valaki értelemesen együtt akarja kezelni, nem úgy, ahogy egy külsős kezéből kiesett?

Kicsit messzebbről nézve: ez az egész téma szerintem ott lett elcseszve, hogy ezeket az aliasokat berakták.

Kicsit még messzebbről: hogy enged script-ben olyan aliast, amit nem a script-ben deklarált. Mint korábban is írtam, ez baromi veszélyes. Bár igazából interaktívnál is, de ez most nem ide tartozik, mert ezzel látszólag senki se foglalkozik. Pedig ott is célszerű lenne szerintem az első használatnál feldobni egy olyat, hogy "Bélám, a dir a Remove-Item alias-a, erősítsd meg h futtatnád-e"...

És akkor maga téma: itt van egy adott pull request. Itt ez a téma, és nem az lftp. Ha nem lenne benne a wget, akkor nem lenne az se téma, hacsak, ugye. És itt ebben a konkrét esetben kell a ms-nak valami döntést hozni, kiszedik vagy nem, "C" válasz nincs, itt nem lehet maszatolni.
Az már más kérdés, hogy hogyan veszik ki (már ha kiveszik), mert előbb el kell dönteni, hogy kiveszik-e vagy nem. És ez egy politikai döntés, ahol dönteni kell a ópenszósz közösség és a compatibility között.

A "nekem meg kéne vissza a curl alias, mert eltört valamit" megoldása szerintem pedig triviális, mert a, deklaráld magadnak; vagy b, replace all.

Az ötlet elméletileg jó.
Gyakorlatilag viszont a script-ek jelentős része automatán fut, itt a warning megjelenítése problémás.
És még ha egy valós személy futtatja a script-et, akkor is mi történik a legtöbb esetben? Kiírja hogy warning, deprecated, akármi. DE! A cucc lefut, megtörténik aminek meg kell történnie, szóval ki nem ....ja le? Aztán letelik az adott idő, megváltozik a default, a cucc "hirtelen" eltörik, és majd akkor kezdődik a qvaanyázás.

Egyébként is tiltani kellene az alias-ok használatát PS script-ben, szerintem legalábbis.

- lassan távolítják el
??

Például valahányszor lefut a script, megkérdezi hogy szeretnénk-e, ha az összes curl és wget szót (amelyik a MS verziót hívná meg) kicserélje mscurl és mswget szavakra. (I/N)
+ Ugyanezt megkérdezi a VisualStudio
+ amikor az új PS verzió települ, megkérdezi hogy átírja-e a számítógépünkön található összes fájlban / általunk megadott mappában találhatókban (végrehajtva őket előtte, hogy megnézze hogy melyik curl vagy wget hajtódna végre) (I/N)

Ezzel sokakat lehet értesíteni. Persze egy csomó felügyelet nélküli szerver így is eltörik frissítéskor.

Nyilván nem fogják gyorsan eltávolítani :)

Amúgy meg igen, ez nyilván egy folyamat lesz, figyelmeztetéssel meg satöbbi. De attól még igaz amit írtam, hogy itt egy politikai döntést kell meghozni Redmondban, ami valakinek fájni fog.

És még egy dolog (itt találtam):

# dangerous! dangerous! dangerous!
Remove-Item -Path Alias:dir
Set-Alias -Name dir -Value Remove-Item

Szerintem alapvető hiba, hogy a ps engedi "külsős" alias használatát script-ben. Mert OK, lehessen belül defíniálni, ne kelljen mindig del helyett kiírni azt, hgy Remove-Item, de a külsős alias-ok használata azért eléggé veszélyes. (Linux script-eknél pedig a path machinálás lehet az, de ez más téma.)

Nagyon retardáltnak vagy nagyon nagy trollnak kell lenni ahhoz, hogy valaki ennyire látványosan ne akarja érteni, hogy egy n+sok eve létező szoftvernél, amit éppen, hogy kiadtak multiplatformra, talán a legnagyobb userbase a legrégebbinél van. És mondjuk nem biztos, hogy néhány nullkilométeres platform miatt ki kell baszni a meglévő userekkel.

Extra b9nusz, hogy ameddig két kibaszott aliasrol van szó, addig ez maximum a seggfájás kategória.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nagyon ostobának kell lenni ahhoz, hogy azt hidd, hogy nem értem, hogy mivel próbálnak takarózni. Az más kérdés, hogy röhögök rajta.

Amit elbasztak, azt illene kijavítani. Nem göngyölgetni, csak azért, mert van egy marék ostoba felhasználójuk. A bürokrácia az, amit le kéne redukálniuk. Jó, hogy nem hívatják be Satyát miatta, hogy megkérdezzék, mi a fasz legyen.

--
trey @ gépház

Azt hiszem, hogy az MS által így úgy elnevezett aliasok mibenléte kb az MS szarhalma, így neki kell helyrerakni.
Ha valaki tudatosan wget-nek hív egy parancsot, ami nem a 300 éve ezer helyen elfogadott, használt wget funkcionalitását hozza, az egy barom.
Ez ugyan annak a habitusnak a része, mint ami anno az internet előretörésével volt tapasztalható, hogy az MS elkezdte ezt az egész dolgot úgy kommunikálni, kampányolni, mintha ő találta volna fel az egészet.

Számtalan helyen tapasztalható volt, hogy meglévő megoldásokra csinált egy nyakatekert saját valamit (vagy jót, vagy szart), aztán elkezdte ezt de facto szabvánnyá erőltetni.
Elhintette csillió gépre a dolgot és utána meg arra hivatkozunk, hogy de hát csillió helyen ez így van, ezért nehézkes a változtatás, mert eltör valamit.
Akkor most ki is az űber köcsög, aki pont leszarja, hogy mi kell az ügyfeleinek?

Már rég le kellett volna húzni a klotyón az összeset. Aki meg (mindegy, hogy kényszerből, vagy önként dalolva) MS szottyerekre hagyatkozik, meg azt használ, az meg is érdemli. Hogy az ember fizessen is azért, ami nem megy, aztán még azért is fizessen, hogy egy szakértő időnként megmondja neki, hogy hülye, de megoldást a reinstallon kívül nem hoz, az komolyan megérdemli a sorsát.

A company identityvel nehezen férkőzik össze ez a opensource-ság. Egy ideig még szokniuk kell a dolgot ... :)

-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)

Ha régóta viszket, nem kellett volna korábban vakargatni? Amúgy meg a probléma megoldása sokkal kevesebb időt vesz igénybe, mint akár az ebben a fórumban olvasható szócséplés. Akit zavar az alias, kitörli vagy felüldefiniálja. Aki meg nem használja a PowerShellt, annak nem mindegy?

Ave, Saabi.

Most lett nyílt forrású, szabad szoftver. Most tudták kérni. Joggal várná el a nyílt forrású közösség, hogy ha valamit jobbá lehetne tenni és még patchet is küldenek rá, azt megvitassák, megfontolják. Ez az egész szerintem erről szól.

Szerintem te nem nagyon érted ezt az open source dolgot.

--
trey @ gépház

Oh, igen opensource vonalon már csak úgy megy, hogy pár hangos bohóc kitalál valamit, hogy nem tetszik neki és akkor az úgy is lesz.
Ezért is lett libreoffice és ezer más forkolt szar, a rohadtnagy opensource közösségi egyetértésben.
Édesjóistenem, milyen kettős mérce.

"Szerintem te nem nagyon érted ezt az open source dolgot. "

LOL.

"azt megvitassák, megfontolják. "

Egyébként nem ez zajlik?

De, ez zajlik. Köszönhetően a nyílt forrás "bohócoknak". Ha a Microsoft arrogáns bohócán múlt volna (első kommentelő), akkor itt semmilyen megvitatás nem lett volna, hanem egy "Unacceptable Changes" vagy "WONTFIX" akármivel le lett volna zárva az egész. Szerencsére vannak "bohócok", akik ezt nem hagyják és próbálják tanítani a Microsoftot arra, hogy mi az open source, ha már úgy alakult, hogy végül arra adta a fejét, hogy ehhez a közösséghez dörgölődzik (ki tudja egyébként, hogy miért...).

--
trey @ gépház

"De, ez zajlik."

Akkor min is hőbörög a sok bohóc?

"semmilyen megvitatás nem lett volna, hanem egy "Unacceptable Changes" vagy "WONTFIX" akármivel le lett volna zárva az egész. "

Oh, hát ilyen is csak egy microsoft-os opensource bugreportban van, igazad van. LOL.

"próbálják tanítani a Microsoftot arra, hogy mi az open source"

Igen, látjuk mi is az opensource a sok forkolt szar kapcsán. Marhára nem arról szól, hogy pár hangos bohóc kitalál valamit és az úgy lesz. Úgy lesz, ahogy a maintainer szeretné, hogy legyen. Ha úgy érzi, hogy nem lesz belőle breaking change, mert fontosabb a visszafelé kompatibilitás, akkor nem lesz, bármennyit is pörögnek a hátukon a bohócok. Ha nem tetszik, lehet forkolni. Erről szól az opensource, mint azt oly sok példán láttuk már.

Nem vagyok egészen biztos benne, de ha jól látom, a szál időrendi sorrendben van, akkor pedig azért az előrehaladás kb az volt hogy

- open
- msbohóc wontfix close
- badger újranyitja
- ms2 ember mondja, hogy nem akarjáj nem megjavítani, csak át kéne gondolniuk
- ms3 ember mondja, amit linkeltél

és ez az első 5 comment, az egész szardobálós szál ezután kezdődik. Szóval jött a külsős ember, nyitott egy requestet, valami fasz lezárta, azt a többiek a színfalak mögött nyilván tarkónbaszták, és azonnal közölték, hogy hadd nézzük át rendesen a problémát, mert értjük, hogy need to fix this. Szóval én a nagy hozzáadott értékét nem látom a sok élharcosnak, a valódi érintettel viszonylag gyorsan eljutott az ügy idáig.

Ahogy az egyik hozzászóló is írta a pull request alatt, scriptben nem használunk aliast. Az alias interaktív használatra lett kitalálva.

Ave, Saabi.

Workaround megoldás lehetne, hogy ha úgy módosítanák a powershell-ben a wget és curl működését, hogy ha a Path-on talál ilyen binárisokat, akkor használja azokat, amúgy meg egy warning keretében működjön a régi alias. Nem a legjobb, de legalább valami :)

"A PowerShell csapat problémája az eltávolítással az, hogy a felhasználók már minden bizonnyal rendelkeznek olyan scriptekkel, amelyekben ezeket az aliasokat használják, és ha egyszerűen eltávolítanák ezeket az aliasok, akkor ezek a már meglevő scriptek nem működnének a továbbiakban."

Ez ugye ugyanaz az MS, aki "removes policies fom Windows 10 Pro"? http://hup.hu/node/148679

en gelei magyarazkodasat varva subs-olom...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Szerintem az volt az elgondolás mögötte, hogy az emberek megszoknak toolokat, és ha valaki leül a PS elé, a curl-szerű funkcionalitáshoz az első próbálkozása reflexből is a curl lesz. Én rendszeresen 'dir'-t használok 'ls' helyett linuxon, már csak megszokásból is. Ráadásul a 'dir' nem az 'ls' aliasa, és még csak nem is pont ugyanúgy működik, mint Windows alatt.

Hogy ez mennyire szerencsés, arról már inkább lehet vitatkozni, mindenesetre aki az igazi curl-t akarja használni, az elég könnyen fel tudja oldani a problémát.

Az könnyen lehet, hogy hiba volt, viszont abban is van igazság, amit "az a nyikhaj" mondott. Globálisan kiszedni az aliasokat eltörné egy csomó ember szkriptjét -- tudjuk, tudjuk, aliast tenni a szkriptbe nem good practice, de akkor is előfordul.

Az viszont butaság, amit többen is írnak, hogy emiatt "nem lehet" az igazi curl-t használni. De lehet. Olyannyira lehet, hogy tetszőlegesen törölhetsz és létrehozhatsz aliasokat user, session, és emlékeim szerint script szinten is. Sőt, azt is megteheted, hogy a curl.exe-re mutasson a 'curl' alias. Vagy bármi.

A kérdés itt az, hogy hogyan tovább, ugyanis jelenleg egyik felmerült megoldás sem optimális.

Megszokott tool-ok, OK, de akkor is: miért így?

Foghatták volna a wget és curl forrását, lefordítják windows-ra és terjesztik a ps-sel.
Csinálhattak volna olyan "saját" curl és wget parancsot, ami paraméter és feature szinten kompatibilis a létező wget és curl programokkal.
Vagy csinálhattal volna pl. pscurl és pswget (vagy curlps és wgetps) alias-t, ami részleges curl és wget funkcionalitást nyújt ps-ben.

A fentiek bármelyike jó megoldás lett volna. De ők inkább egy rosszat választottak...

Fú, ezzel mennyit szívtam egy éve... De legalább tudom most már az okát.

Persze ez még véletlenül sem olyan, mint amikor egy török programozótól elvesznek egy 'kik' nevű projektet (illetve a nevét), mert hogy az trademark... Illetve pont olyan, csak itt a MS nem volt jóhiszemű és nem lesz semmi baja az ügyből.

A busybox ugyanigy tartalmaz egy csomo beepitett aliast. Azert nem sirnak a fejlesztok?

Idegesito, persze, de van annak elonye, hogy bizonyos alapfunkciok hasznalatahoz nem kell magat a toolt telepiteni.

Nem látok se curl, se wget "alias"-t a busybox-ban, így érthető hpgy badger erre nem küldött pull request-et :)

Persze értem amit írsz, de a busybox definíció szerint a gnu userland csökkentett funkcionalitású, méretre optimákolt változata a kis teljesítményű eszközökre. Ellentétben ugye a sokszáz megás ps-sel.
Szóval ha valaki busybox-ot használ, akkor tudja hogy mire számíthat (limitált funkcionalitás), míg ha egy általános célú scriptnyelvben curl-t hív, akkor a curl funkcionalitására számít.

My 2 cents...

Az egy elhibázott döntés volt, hogy a PowerShell default aliasok scriptekben is működnek, szerintem már az első verzióban is olyan viselkedést kellett volna implementálni, hogy az interaktív használatra szánt aliasok csak interaktív PowerShell környezetben érhetőek el alapértelmezés szerint. Aki pedig explicit bekapcsolja ezeket az aliasokat scriptekben, az minimum kapjon egy warningot, hogy így nem lesz hordozható a scriptje.

Ugyanakkor nem gondolom, hogy ezek az aliasok eredendően rosszak lennének, UNIX shellek is gyakran implementálnak egyes parancsokat builtinként, adott esetben eltérő feature-settel, mint a külső parancsként elérhető változat. Ettől még meg lehet hívni a külső parancsokat, ugyanez igaz PowerShellben is.

Én abban nem látok semmi kivetni valót, ha egy adott környezetben egy adott néven elérhető parancs/függvény/metódus/whatever más opciókat ad, mint egy másik környezetben. Ebből a szempontból a vita engem arra emlékeztet, mintha a Ruby fejlesztők panaszkodnának, hogy milyen dolog az, hogy a JavaScript Array-nek más metódusai vannak, mint a Ruby Array-nek.

nemigazan latom at a problemat, szoval kerdeseim vannak.
- a mar megirt curl/wget hasznalo shell scriptjeim nem fognak mukodni, ha feltelepitem a powershell -t ?
- a windowsos powerhellben van wget es a curl alias ?
- hanymillio script szuletett a ps for linux megjelenese ota, amit elesben hasznalnak linuxon, es ami miatt nem lehet visszacsinalni ?
- mi a turonak telepitsek ps -t linuxra, ha hianyzik mogule a - divatos szoval - "okoszisztema", ami miatt valami ertelme is lenne ?

- a mar megirt curl/wget hasznalo shell scriptjeim nem fognak mukodni, ha feltelepitem a powershell -t ?

Nem.

- a windowsos powerhellben van wget es a curl alias ?

Van.

- hanymillio script szuletett a ps for linux megjelenese ota, amit elesben hasznalnak linuxon, es ami miatt nem lehet visszacsinalni ?

Lényegtelen, a Windowsosban régen ott van.

- mi a turonak telepitsek ps -t linuxra, ha hianyzik mogule a - divatos szoval - "okoszisztema", ami miatt valami ertelme is lenne ?

Nem hiányzik, simán hívhatsz belőle "natív" programokat, lásd pl. a fenti videót.

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

> a mar megirt curl/wget hasznalo shell scriptjeim nem fognak mukodni, ha feltelepitem a powershell -t ?

De, a PS aliasok csak PS-en belül érvényesek, de még onnan is tudsz natív curl-t hívni.

> mi a turonak telepitsek ps -t linuxra, ha hianyzik mogule a - divatos szoval - "okoszisztema", ami miatt valami ertelme is lenne ?

Egy csomó embernek nem lesz erre szüksége, másoknak igen. Azért a PowerShell nemcsak egy yet another shell akar lenni, vannak benne egész értelmes ötletek, ami miatt érdemes ránézni, aztán eldöntöd, hogy kell-e neked.

off: Régi megfigyelésem, hogy amit egyszer elcseszünk, azt nem lehet un-elcseszni, két okból sem: egyrészt az egónk nem engedi, másrészt nem tudjuk szabályozni, hogy a világon szerteszét lévő számtalan programpéldány közül hány van elcseszés előtti, hány elcseszés alatti és hány javítás utáni állapotban. Szóval a javítás igazából csak a káosz fokozása.

Kedvenc példám: PHP-ben a htmlspecialchars 'encoding' paramétere