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 glibc 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...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á.
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.