Midnight Commander – régi mc.ext használata

Ubuntu Linux

Szervusztok!

 

Most frissítettem 24.04-re, és azzal szembesültem, hogy a Midnight Commander nem használja a /home/akarki/.config/mc/mc.ext fájlt a megnyitásokhoz. Vagy nem tudom mi a baja, de nem nyit meg semmit, amit akarok. pl. *.ods, *.ly fájlokat, amikoet korábban röhögve kezelt.

 

Mi jót változtattak kedvenc fejlesztőim? Tudnátok segíteni, az új „rendszerem” kialakításában, hogy ismét működjön valahogy az az általam szerkesztett társító fájl.

( valek | 2024. 09. 05., cs – 17:54 )

Köszönöm! Ezek szerint a grafikus alapbeállításokkal futna, ha jól értem.

Ha arra gondolsz, hogy orokli a rendszer- es user szintu hozzarendeleseket, ahogy minden mas valamirevalo program (pl. fajlkezelo, session manager) teszi, akkor igen.

Kisse idegesito persze, hogy pl. egy ujabb PDF olvaso installalasakor (Debian) esetleg az lesz a alapertelmezett, mert csak. De az elso anyazas utan visszapockolod.

Nem értek egyet. Egy terminálos fájlkezelőnek nem feltétlen kell örökölnie a GUI/mime társításokat. Pont ez az egyik előnye, nálam Vifm, sfm, lf, mc, saját fzf-script, stb. alatt egyedien vannak kezelve a fájltípusok, nem azzal vannak társítva, mint GUI-n. Ez egyfajta differenciáltabb, kontextusfüggő társítási rendszert tesz lehetővé.

Persze aki akarja, egységesítheti, általában beállítható, hogy az adott terminálos fájlkezelő a mime-társításokat használja.

Pl. el lehet így kerülni, hogy a Wine frissítésekor a képtársításokat elqrja a rendszer, igaz egy valami Wine funkcióval is kikapcsolható, nem emlékszek rá. A lényeg, hogy alapból a Wine minden frissülés után az Internet Explorer-rel akarja megnyitni a képfájlokat.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Persze, mindent is be lehet allitani. De nem hinnem, hogy a kollega szetkonfigolta a rendszert. Szimplan ilyen lesz az alapallapota az mc-nek.

Hogy ez jo-e, az mas kerdes. Engem mar tobbszor bosszantott (Debian is kezd popperlinux iranyt venni sajnos), de annyira meg nem, hogy tegyek ellene.

Mindegyik modern disztró kezd popper lenni, ahogy egyre mainstreamebbé válik a Linux. Nem csak a Debian (bevezették a GUI installert, a nonfree firmware és tárolók engedélyezését), az Arch is már évek óta könnyít, hogy van installer scriptje (archinstall), most legutóbb a Gentoo döntötte el, hogy kínál bináris csomagokat is. Ez ilyen, próbálják könnyíteni, hogy egyre többen használjanak Linuxot.

Egyébként meg ha régi vonalas vagy, lehet ezeket a disztrókat továbbra is a régi módszerek szerint használni, Debian minimal netinstall (és esetleg nonfree tárolók tiltása, ha valakinek ez kell), Arch telepítése kézileg, Wiki alapján, Gentoo Stage 3-ból indulva fordítással. Nem kötelező ezeket a könnyítéseket igénybe venni.

Azt elhiszem, hogy ez az mc default viselkedése, de szénné lehet konfigolni, ez az egyik lényege a terminálos fájlkezelőnek főleg. Általában a menüknél is finomabban, konfigurációs fájlszinten is bele lehet nyúlni a működésébe, át lehet szervezni az ext és user menüt, stb.. Aki lusta konfigolni, annak nem való ez a haladó fájlkezelős, meg terminálos műfaj, csak fel fogja bosszantani, el fog veszni a beállítások tengerében, nekik normiknak van a Nautilus/Files, Dolphin, Tunar, Caja, PCManFM, és egyéb Windows Explorer / MacOS Finder típusú fájlböngészők, klónok, azoknál nincs sok beállítás, elég szép nagy színes ikonokra kattintgatni, alapértelmezésben a mime/GUI társítással nyitnak meg dolgokat, stb..

A Krusader, Double Commander, SpaceFM, mc, ranger, lf, Vifm, nnn, clifm, xplr, Far, stb. az inkább power usereknek van. Vagy még egy köztes kategória, ami kétpaneles, ortodox, Norton Commander stílusú fájlkezelő, de nincs agyonbonyolítva, Tux Commander, Sunflower, stb..

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( bzt | 2024. 09. 05., cs – 19:52 )

Én is megszívtam a frissítéssel. Van két zip fájl, mindkettő 32 bites PK, és mindkettőben store meg deflate tömörítés van csak, egyikből sem hiányzik vagy inkonzisztens a Central Directory. Mégis, ha az egyiken ütök Enter-t mc-ben, akkor listázza, mintha könyvtár lenne, pont, ahogy várnám. Azonban ha a másikra, akkor azt a firfox-al próbálja megnyitni... ami szerfelett idegesítő, ugyanis a firefox nyilván nem tud mit kezdeni vele, csak felkínálja letöltésre, de közben meg már el is kezdte feleslegesen lemásolni azt a zip-et.

Akárhogy nézem, nem látom, az egyik zip miért megy, és a másik miért nem. Valakinek ötlet?

Ps: a file mindkettőre azt mondja, hogy Zip archive data, at least v1.0 to extract, compression method=store (a method-ban téved, zip -l mutatja, hogy van "Defl:N" is mindkettőben, azonban más, nem RFC1950 tömörített nincs). A fájljogosultságok is azonosak, rw-r--r-- és a tulajdonos meg csoport is egyezik a fájlokon. A jelenség egyébként konzisztens, amelyik zip működik, az mindig működik, amelyik nem, az meg soha sem.

Ps2: ugyanez történik mkv kiterjesztés esetén is, de jóval ritkábban, azonban így is felettébb idegesítő. A legtöbb mkv fájl Enter-re elindul az mplayer-el, pont, ahogy szeretném, de akad egy-kettő, amit az Audacity-vel próbál az istenbarma megnyitni, és tippem sincs, miért. Itt is a fájlnéven kívül minden azonos, a kiterjesztés, jogosultság, tulajdonos, csoport, és az ffmpeg szerint is ugyanolyan kódolású stream-ek vannak bennük, szóval WTF?

Nem, ugyanaz a file parancs kimenete mindekettőn (zipnél és videóknál is, lásd fentebb).

A zip esetében a mágikus bájtokat is megnéztem direktben (hexdump -C) egyeznek bitről bitre (50 4b 03 04 14 00 00 00 aztán vagy 00 (store) vagy 08 (deflate) más kódolás nem fordul elő egyikben sem).
Videók esetén csak ffmpeg kimenet hasonlítottam, asszerint ugyanaz a Matroska konténer és ugyanolyan kódolású streamek vannak bennük (mondjuk a hibásan megnyitottban két felirat sáv is van, míg a másikban csak egy, de nem hiszem, hogy ez okozná. Más, több feliratsávos videók mennek jól).