A legutóbbi frissítés óta csak a baj van az mc-vel.
GNU Midnight Commander 4.8.32
Built with GLib 2.80.4
Built with S-Lang 2.3.3 with terminfo database
Messze nem ez az első bajom az mc-vel, az utóbbi tíz évben rohamosan romlott a minősége, de ez az első, ami vizuálisan is kifejezetten bosszantó és idegesítő. A többit nyűgjét vagy megtanultam megpatkolni minden frissítés után, vagy együttélni vele (de pl. az, hogy a fájllista és a shell munkakönyvtár meg a command history szinkronja néha elcsúszik a francba, soha nem fogom megszokni).
Másnál is előjött ez az újrarajzolási probléma? Ha igen, talált esetleg valaki már megoldást rá (azon túl, hogy lekoptatom a CTRL és L gombokat a billentyűzetemről).
ps: itt egy képernyő a hibáról. Ez még istenes, itt most épp "csak" a felső sáv meg az Fn menü mászott el, szokott ez rosszabb is lenni (az tök random, hogy mi nem frissül, legalábbis én nem találtam benne rációt még).
MEGOLDÁS: nem slang bug, nem is mc bug, hanem glib bug, beleböfög az stderr-ba egy hibaüzenetet az F4 leütésekor, emiatt esik szét az, hogy mit hisz az mc mi van a képernyőn, és mi van valójában, ez okozza.
"mc 2>/dev/null"-lal indítva a hibajelenség megszűnik.
Hozzászólások
Szerintem nem mc bug, inkább valamelyik library lesz a ludas. Fedora 41-en nem jelentkezik a probléma.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Csak az slang jöhet szóba, de az ugyanaz a verzió nálad is.
A beállításoknál nálam az "Options" > "Configuration" > "Use internal view" és "Use internal edit" be van kapcsolva, máskülönben nem adódnak át a cuccok és szopás használni (pl. ha keresek valamire, akkor listában F4-et ütve az mcedit már nem tudja, hogy mire is kerestem). Ha ez nincs bekapcsolva, akkor független processzként fut az mcedit, és ilyenkor megfelelően frissül is a képernyő, de ez nekem az előbbiek miatt nem jó.
(ps. nálam van még egy "Built with libssh2" sor és van egy "sftpfs" vfs plugin is, de ezeknek ugye semmi köze a frissítéshez, minden más pontosan ugyanaz, csak a glibc verzió más.)
Options / Display bits-el erdemes jatszani ilyenkor
nekem screenben szokott hasonlot prodkalni, de ott mar evek ota.
illetve azt is erdemes megnezni a TERM env erteke mi, foleg linuxon szeretik varialni a disztrok, es nem biztos hogy a terminfo/termcap megfelelo hozza.
Kössz a tippet, sajnos nem.
Input / display codepage: [ UTF-8 ]
[x] Full 8 bits input
Nem hiszem egyébként, hogy ez lenne a gond, sokkal inkább úgy tűnik, hogy optimalizálni próbálja a CSI szekvenciákat az mc, hogy csökkentse a terminálforgalmat, csak hát rosszul. Olyan, mintha teljes egészében kimaradnának bizonyos CSI blokkok, és nem olyan, mintha hibásak lennének (meg egyébként is CTRL+L-re jól megjelenik, szóval nem hiszem, hogy itt kódolási probléma lenne).
de TERM vs terminfo problema attol meg lehet...
Nem. (Mármint igen, elvileg lehetne, de itt most tutira nem ez a baj, mert sem a TERM értéke, sem a terminfo nem változott a frissítésnél, ráadásul termináltól függetlenül is előjön).
Egyébként TERM="rxvt-unicode-256color", TERM="st-256color", TERM="xterm-256color" és TERM="xterm" esetén is előjön a probléma, szóval másfele kell keresgélni.
> az utóbbi tíz évben rohamosan romlott a minősége
s/10/20/
mondjuk mindig idiotak fejlesztettek, egy ideig a miguel icuaza, aki mindent szetbasz amihez hozzanyul, szerencsere mostanaban a microsoftnal rombol mar. a mostani dev (Pavel) is egy idiota, anno bekuldtem vagy 20 patchet ami kulonbozo bugokat javitott (tobbek kozt a path szinkront is) vegul csak egyet rakott be, ami a kereseskori kifagyast fixalta (szarul hasznalta a select()-et).
tavaly meg egyszercsak gondolt egyet es atcserelte a hotkey-eket, en meg pislogtam hogy miert nem azt csinalja amit nyomok. kovetkezo verzioba meg sikeurlt ezt tovabb rontania, aztan a nepharag lesujtott es 3. frissitesre visszaallt az eredetire.
Húsz éve használom, de csak az utóbbi 5-10 évben kezdett el bosszantani. Korábban is voltak hülyeségei, de munkamenetet akadályozó bugjai nem. Most már vannak.
Legutóbb az volt, hogy van két zip fájlom, az egyikre Enter-t ütve megnyitja, mint egy könyvtárat, a másikra Enter-t ütve meg behozza a Firefox-ot, ami persze meg nem tud mit kezdeni vele, csak megkérdezi, hogy letöltse-e, de közben meg már másolja is a háttérben és már be is telt a tmp...
Off: régóta szeretném tudni, hogy a fraktál az a 'check' nevű komponens, amit a mc-fordítás hiányol. Van egy homályos emlékem, hogy valami multiplatformosító dolog lehet, csak nem működik Linuxtól különböző platformokon.
Aztán van ez az okosság, ez is ismerős:
Itt ugye a túl sok zárójel b@ssza fel a gcc agyát. [Szerk: most látom, hogy ez nem lekváros, hanem szándékos: így ellenőrzi, hogy a sighandler_t az változó-e vagy típus: ha változó, akkor nem baj, akárhány zárójelben is van.]
No mindegy, ha PKG_CONFIG_PATH jól áll, akkor azért valamennyire fordul.
Önmagában a mc update nem hozott ki hibát, mgpróbálom a slang-ot frissíteni. Egy fontos részlet:
Nem látok semmi különöset. Ha reprodukálható a probléma, akkor a
scriptnevű szoftvereszközzel kellene rögzíteni a hibát okozó szekvenciákat.A csatolt hibás képet a helyessel összevetve nem sok derül ki, azonban a hibás képet a sima mc (kétpaneles fájlkezelős mód) helyes képernyőjével annál inkább.
Fent, ahol világoskék csík kéne hogy legyen, ott a sima kétpaneles módban is az van, viszont egy sorral lejjebb van a sok vízszintes vonal amit az mcedit valszeg nem is kér hogy legyen. Gyanús hogy az csúszik feljebb eggyel.
Alul pont az látszik csak, ami változott. Pl. "Menu" helyett "Save", "RenMov" helyett "Move(szóköz)(szóköz)".
Tehát minden bizonnyal valami ilyesmi történik:
Amikor meghívod a beépített mcedit-et, az pontosan tudja hogy _elvileg_ mi van a képernyőn (a fő kétpaneles fájlkezelő nézetben), és kioptimalizálja a rajzolást, csak azt rajzolja újra ami változott.
Viszont a képernyőn _gyakorlatilag_ nem az van. Vagy már ott is láttál korruptálódást, ebben az esetben vissza kéne menni egy lépéssel a nyomozásban és az elsőnek fellépő hibára fókuszálni (de akkor is valószínűleg hasonló lesz a konklúzió), vagy pont az mcedit megnyitása kapcsán esik szét. Feltételezve az utóbbit: azok a szkriptek amik kiderítik a fájltípus, kiterjesztés stb. alapján hogy mi a teendő a fájllal, milyen alkalmazás hívandó meg stb., azok valamelyike okád valami hibát vagy figyelmeztetést a kimenetére, azaz a terminálra, ami hazavágja annak a tartalmát, ott innen kezdve nem az van mint amit az mc hisz és így az inkrementális képernyőfrissítés (amit nem közvetlen az mc csinál hanem a slang vagy ncurses, de ez most lényegtelen) is nyilván szar lesz.
Indíts egy `script`-et, abban játszd végig, a végén a kapott `typescript` fájlt nézd át, érzésre megtalálod hogy kábé hol indul az mcedit, arrafelé keress oda nem illő figyelmeztetéseket-hibákat, remélhetőleg a bűnös elárulja magáról hogy melyik progi is ő.
Nyilván, a kérdés az, hogy hogyan kell megjavítani, hogy helyesen optimalizáljon.
Internal edit esetén nem futnak le ilyesmik.
Internal edit esetén nem indul mcedit (mint külön processz).
Szopacs, script-el indítva nem jelentkezik a hiba. Legalábbis eddig egyszer sem jött elő.
EDIT: Viszont amikor F4-et ütök, azon a ponton van egy ilyen sor a typescript fájlban:
(mc:288988): GModule-.[1;35mCRITICAL.[0m **: .[34m23:32:44.818.[0m: g_module_close: assertion 'module != NULL' failed
Hm, ez lesz az biztosan, mert "
mc 2>/dev/null" esetén minden okés...> Nyilván, a kérdés az, hogy hogyan kell megjavítani, hogy helyesen optimalizáljon.
Mire gondolsz az alatt hogy helyes vs. helytelen optimalizálás? Ha a segge alatt, tudta nélkül megváltozhat a képernyő tartalma, akkor nyilván semmilyen optimalizálás nem tud garantálni helyes végeredményt, az egyetlen esély minden egyes alkalommal a teljes képernyőt újrarajzoltatni. Ezt tudtommal egyetlen library se csinálja (kivéve ha direkt ezt kéred, lásd Ctrl+L). Ha meg számíthat arra, hogy senki más nem piszkít bele az általa rajzoltakba, amire nyilván minden library számít, akkor fair játék békén hagyni bármit ami szándék szerint nem változik. Nem látom, hogy létezhetne bármiféle átmenet.
> Internal edit esetén nem futnak le ilyesmik.
Lehetséges. Internal view esetén vannak ilyenek, innen gondoltam hogy edit esetén is lehet hogy vannak.
> Internal edit esetén nem indul mcedit (mint külön processz).
Nem mint külön processz gondoltam, hanem a belső mcedit komponens.
>
g_module_close[...] glibc bugEz glib, nem glibc.
Valszeg az mc hibásan használja a glib-et, megérné küldeni nekik egy hibajegyet.
Nálam is ugyanazok a verziók vannak fent mc-ből. slang-ből, stb., mint a topikindítóban. st-ben és xterm-ben hibátlan az mc, nincs vele gond. Az mcedit viszont bugzik, a felső sorában fekete mezők jelennek meg, meg hiányosan írogat dolgokat oda. Nem nagy probléma, mert Vifm-et használok, mc-t csak ritkán, és akkor is neovim-mel és less-szel, így az mceditet, és az mc saját fájlnézőjét nem látom soha.
Az urxvt-t nem ajánlom, az egy bugos fos. Az uxterm-et nem ismerem. A foot, kitty, alacritty, wezterm, lxterminal, gnome-terminal, konsole az okés.
Ha st-ben gond van, akkor érdemes újrafordítani. Ezzel szívtam nemrég én is, hogy saját st buildet használok, és fagyott miatta a gép. Sokára jöttem rá, hogy ez a baj, újrabuildeltem, és azóta jó. Néha idővel elavul a bináris, ha régi függőségek ellenében volt dinamikusan linkelve fordítva, de azóta drasztikusan léptek verzióban a függőségek.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Akkor nemcsak nálam jelentkezik ez a hiba.
Ez az etalon. Ha valami nem megy xterm alatt, akkor az programhiba és nem terminal hiba. Manapság a CSI kódokat xterm-hez mérik mindenhol. (Az "u" csak annyit tesz, hogy UNICODE kompatíbilis opcióval fordított.)
Ezeket próbáltam, mind egy bloated foshalmaz, és nem tudják, ami nekem kell, helyette tudnak 100 dolgot, amire rohadtul nincs is szükségem.
A gnome-terminalt meg különösen senkinek sem ajánlom, és a konsole-t se, mert iszonyat függőségük van (több, mint fél GIGA).
Egyébként elárulok egy titkot, ezek majdnem mindegyike pontosan ugyanarra a libvte függvénykönyvtárra épül, mint az urxvt, tehát ha az urxvt bugos fos, akkor ezek is (és tényleg).
Eleve én fordítottam, de nem st bug van, hanem mc bug.
Na az st az nem libvte-s, az egyetlen bajom vele, hogy nem tudja rendesen az ablakátméretezést, egyébként mindenben megfelelne az elvárásaimnak. Néztem a kódját, hogy hozzáadom, de iszonyat csapnivaló a belső terminálábrázolása, az egészet refaktorálni kellene hozzá.
> Egyébként elárulok egy titkot, ezek majdnem mindegyike pontosan ugyanarra a libvte függvénykönyvtárra épül, mint az urxvt, tehát ha az urxvt bugos fos, akkor ezek is (és tényleg).
A korábbi felsorolásból az lxterminal és a gnome-terminal épül a libvte-re, a többi nem. Az urxvt sem.
A szubjektív részére ("bugos fos") nem reagálnék, rád hagyom, de az objektív tényeket legalább rakjuk a helyükre, köszönöm.
Igen, némelyik felsorolt terminál bloat, de akkor meg nyújt pluszt cserébe (GPU gyorsítás, képkezelés, ligatúrák, fülek, stb.), és legalább bugmentesek. Csak 1-2 épül VTE-re, nem az összes. Régen én Termite-ot használtam, de annak abbamaradt a fejlesztése. Az urxvt-vel személyesen is van rossz tapasztalatom, hogy nem jeleníti meg az összes Unicode karaktert, amit a font támogat, meg ANSI kódokat nem kezel le korrekten.
st-nél nem az a lényeg, hogy te fordítottad-e, hanem hogy mikor. Mert ha nagyon sok hónapja, és azóta rendszeresen frissült a rendszered, libek frissültek, akkor én a helyedben még egyszer újraforgatnám az st-t, változatlan kóddal, de új bináris jön létre, a mostani libekhez lesz dinamikusan linkelve, ez meg tud szüntetni fennálló bugokat. Rollingon ez nekem rendszeresen előjön, nem csak st-vel. Én st-t használok.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Persze, hogy nem csak nálad. Szerintem mindenkinél, aki újabb verziót használ. Maximum csak azokat nem érinti, akik ilyen dinoszauruszok korabeli disztrón vagy kiadáson vannak, és el vannak maradva a komponensei 2-3 verzióval.
A
2>/dev/nullformátumú átirányítás nálam is megszüntetni mcedit-ben a hibajelenséget. Jó tudni, figyelni fogok erre a jövőben, be is teszem az sxhkd konfigba, hogy ezzel indítsa az mc-t.“The world runs on Excel spreadsheets.” (Dylan Beattie)
"akik ilyen dinoszauruszok korabeli disztrón v"
mint pl. 22.04 LTS Ubuntu ?
GNU Midnight Commander 4.8.27
Nekem teljesen jó, hoyg nem szopat
http://www.micros~1
Rekurzió: lásd rekurzió.
Igen. Pontosan. Jelen esetben szerencséd volt vele. Az mc amúgy is egy old-school szoftver, nem fejlődik sokat, így nem probléma, ha le van maradva a verzióval. Egyébként sem szopatott volna meg nagyon, látod, lett rá egy soros /dev/null-os workaround, amíg nem javítják, de az is lehet, hogy ha kézileg fordítanád a mc-git-et, abban máris javítva van, csak még a legújabb kiadásba még nem került bele a javítás.
Van viszont, ahol a verziók frissessége jobban számít, pl. ha újabb szoftvereket akarsz lefordítani (pl. home brew fájlkezelők, népszerű szoftverek Rust-ban újraírt változatai), amik igénylik az újabb fordítókat, vagy libverziókat, a github, gitlab, stb. tele van ilyenekkel. Vagy pl. játékok nagyon igénylik a legújabb kernel, legújabb GPU driver/mesa, legújabb Proton, stb. csomagokat, néha ezen múlik, hogy elindulnak-e, vagy játszhatóak-e. Illetve aki nagy waylandes, és valami nagyon modern waylandes felületet akar használni, pl. KDE6 vagy Hyperland, náluk is elég fontos, verzióról verzióra kerülnek bele a feautre-ök, bugjavítások. A negyedik esetkör, amikor valaki nagyon új gépet, hardvert vesz, pl. pár hete, hónapja kijött legújabb GPU, CPU, chipset, stb..
Másik részről ami megmenti a dinoszauruszos disztrókat mostanában, az a Snap, Flatpak, Appimage, abban elérhetők általában az újabb verziókk és nem gond, ha régi rendszer van alatta, mert úgyis a saját függőségeivel együtt konténerizálva jönnek ezek.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Köszönöm mindenkinek a segítséget!
A megoldás nem slang bug, nem is mc bug, hanem glibc bug, beleokád az stderr-ba egy hibaüzenetet, emiatt esik szét az, hogy mit hisz az mc a képernyőn és mi van valójában.
Ez biztos, hogy nem mc bug? Az stderr legálisan hibaüzenetek kiíratására van fenntartva, tehát ha a vezérlőkódokat stdout-ra írogatja az mc, akkor neki kell arról gondoskodnia, hogy az stderr-t elnyelje, azaz a /dev/null-ba küldje, ahogyan csináltad is. Workaround lehet egy alias.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Azért ne túlozzunk: `glib` probléma. Ami persze fakadhat `mc` hibából.
Szerk: glib-éknél is
elgurult a gyógyszerdiadalmas előrelépés történt, `meson` kellene a fordításhoz. Aminek, ha találgatnom szabad, nyilván további három függősége lesz, köztük egy újabb Python3 verzió.Szerk: a meson maga is meg van könnyítve, tehát korrekt INSTALL.TXT helyett random szamárságok vannak hozzá, a hasznos információ itt van: https://www.linuxfromscratch.org/lfs/view/development/chapter08/meson.h…
Szerk: glib meglátása:
Én, ha ilyen subproject lennék, most elszégyellném magam, és rögtön generálnék egy ilyen meson.build fájlt.
https://gitlab.gnome.org/GNOME/glib/-/issues/2716
Azért elbírnám, ha nem vérpistikék és pötteringek kezében lenne az ipar sorsa. No mindegy, már itt az éjjájj, az majd megoldja ezt is.
Szerk: szóval ahol azt írja, hogy Gitlab/releases, onnan egycsapásra ne töltsünk le félig összecsomagolt használhatatlan fájlokat, hanem innen: https://download.gnome.org/sources/glib/
Persze így is megpusztul a fordítás, de van itt pár json formátumú logfile(!), elvileg lehetséges, hogy valamelyikben van hasznos információ.
Szerk: további jóság: a disztróból jött slang-nak van /usr/include/slang könyvtára is, a forrásból jöttnek nincs. A `mc` fordítása során ezért az előbbi nyer.
Egyelőre nem tudtam a hibás működést reprodukálni.
Gyerekek, ez akkora glibc bug, hogy a holdról is látszik: "CRITICAL: g_module_close: assertion 'module != NULL' failed".
Nyilván illene az mc-nek tisztességesen kezelnie az stderr-ját, szó se róla, na de az, hogy egy ilyen glibc hiba egyáltalán előidézhető applikációs oldalról és ez összebassza a kimenetet az csakis a glibc sara.
Jobb lett volna, ha eleve kezeli az stderr-t, de nehéz hibáztatni az mc-t azért, mert feltételezte, hogy a libc nem okád az stderr-jára.
Ebben az iparban egyetlen betűnek is lehet jelentősége, pl. `identd` vs `inetd` vs `rinetd`. Ugyanígy a `glib` sem azonos a `glibc`-vel.
Namostan a `glib`-nek megvan az a rossz szokása, hogy amikor hibás paraméterrel hívják, akkor a stderr-re logol (assert.h:assert) bár az igaz, hogy az end-user nemigen tud mit kezdeni ezekkel.
Szerk: a Java stacktrace-ei végtelenül idegesítőek ugyan, amikor rendes hibakezelés helyett írja őket a program a logba, de a mostani esethez jól jönne egy ilyen.
Valóban, nem'tom miért néztem folyamatosan glibc-nek... talán mert nem is lenne másra szüksége?
És újfent, valóban!
Közvetlenül a 4.8.32 tag utáni commit:
A ticket szerint a korábbi verziók nem érintettek, és nyilván a következők sem lesznek.
az oroszok mar a
spajzbanmc-ben vannak...Már nagyon régóta.
Ebben nincs meglepő, az oroszok, ukránok benne vannak szinte az összes ilyen két paneles commandernek a fejlesztésében, nem csak mc, Double Commander, Vifm, stb.. Egyedül a Total Commander kivétel, mert az nem FOSS, meg ott a svájci fejlesztő egyedül nyomja. Ez se csoda, az oroszok után a német nyelvterület még az, hol ezek a commander-klónok mindig is népszerűbbek voltak.
Szerk.: sokszor meg is lep, hogy ezek a commanderek a németektől nyugatabbra mennyire népszerűtlenek. Retró videókon is látom, hogy az amerikai retrósok gépelgetnek a command.com-ba, mint a hülye, ezt annak idején senki nem csinálta. Eleve a Norton Commander is amerikai volt, ezért nem értem, hogy miért nem lett arrafelé népszerűbb. Mi itt Európában sose gépelgettünk a parancssorba, akkor se, mikor a DOS uralkodott. Szinte mindenkinél futott valami fájlkelező, Norton Commander (ennek a klónja az mc), DOS Navigator (klónja a dn2l), Volkov Commander, XTree (klónja az YTree), DOS Shell, Windows alatt nc95, FAR, Windows Commander, ami később Total Commander lett, de van még egy csomó a mai napig, FreeCommander, Double Commander, német fejlesztés az EF Commander, linuxos vonalon Krudasader, Tux Commander, mucommander, stb.. Egyedül az amigások még azok, akik hűek maradtak a kedvenc fájlkezelőjükhöz, az Opus-hoz, annak van modern windowsos változata.
Még a linuxos power usesek, akik terminálguruk, azoknál is ma már inkább olyan fájlkezelőt futnak, ami a Mac-es Finder működését utánozza, Ranger, lf, nnn, és nem favorizálják a commander típusúakat, pedig azok továbbra is léteznek, nem csak mc, de Vifm, sfm. Ez még a GUI-ra is igaz, minden disztró, DE alapvetően Mac Finder / Windows Explorer stílusú fájlkezelőt szállít (Nautilus, Dolphin, Thunar, Caja, PCmanFM, stb.).
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Off: eccer az találtam mondani a mc tudós fejlesztőinek, hogy a
free(talannull); talannull= NULL;helyett jobb lenne azif (talannull) { free(talannull); talannull= NULL; }, de meggyőztek, hogy a feleslegesfree(NULL)egyáltalán nem gond.https://midnight-commander.org/ticket/3585
A free() valóban tolerálja ha NULL-t kap. A g_module_close() pedig nem, erről szól a GLib issue, ha követed a jelen téma mc issue-ja alján a linket.
A hozzáállásról van szó (mondta Gerald Strickland igazgató Marty McFly-nak): hagyományos észjárással gondolkodva azt tesszük szabállyá, hogy "semmilyen destruktort nem hívunk
NULL-pointerre, semfree-t, semfclose-t, semg_module_close-t"; nem pedig azt, hogy "hát afree-nél lehet lazázni, afclose-t korretül kell csinálni (legalábbis egy bizonyos glibc verzió óta), ag_module_closepedig határset."https://gitlab.gnome.org/GNOME/glib/-/issues/3459
Úgy tűnik, hogy éppen a `free(NULL)` hiba-nem-jelzése szoktatja rá a fusereket a NULL-ellenőrzés nélküli destruktorhívásra.
C fejlesztőnek destruktorról beszélni olyan, mint .NET fejlesztőnek natív kódról beszélni. Felesleges. :D Teljesen egyedi észjárásuk van.
Blog | @hron84
via @snq-
Ezt nem tudhatom, mert még csak 1990-óta tákolgatok C-ben.
A g_free() számára a bemenet lehet null, ahogy a free() számára is.
https://docs.gtk.org/glib/func.free.html
memType:
gpointerThe memory to free.
NULL.Szóval teljesen felesleges, amit írtál.
Ha már MC, akkor csak úgy
DOS-on Norton Commander-el éltem, ezért egy ideje MC-ről erre váltottam:
https://github.com/elfmz/far2l?tab=readme-ov-file#far2l-
Fut mindenen (is):
https://github.com/elfmz/far2l?tab=readme-ov-file#community-packages--binaries
Van portable ha hirtelen bármilyen architektúrán vagy OS szükséges:
https://github.com/spvkgn/far2l-portable/releases
Ubuntu stabil csomag amit én használok:
https://launchpad.net/~far2l-team/+archive/ubuntu/stable
Van ebben is far2l és far2ledit. Eleinte létrehoztam alias-t mert úgy ráállt a kezem az mc-re hogy szívás volt.
Egyre bővül a plugin készlete:
NetRocks (SFTP/SCP/FTP/FTPS/SMB/NFS/WebDAV), colorer, multiarc, tmppanel, align, autowrap, drawline, editcase, SimpleIndent, Calculator, Python (optional scripting support)
A far-t és a dn2l-t (ez a DOS Navigator 2 linuxos változata) próbáltam. Az első le sem fordult, a másik igen, de bugzik, mint az állat, nem vesz be billentyűket, crashel Arch alatt.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Mondanám hogy egy elég nagy közösség fordítja nap mint nap, és nem a HUP-on írnak bug report-ot, de a nagy Raynesnek, aki Arch Linux Evangelista és Konzol Huszár, fölösleges.
Ez ilyen. Érdekességnek próbáltam be, retró nosztalgiából, annyira nem volt fontos, hogy elkezdjek jelentgetni, pedig valóban lehet hasznos lett volna. Anno, mikor néztem, elég halott projektnek tűnt mindkettő, most nem néztem, hátha van újabb commit, hétvégén lehet újra megnézem. Ennek semmi köze nincs ahhoz, hogy melyik disztró, konzolt, meg nem használok, azt már mondtam. Ne keverjük a konzolt és a terminált, mert baromira nem ugyanaz. Konzolt senki nem használ, max. hibaelhárítás, meg minimál telepítés esetén, mikor nincs más.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
"Te mondd, hogy mélykonzol, a te hangod mélyebb!"
Meg az Arch Linux telepítők, self.oral
Meg hamarosan én, mert egy secure boot uefi-s gépen nem boot-ol a Fedora, s valahogyan fel kellene rá maszíroznom a systemd-boot nevű izét.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Azért írom, hogy a minimál telepítés során. Ebbe az Arch is beletartozik, meg a Gentoo, Debian minimal netinstall, Alpine, de a Fedorát is lehet opcionálisan ilyen módszerrel telepíteni. Ezeknél nyilván szükségszerűség. Sok alap BSD-nél (Free, Open, Dragonfly, NetBSD) is szintén ez van (kivétel az eleve grafikusak, Midnight, Nomad, helloSystem, stb.), bár előbbieknek van telepítőjük, de azok is konzolosak, és nagyon kevés mindent tesznek fel, telepítés utáni rebootot követően azoknál sincs semmilyen grafikus felület, tty-ból kell felokoskodni dolgokat.
Bár lehet kicsit csalni, és másik gépről csinálni, terminálból, SSH-n keresztül, az játszik, de felesleges. Arra a pár percre, fél órára ki lehet bírni a tty-t, de mindennapos felhasználásnál agyrém, se Unicode támogatás, se 16-nál több szín, se GPU gyorsítás/vsync, se billentyűzetes sebességállítás, se semmi nincs benne, így az még nekem is önkínzás lenne. Tényleg én is csak akkor használok tty-t, ha minimál telepítés van, vagy pl. valami bug miatt nem fut se az X, se a Wayland, és valahogy debugolni kell (pl. GPU drivert), akkor pár percig ehhez a szükségmegoldáshoz nyúlok. Szökőévente egyszer van ilyenre szükség. Egyébként terminál, de modern formában, modern betűtípus, UTF-8, rendes Unicode támogatású font, szép, 24 bites színtémák egyes programok alá, felgyorsított billentyűzet (alapból minden OS alatt a billentyűzet lomhára van állítva, lassan ismétel, de állítható), régen még transzparenciát és/vagy elmosást (kvázi Areo-effekt) is tettem a terminál alá, de arról leszoktam, mert a terminálos tartalom olvasását, áttekinthetőségét megnehezíti, meg ellene hat néhány színtémának. Amiket nem használok, azok a ligatúrák, képrajzolás (Sixel, Kitty-protokoll, uberzug, stb.), utóbbi szerintem felesleges grafikus felületen, arra nyílik új tiling ablak a terminál mellé, abba is ugyanolyan jók a képek. Esetleg tmux-szal lehet még vegyíteni a terminálos élvezeteket, de azt szintén nagyrészt kiváltja nálam a tiling WM, a csempéket nem a terminálban nyitom, hanem az ablakkezelőben, kb. ugyanazt a hatást éri el.
Egyébként tty alatt is bekapcsolhatók extrák, pl. használható magyar vagy más nemzeti kiosztás, állítható felbontás, beizzítható kicsit modernebb betűtípus (pl. Terminus), nagyon korlátozottan, de a billentyűzet sebessége is állítható valamennyire, de a grafikus terminált sose fogja utolérni kényelemben, fapados marad.
Amire még megérheti tty-t használni, azok a kritikus rendszerműveletek. Pl. ha valaki egy nagy rendszerfrissítést tol le, és pl. nem akarja, hogy véletlenül bezárja azt a terminált, amiben fut, vagy az X crashelése elvigye, és ne fusson le teljesen a művelet, akkor tty-ból biztonságosabb indítani, de ez pótolható megint, ha terminálban tmux, screen, hasonló megoldással session-ben futtatják, akkor se szakad meg.
Egyébként el sem hinnétek, hogy terminálból szinte minden megcsinálható, még grafikus kimenetű feladatok is. Pl. képmegjelenítés (sxiv, nsxiv, imv, feh), videólejátszás (mpv, mplayer, ffplay), audiólejátszás (mpv, cmus, mpd kliensek, még kvázi grafikus Unicode vizualizáció is lehetséges, stb), grafikus doksiszerkesztés (plain text forráskód alapján, TeX, LaTeX, groff, markdown + pandoc, PostScript-kódolás, közben egy élő frissítésre képes pdf-nézőt be lehet állítani, ami megjeleníti grafikusan az eredményt), még a LibreOffice-nak is van CLI backendje, kottaszerkesztés (Lilypond, a fent említett pdf-es módszerrel), OpenSCAD (itt is látszik a lerenderelt grafikus kimenet), képmanipulálás ImageMagick-kel. Audió/videó felvételrögzítés is megoldható (pl. ffmpeg), e-mail-ezés (mutt, neomutt, alpine, aerc, mailx), alkalmazások indítására menü, feladatkezelés (htop, btop++, glances, stb.), RSS olvasás (newsboat), táblázatkezelés (sc, scim, R, diagrammok, ábrák GNU plottal), fájlkezelés, tömörítés, konvertálás fájlformátumok között, Androidos teló kezelése (adb, MTP mount + bármelyik terminális fájlkezelő), optikai lemez olvasása, lejátszása, grabbelése, kiírása, miegymás. Számológépnek se kell GUI, calc, python, bc, octave, dc ugyanolyan szépen számol terminálban, még jobb is, mert nem egérrel kell nyomkodni a gombokat, hanem közvetlenül, és könnyeben is javítható az elgépelés, van normális history-kezelés, végtelen precízió (orbitálisan nagy számokat, meg a kicsiket is kezelik, akárhánymillió tizedes jegyig, ezt a szintet számológépek nem bírják). Az mpv, Zathura (mupdf, xpdf), OpenSCAD, stb. se grafikus, mert van ugyan grafikus kimenetük, de nem hagyományos GUI alkalmazások, nincs grafikus toolkit ablakuk, menüjük, hanem egyfajta framebufferként használnak egy ablakot (amit értelem szerűen ki lehet nagyítani teljes képernyőre is). A legtöbb játék se GUI-s, hanem egy grafikus bufferbe nyomják bele a grafikus képet. Rendszeradminisztrációhoz sem kell feltétlen VNC, RDP, spéci távfelügyeleti alkalmazás, desktop sharing, stb., kiváló rá terminálból az SSH, ha kulturált rendszerről van szó (nem szutyok Windows például).
Amihez tényleg kell GUI, és az átlag felhasználó se ússza meg, az a böngészés, azt sajnos megoldották a soy/webdevek, hogy ne menjen se tty-ból, se terminálból, hanem kelljen egy full JS bloat, mainstream GUI böngésző. A másik, hogy sok játékhoz kell a grafikus launcher sajnos Steam, Epic, stb., ez is egy buzi trend lett. Sok zeneszoftver/DAW is úgy van megírva, hogy kell neki sajnos a GUI, abból is általában valami bloatabb toolkit (tipikusan Qt, de sokszor még Jack-et is igényelnek). A másik ahol kell a GUI, az random pixelre pontos grafikus munka (digitális rajzolás, retusálás, precíz videóvágás, effektezés, vektoros grafika finomhangolása, stb.), de ez utóbbi feladatokat nem nagyon végeznek átlagosabb felhasználók.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Arch Linuxon a megfelelő függőségek feltelepítése után gond nélkül fordult. Mindjárt összepakolok hozzá egy PKGBUILD-et, hogy megnézzem, hogy működik.
Blog | @hron84
via @snq-
Meg mióta kivették a Shift+PgUp-ot.
@FeriX :
felraktam repóból a far managert (amikor win-eztem 2000 előtt használtam én ezt)
negyedórás keresgetés után pár dolgot nem tudok megoldani (plugint nem keresgettem):
- el lehet alul a parancssort tüntetni? - ezt az mc-n mindig megcsinálom hogy a könyvtárban a fájlnevet gépelve "ráugorjon".
parancsot csak ctr+o utan adok ki.
- az egyik panel-beli dir-t megnyitni a másik panelben (alt+i az mc ben)
- szimbolikus linket létrehozni az aktuális file/dir-re a másik panelben azonos névvel (ctr+x+s az mc ben)
- (nincs julia syntax-highlight alapban)
rengeteg opciója van aminek a tizedét sem értem/használom, az mcedit-hez képest a működő ctr+C/V kopipaszt az tetszik...
ncs
Megnéztem újra, ezeket nem tudja a far2l.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
köszi, akkor nem is erőltetem :-)
No most reprodukáltam valami hasonlót, Right / Shell Link / hibáshostnév
mc-4.8.32
Ahogy már fentebb említettem, ez a hiba nem jött volna létre, ha nem lennének olyan cukipofa függvények, amik nem csapnak a kezünkre, ha NULL-t adunk paraméterként: ebből fakadt az a hibás intuíció, hogy ellenőrizetlenül hívhatjuk meg a
g_string_free-tis.Tervezed is jelezni nekik?
Úgy nézem, már van folyamatban egy ticket, ami több ilyet javít.
https://midnight-commander.org/ticket/4572
Valóban, igazad van.
Szeretem az mc-t, állandóan használom is, de azért van baja. Ami legjobban zavar, hogy induláskor csinál vmi gethostbyname-et vagy hasonlót (anno strace-eltem, de már elfelejtettem), azaz ha nincs hálózat, vagy épp lerohadóban van, akkor 5-10mp-re blokkol. Namost nekem gyorsbillentyűn van a MATE Terminal + mc, és baromira zavar, hogy 5-10mp-cet kell várni, hogy egyáltalán elinduljon.
Nem tudom, más is megfigyelte-e ezt? Nem jártam annyira utána, mert napi munka után már nem nagyon van kedvem az mc kódot túrni... lehet, hogy ha kézzel újrafordítanám megfelelő configure paraméterekkel, akkor kikerülne belőle ez a feature...
igen, tapasztalom neha, eleg ha a dns nem jo, mar beakad. talan ha a hosts fileba beirod a gep ip-jet es nevet az segit rajta, de nem probaltam
Ezt konkrétan nem, de olyant igen, hogyha rosszalkodik a hálózat, akkor az sftp kapcsolódáskor lefagy, megjelenik egy piros hibaüzenet ablak, és nem lehet semmit sem csinálni. Az egyetlen megoldás az mc-t futtató terminálablak kill-elése.
Egyébként nem ez az egyetlen, máskor is tapasztaltam már, hogy valamilyen piros hibaüzenet ablak felugrása után lefagy, és semmilyen billentyűt nem fogad el, csak a terminál kilövése játszik onnantól (szóval nem tudom, hogy a hálózatkezelésében van-e a hiba vagy a hibaablak kezelésében, mindesetre kiakad).
Én ezt nem tapasztalom Arch-on. Most direkt kipróbáltam, lekapcsolódtam a Wi-Fi-ről, és ugyanolyan gyorsan indult az mc, mint normálisan, pár ms alatt, semmi 5-10 mp-es lag. Milyen disztrón próbáljátok?
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Fedora 36 és 39.
A Fedora 36 az csak lustaság, vagy szándékos önszivatás? 2 éve lejárt a támogatása, a 39-nek csak 2 és fél hónapja. Persze nem ez a hiba oka, az biztos, de már alapindulásban furcsa.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Több oka van, röviden összefoglalva:
Légyszi ne kezdjük el, h milyen felelőtlen vagyok és az én gépemen keresztül intézi az összes hacker a botnetjeinek a vezérlését stb... :D
Nem hinném, hogy feltétlen meghekkelnek, de ezzel a lusta hozzáállással később meg fogod magad szivatni, valami hirtelen szükségessé váló csomagnak egyszer csak nem lesz kielégíthető a függősége, stb.. Ilyen szinten gáz csak. Időd arra van, amire szánsz. Főleg egy C fejlesztés nem tűnik annyira bonyolult környezetnek, hogy valaki nem merjen hozzányúlni.
Ja, a Fedora sztenderd, DE-s kiadási egyre bloatabbak, de tudod csak egy ablakkezelővel is használni, meg kigyomlált service-ekkel, vagy egy minimalistább disztrót. Full rollingnál nem kell sok idő az upgrade-re, mert nincs upgrade, sima update-ek vannak, a csomagok egyesével, szép lassan újulnak meg.
Ha nem szeretsz gyakran frissíteni, akkor a Fedora amúgy is egy elég rossz választás. Debian, vagy Ubuntu LTS Pro-ként, aztán elvagy vele több évig, ha nem zavarnak az elavuló verziók. Frissítés ezekhez is jön ki, de nem upgrade-ként, csak néhány csomag frissül itt-ott, főverziót nem váltanak a csomagok.
Az az egy valóban jogos érv, hogy nem szereted a változásokat, de azt el tudod kerülni, ha nem a mainstream-ben mozogsz, ahol a DE-ket meg sok GUI-s dolgot fél-egy évenként átültetnek új toolkitre, meg átdizájnloják a felületét, ez engem is zavar, emiatt kerülöm is ezeket. Anno a Gnome2-Gnome3 meg KDE4-KDE5 váltás is beszivatott, azóta inkább minimalistább eszközöknél maradok, főleg terminálos megoldásoknál, azokat sose tervezik át.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Inkább úgy jártam, hogy kellett volna valami csomag, és vagy nem volt, vagy túl régi volt. Amúgy nem feltétlen vagyok rest magamnak fordítani :) bár az is jó nagy szívás tud lenni.
Szerencsére nem az, nagyrészt mert magamnak így alakítottam ki. MATE, KATE, make, gcc, mc, toolchainek. Igaz, magán dolgokra is használom a gépet, onnan is jön azért egy rakat csomag.
Régen Arch-oztam, ott engem beszivatott a rolling release, nem elég, h állandóan szedegette le az újabb csomagokat (ez pl. engem nagyon zavar), össze is omlott és a fél rendszer nem működött. Akkor elhagytam az Arch-ot. Azóta is mindenki mástól csak jót hallottam felőle, de nem akarok ismét kísérletezni vele. Amúgy igen jó wikije van.
Ebben is igazad van, valószínűleg más disztrót kéne használnom a bloatosodás és a "stabilitás" miatt. Debian eszembe jutott, vagy Linux Mint, van még 1-2 jónak tűnő alternatíva. MATE vagy Enlightenment DE. Csak ugye akkor a váltással megy el egy csomó idő, és ezt most még sajnálom rá - szabadidőmben nem a gép előtt akarok ülni, munkaidőben meg annyi dolgom van, h nincs egy üres 0.5-1 napom csak a laptopok abajgatására... talán majd nyáron, szabadság alatt.
Mert mindenki szereti elfelejteni a /etc/hosts fájlt okszerűen kitölteni.
Ha nem szeretnéd a lassulást:
A gethostbyname ilyenkor visszadobja neki, hogy 127.0.1.1 és mindenki boldog.
Blog | @hron84
via @snq-
A legtöbb mainstream disztró ezt megteszi default, az localhost-hoz meg a $(hostname)-hez hozzárendelik a 127.0.0.1-et meg az IPv6-os párját is. Nem mintha annyira számítana, nálam Arch-on kis sincs töltve, létezik a /etc/hosts, de csak fejléces megjegyzés van benne kikommentelve. Gondolom ezt a systemd megoldja, hogy a hálózatnál más módon is hozzárendeli a localhost-hoz, hostname-hez a helyi loopback címet, ahogy pl. a DNS-t is saját hatáskörben kezeli.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Akkor a systemd nem csak egy init-rendszer?
Ja, pont ez a baja, amit mindig írok, de sokan képtelenek megérteni. Félre ne érts, én a régi unixos módszert preferálnám, /etc/host, cron, egyszerű symlink-ekkel működő SysV init, szöveges log (nem ez a journalctl-es bináris baromság), stb.. Viszont másik oldalról megvan az előnye a systemd-nek, pl. sokkal gyorsabb boot, meg ilyen localhost/DNS kérdésekben normiknak meg tudja könnyíteni az életét, hogy automatán lekezel mindent, és nekik nem kell konfigfájlokat szerkeszteni, meg terminálhoz nyúlni, amitől nagyon szoktak félni, teljesen ki tudnak tőle térni a hitükből, ha valami nem GUI-s.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
TL;DR: természetesen nem csak init-rendszer, hanem egy bazinagy... nemtudommi, aminek a célja szerényen a Unix leváltása. (Talán a Tronból ismert Fővezérlőprogram a jó név.)
Igen, elvi síkon is baj van vele, hogy át akarja venni az OS és kernel minden funkcióját. Pedig a Unix-filozófia miatt modulárisnak kéne lennie, minden modulnak cserélhetőnek, elhagyhatónak.
Pont ez a legnagyobb baj vele, hogy egy nagy monolitikus valami, ami rá is van kényszerítve mindenkire, mert a sok hülye fejlesztő beemeli függőségnek. Ráadásul évről-évre hízik is, a logind, journald, udevd, meg a localectl, hostnamectl, netctl, DNS kezelés mellé bejött a homed, ooemd, polkitd, bővül tovább a szolgáltatásainak a köre.
Ugyanez igaz a linuxos hangrendszerekre. Eleinte a sndio egész egyszerű unixos, BSD-s megoldás volt, jött rá a bonyolult ALSA, de ez még érthető volt, normálisan le lett kezelve a kernelben, de ez se volt elég, a Red Hat nekiállt bloatosítani, JACK, Pulseaudio, de már tovább léptek a még bloatabb utódára, ami már egy rakás dolgot futtat, Pipewire, Wireplumber, Pipewire-pulse, mindenféle portálokat is kezel, már nem csak hangot, de videót, kamerát, streameket mixel, USB-s LED-es hátvakaró eszközök meghajtásával a hátad vakarja, stb..
Ezek pedig elég sokat bloatosítottak a Linuxon, mikor együtt fut a systemd meg Pipewire sok modulja, szolgáltatása, akkor meg tudna együtt enni 100-200 mega extra memóriát, főleg régi gépeken gond, amelyekben még nem volt elég RAM, meg gyengébb a CPU, nem kicsit be tud tőle térdelni.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
A felhasználói igények fejlődnek. Mikrokontrollerre nem kell Linuxot rakni. Arra megírod csupaszon a kódot natív C-ben, ha nagyon picike mikrokontroller, akkor assemblyben.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
A polkitet tessék békénhagyni, az bőven a SystemD előtt is létezett, és annyira nem is rossz irány a jogosultságkezelésre.
Amúgy a Pipewire pont a moduláris, lecserélhető dolgok példája, a PipeWire-Pulse segítségével képes leváltani a PulseAudio-t úgy, hogy kompatiiblis marad a pulse-only appokkal.
És őszintén szólva, az ALSA-nak pont az volt a baja, hogy (mai szemmel nézve) kicsi és egyszerű volt, eljött a pont, amikor már nem lehetett tovább bonyolítani, mert akkor nem lett volna kicsi és egyszerű. Szophatsz ugyan most is pulseaudio/pipewire nélkül mondjuk egy bluetooth füles beállításával, csak épp nem éri meg a szopást.
Régebbi gépen meg régebbi Linuxot kell futtatni, vagy olyan disztrót kell keresni, ahol opcionális a SytemD meg a pulseaudio. Például a Gentoo-ban ezeket mind elég jól testre tudod szabni, más kérdés, hogy mekkora szopáshalommal fogsz szembesülni, ha valami olyan dolgot szeretnél, ami a "régi gép" korában még nem is létező technológia volt.
Blog | @hron84
via @snq-
> meg ilyen localhost/DNS kérdésekben normiknak meg tudja könnyíteni az életét
vagy inkabb megneheziteni...
+1. Letért az egy igaz UNIX útról: "egy program egy dolgot csináljon, de azt jól". Helyette lett belőle ez a böszme förmedvény, amivel még EFI rootkit is gyönnyedén terjeszthető.
Ezt ellenben erősen megkérdőjelezném.
Normál, tipikus működés mellett a SysV (pár symlink) nagyságrendekkel gyorsabb. Nyilván előfordulhat olyan elcseszett konfiguráció, ahol kismillió egymástól függő service-t kell indítani, de nem ez a jellemző, és azért büntetni a felhasználók 99%-át, mert 1%-nak speciális konfigja van, hát, enyhén szólva is faszság a köbön.
Azt azért be kell látni, hogy egy tipikus asztali gépen vagy szerveren max. ha 10 szolgáltatás indul bootkor a háttérben, ehhez meg bőven elég a sorszámozott symlink, sőt, még jóval gyorsabb is, mint bármi más. Őszintén, tegye fel a kezét, aki valaha is nem tudta megoldani az asztali gépén vagy szerverén a rendszerindulást SySV-vel! Nekem 20 év használat alatt sem volt soha gondom vele (talán egyszer, 2000-es évek elején, amikor még én is, meg a debian is fiatalok voltunk, egyszer át kellett sorszámoznom egy symlinket, hogy ne párhuzamosan induljon, hanem csak miután egy másik lefutott).
Én annak idején üzemeltettem elég bonyolult rendszereket is SysV alapú init rendszerekkel, OpenRC-vel és Upstart-tal is, soha nem éreztem a szükségét egy akkora mocskos nagy bloatnak, mint ami ma a SystemD. Pedig volt, hogy jó pár egymásra épülő szolgáltatás függőségi fáját kellett kirakni - de ki lehetett, és nem is volt olyan sok szopás.
Blog | @hron84
via @snq-
Már benne van:
Amennyiben a gép hostneve nem localhost.localdomain hanem valami más, akkor nincs benne.
Blog | @hron84
via @snq-
Hát, ezt most nem tudtam reprodukálni, nem látom a 'strace'-vel, hogy hozzányúlna a /etc/hosts-hoz.
Ugyanakkor igaz, hogy emlékezni vélek lassulási anomáliákra, például volt, amikor a gpm-mel vívott nemes harcot a mc... https://hup.hu/node/132732
> nem látom a 'strace'-vel, hogy hozzányúlna a /etc/hosts-hoz.
nem kozvetlen nyul hanem a gethostname()-t vagy ilyesmit hiv, es az veszi onnan, HA nem mukodik a dns feloldas
strace mutatná azért, de csak ilyet vélek látni:
És van pár
gethostname(aliasuname) ez igaz.Igen, ha nem volt hálózat, nálam meg bent volt a bash_profile-ban az mc, tudtam káromkodni.
http://www.micros~1
Rekurzió: lásd rekurzió.
A témánál maradva jelezném, hogy kb. egy hete frissült az mc, a 4.8.33-as verzióban már nincs meg ez a bug, gondolom ebbe már integrálva lett az a javítás, amit ez a hozzászólás említ.
“The world runs on Excel spreadsheets.” (Dylan Beattie)