mc

Fórumok

Sziasztok.

Kíváncsi lennék, mc-hez ki melyik billentyűkombinácót vagy -sorozatot használja legsűrűbben a napi rutinhoz, melyet ha gyorsan elvégez, még az sem tudja követni, aki mellette ül.

Az általam leggyakrabban használtak:
1. F9-f-s
2. F9-f-h
3. Esc-a
4. Alt-s
5. Esc-a után Esc-Enter (aktuális file, teljes elérési úttal)
6. Alt-p majd ppppp... vagy visszafelé Alt-n nnnn  (history)
7. F9-c-f-tab (keresés)
stb.

Hozzászólások

Igy elsore: ctrl-s; esc-enter; ctrl-x - s, ctrl-x-ctrl-s. Kb ezek... 

F9 c f  = file search

F9 c i  = dirsize

ctrl + \ = dir hotlist

amugy a szokasosak, ctrl+o, F4 stb

symlinket, chmodot en paranccsal szoktam, nem mc-vel

esc s   --> keresés az ezt követően begépelt betűkkel kezdődő névre a mappában  ... újabb 'esc s' és a következő ilyen kezdetű (pl. átugrik a dir és a file szekció között)

Ha jól emlékszem, már a terminál úgy küldi, hogy az Alt + betű kombinációra egy ESC karaktert küld, utána a betűt.  Szóval ez máshol is működni fog.

mc hajlamos ESC, majd szám bevitelre F<szám> billentyűt is érzékelni;  gondolom, hogy fizikai funkcióbillentyűk hiányában is lehessen használni.  (szerk: bocs, most látom, hg2ecz már ezt is írta).  De amit mondani akarok: ezt viszont már nem a terminál csinálja, az F-billentyűk 5-6 karakteres szekvenciákat küldenek, ráadásul termináltípusonként kicsit eltérőt. :(

Én azért a Ctrl+S kombóval vigyáznék. Az összes shellben default jegeli a terminált, amit csak Ctrl+Q-val lehet feloldani!!! Persze ez a működés letiltható, ha a shelled rc-jébe beteszed az stty -ixon sort, de ezt sokan nem tudják, és megijednek, hogy „lefagy” a terminál.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Nincs mit. Egyébként csak látszólag fagy le, mert a terminál működik tovább, csak nem látod mi történik benne, mintha ideiglenesen nem kapcsolódna a forráshoz. De aztán ahogy megnyomod a Ctrl+Q-t, onnantól meg minden megjelenik benne, ami a köztes időben történt, kiírás, billentyűbevitelek echo-ja, stb.. Nem vészes, csak sok ember meglepődik, ha még nem tudtak róla.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

:-)

 

Ha már itt tartunk tud valaki bill kombót arra, hogy az egyik panel utvonalát beállítsam ugyanarra mint a másik?

Tehát ha az egyik panel a /var/log/apt könyvárban van, akkor hogyan tudom egyszerűen a másik panelt is erre állítani?

ctrl+o és mögé látok

Vortex Rikers NC114-85EKLS

Vagy 10 eve mondta valaki, hogy milyen lassan inditottam el egy filmet, ennyi ido alatt neki is menne egerrel. Minek a parancssor, meg tok gagyi.

Mondom jo, de kozben en ki is tomoritettem:)

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Vinesek már az mc látványától is elfutnak.

A "linuxosok" meg akkor szoktak megfagyni, amikor közlöm, hogy nálam nincs fent az mc. Miután látom, hogy próbálkoznak az elindításával. ("Dete... akkor.. mc helyett... mit használsz?!" és ilyenkor megmutatom nekik a 10 ujjamat.)

Én lehet valami elrettentő példa leszek, mert isten látja lelkem, próbálkoztam megszeretni. Nem ment. Pedig DOS/Windows95-ről jöttem linuxra, ahol az NC alapkövetelmény volt sokszor a gépen. Még az elején, kb 2000-2005 között ott volt az mc, használtam, de már akkor is inkább zavart. Pedig akkor még desktop-on volt linux-om. Aztán a Nagy Szakítás után, amikor kidobtam desktop-ról, már csak szerver, de ott meg minek.

Azóta is, a körülöttem lévő emberek - akiktől tanultam - nem igen használták. Ahhoz voltam szokva, hogy a problémát azzal kellett megoldani, ami van, nem válogatni az eszközökben. Fújjolni, hogy én ezt nem eszem meg, mert ez vi, én csak a nano-t szeretem. :P Az nem túl profi hozzáállás.

Ami most van, az nekem a paradicsom. Van egy windows-om, ami grafikus felületet ad nekem, alkalmazásokkal, amiket nem kell tákolni, hogy fussanak. Van WSL, hogy annyi konzolt indítsak, amennyi jólesik - és végre az a K puttyot kivághattam a 'csába.

Az mc nekem olyan, mint a biztosítási ügynök, aki váltig álltja, hogy olyat mutat nekem, ami biztos nincs és érdekelni fog. Aztán fél óra után kiderül, hogy semmi olyat nem tudott mondani, ami nincs, de érdekel.

nem vagy egyedi eset, én is azt figyeltem meg magamon, hogy amikor windows után elkezdtem linuxokkal foglalkozni, adta magát a mc, mint hasznos tool, mert nem kellett fejből tudni a parancsokat. aztán ahogy jobban elmélyedtem a konzolos világban, kiderült, hogy a mc igazából inkább csak átmenet a gui és a konzol között, és konzolban sokkal gyorsabban lehet elvégezni ugyanazt, mint mc-ben.

Azért az mc tud segíteni ha sok hosszú fájlnevet kell gépelni/szerkeszteni.
Mivel az mc -vel gyorsan elérem nemigen használom a "file" parancsot. Hirtelen nem is tudom mivel lehet egy könyvtárnyi fájlt összehasonlítani egy másik könyvtárnyi fájlal. A fájlokban szöveget keresni, persze sok fejlesztő ide is tartalmaz ilyet.

A legnagyobb hiányosságom, az a path végén kell e "/" vagy sem, esetleg "/*" az  olyan parancsoknál mint a cp, mv Az mc ezeket simán megoldja, cserébe jóval lassabban.

* Én egy indián vagyok. Minden indián hazudik.

Szerintem túl szigorú vagy az mc-hez. Nincs vele baj, nem kötelező használni. Azzal egyetértek, hogy vannak nála hatékonyabb alternatívák, de önmagában nem egy rossz tool, aki használja, annyira rossz lóra nem tesz vele, elfér, sokat enni nem kér, és hasznos.

DOS-on valóban muszáj volt a rendes két paneles fájlkezelő, mert a command.com shell elég primitív, alapból se fájlt/mappa/kapcsoló kiegészítés, se historykezelés, se semmi nincs benne. Bár a kései DOS-os időkben Norton Commander helyett DOS Navigatort használtam, meg néha, ha floppyról kellett minimálrendszert futtatni, akkor Volkov Commandert. Windowson meg FAR Manager ment sokáig, amit váltott a Windows Commander (amit ugye átkereszteltek Total Commander-re), bár korai Win95-ös időkben használtam Norton Commander for Win95-öt is.

Amit én sose értek, hogy sok windowsos és maces user hogy van el ezekkel a Windows Intéző meg Mac Finder szutykokkal, mert teljesen használhatatlanok, meg az összes klónjuk is, Nemo, Nautilus, PCmanFM, stb.. Nekem minden OS-en kell valami két paneles fájlkezelő, igaz Linuxon én is egyre inkább csak shellt használok fzf-es megoldásokkal, de még a mai napig van fent Vifm, stb..

De még ilyen youtube-os amerikai retrósoknál is látom, hogy DOS alatt shellbe gépelgetnek, ahelyett, hogy nc-t, vagy dn-t használnának, vagy min. vc-t, vagy Xtree, tree86, Ztree, vagy valami. Akár még a DOS Shell nevű TUI, LapLink is jobb, mint a command.com. De kézzel gépelgetnek a szerencsétlenjei, pedig tapasztalt DOS-os veteránok. Persze nem tudom mit lepődök meg, hiszen Windowson is az Intézőt használja szinte mindenki, pedig annál bármi jobb, ha valaki nem is akarja a Total Commander lewarezolni, akkor is vannak jobb ingyenes alternatívák Double Commander, FreeCommander, EF Commander, FAR, stb..

Ugyanez text editornál, DOS-on mindenhol az edit.com-ot látom, Windowson a Notepad-et, amikor ezeknél is szinte minden jobb ezekre a platformokra, nem is sorolom, mert Dunát lehet rekeszteni velük.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

hogy van el ezekkel a Windows Intéző meg Mac Finder szutykokkal, mert teljesen használhatatlanok

Itt meg te vagy tul szigoru ezekkel szemben :)
Ezek a toolok nem nagymennyisegu filemuveletre lettek kitalalva, hanem ugyanugy mint ahogy az MC segit a linux terminalos dolgok hasznalataban (nem kell mindent fejbol tudni), ez is segit, hogy ne kelljen mindent megjegyezned.

Ezek mind segedeszkozok, amik egy rutinos felhasznalot, akinek a kezeben es a fejeben van a tudas inkabb lassitanak, viszont egy kezdonek nagyon nagy segitseget nyujtanak.
En pl annyira ritkan mountolok fel telefon tarhelyet gepre, hogy egyszerubb egy thunart inditanom, es rakattintanom, mint elokeresni, hogy hogyan is mountolok mtp eszkozt.

q f10 q f10 q f10

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

F9 -> beállítások -> alapbeállítások -> saját szövegszerkesztő
Innentől F4 és syntax highlight-os. könnyen kezelhető texteditort kapsz, aminél a syntax fájlt ha kell könnyen felbővítheted.

bal alt-? (rekurzív)keresés ... rákeresel egy szóra és amely fájlokat+sorokat találatként kiír, egyiket kiválasztva F4 és a fájlon belül a szón áll a kurzor.

Ezt a listát illetve alatta a cikket ajánlom figyelmetekbe:
    https://midnight-commander.org/rufork/docs/mc_hotkeys_en.pdf
    https://linuxcommand.org/lc3_adv_mc.php

Legközelebb pedig jöhet a vim és parancsai. :)

syntax file tex-kódnál hiányos.

Ha valaki matematikai módban esetszétválasztást ír, a \Big{ jel után végig zöld minden.

Ezt sehogyan sem tudtam megregulázni.

 

Íme egy példa:

\begin{tabular}{@{}lc@{}}
\hline 
\scriptsize
$A$ & \multirow{2}{*}{$\Big\}\scriptscriptstyle$\mbox{\tiny valami}} \\
\scriptsize
$B$ &                             \\
\hline 
\end{tabular}

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

Az mcedit mindenben hiányos, nem csak TeX-kódok színezésében. Csak egy nagyon alap, kb. nano-szintű szövegszerkesztő, nem arra lett kitalálva, hogy komoly kódokat írjál benne. Ahhoz tegyél fel egy Micro-t, ha nem akarod a vim-et vagy Emacs-et megtanulni. De az mcedit/nano párosnál kb. akármi jobb, ne, ee, jed, joe, és még kismillió. Nem csak kódszínezésben, de színtémázásban, sablonozoásban, automatikus behúzásban, blokkkezelésben, speciális kijelölési módokban, regexp-es műveletekben, stb..

A Norton Commanderben lévő editor is nagyon alap volt csak, épp csak annyi funkcionalitással, hogy valami konfig- vagy .bat fájlbe bele tudják 1-2 sort szerkeszteni. Az se volt való kisregényt írni, meg komoly kódokat. Az mc meg ezt klónozza, nem csak a felületével, de az mcedit-tel is. Az mcedit simán lecserélhető external editorra.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

mcedit nem IDE, de azert nem is olyan rossz. en pl. azzal fejlesztek, legyen akar C, python vagy bash script. kenyelmes hogy in-place tudom modositani a kodot az "eles" szerveren, nem kell deployolgatni meg feltoltogetni :)  persze nem kritikus dolgokrol van szo, inkabb adatkigyujtes, monitorozas (munin pluginek stb), spamszuro modulok, regexpek...

neha kiprobalom a nagy IDE-ket is, de nem nyujtanak annyival tobbet, hogy megerje valtani. amit 99%-ban hasznalok pedig az mcedit is tudja (osszetartozo zarojelek jelzese, copy-paszta, auto-indent stb). nekem a syntax highlighting nem kulonosebben hianyzik, fel se tunik ha nincs.

A'rpi

Sokat használom így is úgy is. Talán az egyetlen ami hiányzik (nekem) belőle az hogy több fájlt is nyitva tarthassak egyidejűleg.
Nem túl jó a szemem, így sokszor rosszul látok bizonyos részeket (pl. megjegyzések). C, bash scriptek, itt-ott html.
Igazán akkor érzem milyen jó is ha nincs fenn és nem lehet feltenni (pl. OpenWrt kevés ram -al).

* Én egy indián vagyok. Minden indián hazudik.

F9 -> beállítások -> alapbeállítások -> saját szövegszerkesztő

...

bal alt-? (rekurzív)keresés ... rákeresel egy szóra és amely fájlokat+sorokat találatként kiír, egyiket kiválasztva F4 és a fájlon belül a szón áll a kurzor.

 

Uhh-uhh koszi. Akkor ez hianyzott, hogy nem ugrott az F4 az adott sorra a talalati listaban.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Egyébként még egy másik trükköt javaslok a vi / vim / mcedit háza tájáról: például gcc hibát ír a hibasfajl.c 435. sorában:
    vim hibasfajl.c +435       # egyébként az esc :435 is ugyanez lenne
    mcedit hibasfajl.c +435
és már keresheted is az elírást a 435. sorban.

+

ekkor felugrik egy ablak amibe shell regexpet lehet írni. Pld: *2019*.jpg

enter és kijelöli az illeszkedő fileokat.

*

minden file kijelölése

-

regexp alapján a kijelölést megszünteti néhány filenál, pld *.txt

ESC majd 0 -> kilépés

Szerkesztve: 2021. 02. 20., szo – 12:15

alt - s
alt - i
ctrl - o
ctl - u

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

ctrl-x-ctrl-p: a túloldali panel útvonalát illeszti a parancssorba.

tar zxvf %D/%F<enter>

Ez talan a legsurubben hasznalt kombinaciom :)

Szerkesztve: 2021. 02. 18., cs – 21:23

En ugy navigalok, hogy

Alt-s -- es elkezdem irni a konyvtar nevet es utom az entert, majd ujra alt-s, es ezt addig amig el nem jutok ahova akarok.

Az egesz szigoruan <3-5sec alatt megvan barhova is akarok menni a szgepen. Ha masik meghajtora megyek, akkor van ugy, hogy elkezdem: cd, majd a home-bol navigalok, ott altalaban van is symlink arra a meghajtora (dat -> /mnt/dat))

 

Esc-shift-, -- (ami lenyegeben az Esc-? magyar billentyuzeten), ezt majdnem egyszerre nyomom le, de azert egymas utan olyan max 0.2-0.4 masodperc alatt.

Ez elohozza a kereso ablakot, itt szoktam a fajlokon *belul* keresni (tartalom alapjan)

 

Alt-Enter -- ez a parancssorba teszi a fajl/konyvtar nevet amin allok.

en atnevezni ugy szoktam, hogy

mv, majd alt-enter 2x, es a masodiknal belejavitom amire at akarom nevezni.

(symlinkek ugyanigy: ln -s majd alt-enter, cat alt-enter, hogyha valamiert ki akarom jelolni a fajl egy reszletet egerrel, stb)

 

ctrl-o -- ezt masok is irtak, a mogotte levo szulo shell-ben lehet irogatni.

 

alt-o -- a masik oldalon levo konyvtarra ugrik az aktiv panel, amin epp allsz.

 

alt-a -- ez igazabol `pwd`, a mv, ln -s es tarsaihoz szoktam hasznalni (unrar x alt-enter, tar -xzvf alt-enter, stb, stb)

 

alt-h -- elozmenyparancsok (mint a felfele nyil a bashban, csak itt kidob egy egesz panelt ra)

 

alt-. -- elrejti/megjeleniti a ponttal kezdodo fajlokat es konyvtarakat. A home-ban nagyon hasznos.

 

Kereses-nel (Esc-shit-,) van egy ilyen, hogy listat panelra gomb. Ami az osszes talalatot kiteszi a panelra, es lehet siman lepkedni koztuk (F3,F4).

Itt meg olyat is szoktam, hogy a komplett talalat halmazt atmasolom egy tmp konyvtarba, amiben regexppel kiszanalom, ami nem kell. Es ott szukitem le, amit tenylegesen kerestem.

 

F3,F4 -- benez, illetve szerkeszt. Az a bajom, hogy par verzio ota a keresesnel nyomok F4-et, akkor nem a sorra ugrik, hanem a fajl elejere, igy ott F3-at hasznalok, ami a sorra ugrik, de az nem csinal syntax highlightingot. Ez nagyon megakaszt. Par eve tudta.

Insert -- erre csak raszoktam tenyerelni, amig nem villog:)

 

F5,F6,F7,F8 -- ezeket tenyleg napi szinten hasznalom.

 

Sajnos nem tud normalisan (rekurzivan) konyvtarmeretet szamolni, arra ezt a snippetet hasznalom (`duh` -re van mappelve):

 

du -b |sort -n | perl -e 'while(<>) {$size = (split)[0]; $name = (split)[1];$s="B";if ($size>1024) {$size /= 1024;$s="KB";if ($size>1024) {$size /=1024;$s="MB"}}; printf "%7.1f%s", $size,$s;print " ", +(split)[1], "\n"}'

 

 

Egyszer valaki betamadott, hogy milyen szar az mc, mert meg atnevezni se tud vele. Csak neztem ki a fejembol, hogy wtf....

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Szerkesztve: 2021. 02. 18., cs – 21:38

ctrl x s symlink

ctrl x c chmod

ctrl x o chown

alt shift / search

ctrl shift enter

esc tab kiegészíti a parancsot

alt o, alt i behozza a másik panelen a kurrens dolgot

ctrl o

ctrl space directory size

ctrl x ctrl d diff files

... egyelőre

mc-t mindig is csak kiegészítő jelleggel használtam, de mikor kivételesen használom, akkor nálam a leggyakoribbak, kurzormozgató nyilak (Lynx-mozgás), F9, Ctrl+o, F4-F2 (edit - save). Előtte inkább Double Commandert használtam helyette, manapság Vifm-et, vi-os billentyűkkel. De már a Vifm is egyre kevesebbet megy, inkább csak shellt használok, saját fzf scripttel érem el a fájlokat, fd/fzf-fel lépek be konkrét mappába (közvetlenül, akárhány mappa mélységben egy lépésben), és tab-os kiegészítéssel másolok, törlök, stb.. Szóval alig-alig használok már fájlkezelőt, de akkor Vifm. Aki megtanulta használni a vi/vim-et, annak utána minden más interface kényelmetlen lesz.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Szerkesztettem az eredeti ajánlásaimat, hiszen a ctrl - u kombinációt is gyakorta használom. Ez swap-eli a két panelt.

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

Fenébe, valamelyest ez is ontopic:

https://downloads.openwrt.org/snapshots/faillogs/mips_24kc/packages/mc/…

Az URL árulkodó, ha nem lenne világos, miért is linkeltem. Nem baj, azért csináltam OpenWRT/LEDE image-et, úgy sem használom a router-en az mc-t, csak nagyon ritkán. Amikor a router pendrive-jára vagy onnan másolok, akkor pedig az mc a hoston fut, a másik panelen ssh linken van a router filerendszere.

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

Igen, ez a jó a terminálos CLI/TUI alkalmazásokban, hogy elfut helyi gépen, SSH kapcsolattal lehet távoli gépet birizgálni vele, és nem kell távolra is feltenni. Bár én használtam régen OpenWrt-s routeren mc-t, eleve ott volt a tárolókban, hiba nélkül feltelepült és ment. De a Vifm kapásból csak harmada annyit foglal, az „lf” meg még kevesebbet, igaz utóbbit szénné kell konfigolni, hogy használható legyen, ugyanez áll az nnn-re is. Na, meg Ranger, de az meg a Python miatt nem annyira pehelsúlyú.

Mc-ben én egyet nem szeretek, nem nagyon szabható testre és nem nagyon bővíthető a funkcionalitása. A Vifm, Ranger, lf, stb. nagyon bővíthetők, scriptekkel, saját billkombókkal, stb., így sokkal nagyobb a rugalmasságuk. De ennek ellenére az mc sem rossz tool, talán kicsit elment mellette az idő, de azért használható, ha nagyon nincs más, túléléshez akárhol elég lehet.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

hiába van mc, egy gyökérbe lépéshez ott a cd /
grep, awk, sed, cat és echo szintén használva van nálam, néha az mc-vel megkönnyítve ezek használatát.
Mindig azt használom, ami épp a legpraktikusabb.

Annak idején C++ tanuélásakor nekem a vi használatát tanították az ELTE falai között, de nem álltam rá. az előadó fejből fújta a billentyűkombinációkat. Egyszer megkérdeztem tőle óra után, miért nem tart a népnek egy bemutatót, mitől és hogyan gyors vele minden művelet -- mert akkor többen rákattannának. Nem tette, nem volt rá keretidő.

50 év felett meg már nem állok neki

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

$ sudo apt install vim   # pár dolga miatt praktikusabb
$ vimtutor                 # 25 perces olvasmány, magyarra fordítva. Ajánlom figyelmedve. Ez csak a kezdet.

Nekem 1995-ben az esc :q!  ... fél évig kill volt helyette, ha belefutottam a vi-be. Szerintem sokan így kezdjük azóta is az ismerkedést vele.
Ma gyakran használom, mert sokmindenre frankó. Hogy kettőt kiemeljek:
   - visual mod (ctrl-v) és vizuális téglalappal tudsz operálni a txt fájlban. Például tömegesen balra rántani egy soksoros kódblokkot.
   - :set expandtab  :retab :wq  ... tabulátor cseréje szóközre (Python3)

Ahogy viszont írtad fentebb: sok eszköz vegyes használatával lehet gyorsan haladni. Mindig ami éppen praktikus.

Egyetértek. Annyi, hogy én a kilépésre a ZQ (mentés kilépés nélkül) és ZZ (mentés kilépéssel) billentyűket ajánlom. Gyorsabb, mint a :q! akármi, kisebb elgépelési lehetőség. A ZQ működik sima vi-ban is, a ZZ sajnos nem. Én egyébként nem szeretem a sima vi-t, nagyon limitált program, a sorszámozása nagyon szarul néz ki, kódot nem tud színezni, meg nem lehet keybind-eket csinálni benne normálisan, mindenre azt írja, hogy too dangerous to bind that. De a sima vim, neovim, származékaik a legjobb szoftver ever, nem a szövegszerkesztési tudás miatt, hanem a modális interface-ük miatt.

A másik, hogy vim telepítésénél figyelni kell, hogy a X-es vágólapkezelés a gvim-es csomagban szokott csak belefordítva lenni a legtöbb disztrónál. Vonatkozik ez nem csak a gVim-re, hanem a sima, konzolos-terminálos vim-re is.

Amit még ajánlok annak, aki vim-et kezd el tanulni, hogy ne használja az egeret, kurzormozgató billetnyűket (nyíl fel, le, jobbra, balra, Page Up, Page Dn, Home, End, stb..). Csak a vim gyári billentyűit igyekezzen használni. A vim lényege, hogy ne kelljen gépírástartásból az alfanumerikus billentyűkön kívülre nyúlkálni, ami lassít. A másik, amit nagyon ajánlok vim-hez, az az, hogy akkor jön ki az előnye, ha valaki megtanul gépírni. Gépíráson nem azt érve, hogy próbáljon minél gyorsabban zongorázni a billentyűkön, hanem 10 ujjas, vakon gépírás, szabályosan, nem egyediesítve, félig lenézve.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

,,X-es vágólapkezelés'' alatt azt érted, amikor konzolon futó editorba mondjuk egy okularról kimásolt szöveget nem tudsz rendesen beilleszteni, csak ha a vágólapkezelőnek nevezett förmedvénybe legalább 5-ször ,,bemásolod''?
(pdf-megjelenítő és mcedit vagy mezei terminál között nálam kicsit vontatott a vágólapkezelés)

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

Fene tudja, én a clipman nevű szerkezetet szoktam használni. Működni szokott. Akkor nincs valami a clipboardon, ha csak én hiszem azt, hogy ott kellene lennie. Mondjuk MPLAB IDE-ben kijelölök egy függvénynevet, Ctrl-f keresés, de ugye nem nyomtam Ctrl-c kombinációt, így nyilván nem került a vágólapra. Persze ilyenkor nyűgös vagyok, de én voltam a hülye. Terminálon amúgy Shift-Ctrl-c illetve Shift-Ctrl-v.

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

A középső egérgomb, vagy az

xdotool type `xsel`

bemásolja a legutoljára kijelölt szöveget, akkor is, ha nem teszed külön a vágólapra.

szerk: megpróbáltam, egyelőre nem sikerült billentyűkombinációra beállítanom a kijelölt szöveg bemásolását értelmesen

Primary Selection-nak hívják az utoljára kijelölt szöveget. Ezt jobbára "régi" Motifes meg pure xorg-os progik támogatják, illetve ezek csak a primary selection-t támogatják jobbára. Mellette van még a Clipboard Selection (Ctrl-C/Ctrl-V). Ezt az "újabb" widgeting systemek támogatják (pl. Gtk) sokszor a Primary Selection-nel egyetemben.

én iceWM keybindinget állítottam be, hogy olyan progiknál is Shift-Inserttel illessze be a Primary Selectiont, amik maguktól nem támogatják:

key "Shift+Insert" icewm-clipboard-paste

de a script nem iceWM-specifikus:
icewm-clipboard-paste:

#!/bin/sh

xclip -selection p -o |\
perl -e '"remove newline from the end of stream";
        while(<STDIN>) {
                print $b if defined $b;
                $b = $_;
        }
        $b =~ s/\n//;
        print $b' |\
iconv -f utf8 -t utf16le |\
xvkbd -xsendevent -utf -file - 2>/dev/null

 

ezzel csak az a baj h néha párszáz msec mire lefut a script és véletlen máshova illesztem be. ez a middle click-nél nem jelentkezik, az mindig gyorsabb.

Nem. A konzol az konzol (tty-ra gondolok most, az mindegy, hogy helyi, távoli, serial vagy akármi), ne keverjük az X alatt futó terminállal (pontosabb leánykori nevén terminálemulátorral). De az irány jó, amibe tapogatózol. Ha pl. terminálban fut az vim, mcedit, stb., és kivágsz belőle, akkor be tudd illeszteni másik X-es programba, pl. Firefox, és fordítva.

Sok disztrónál a „sima” (nem göcsörtös) vim úgy van fordítva, hogy tényleg csak konzolban lesz használva, nem X-es terminálban, így ha valami ki van jelölve, vágva, másolva, akkor az X-es programokba nem lehet beilleszteni, meg emlékeim szerint az egér sem megy benne (ami nem baj, de van, akit zavarhat). Míg a gvim-es csomagban nem csak a gvim maga van, hanem a normál (nem GUI-s) vim-ből is olyan verzió, amibe bele van fordítva az X-es vágólapkezelés, stb.. Ezt csak azért írtam előre, mert meg lehet szívni, és az ember nem érti, hogy miért nem működnek dolgok, meg nem intuitív, hogy minek akarná a gvim-et feltenni, mikor a nem g-s változatot akarja csak úgyis konzolban vagy terminálban használni.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Igen, valahogy így. Szóval az xfce terminálja és a GUI-s programok közt a clipman defektes néha.

Esetleg ha forrásból leforgatok egy mc-t, megoldódhat a probléma? Elméletileg a .configure kiszimatol mindent és aszerint forgat majd ahogy köll'

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

Nem vagyok biztos benne, hogy az mc esetében az újrafordítás megoldja. Bár ki tudja, nem vagyok mc szakértő. De ezt a feature-t a terminálemulátornak kéne kezelnie elsősorban, ennek csak annyi a kényelmetlensége, hogy mikor kivágsz, beillesztesz, akkor nem az vim, mc, stb. saját billkombóit használod, hanem a terminál billentyűit, vagy egeret, stb..

Ez egyébként a text user interface-es programok sajátja, hogy javarészt nincsenek felkészítve az X.org-gal való párbeszédre, mivel nem erre vannak tervezve. Ez van, aki úgy aposztrofálná, hogy nem bug, hanem feature.

A clipman meg jó, de az is csak akkor ér valamit, ha az adott kijelölés, kivágás elérte az X-es vágólapot. Ha nem érte el, akkor a clipman nem fogja érzékelni, hogy valamit a vágólapra tettek.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Nem biztos, hogy a Clipman bugos. Megszoktuk, hogy a Ctrl-c a copy, a Ctrl-v pedig a paste, de ez nincs a Bibliában megírva. Vannak olyan alkalmazások, amelyekben jobb egérgomb copy működik, de a Ctrl-c nem. Ilyen például a Claws Mail, de csak bizonyos szövegmezőkön. Magában a levélben megy a Ctrl-c, Ctrl-v is, de van olyan rész, ahol a szöveg kijelölés megy, de a Ctrl-c már nem működik, viszont jobb egérgomb copy igen. Nem lehet, hogy egész egyszerűen ilyen alkalmazásba futottál bele, s azt hiszed, hogy ez bug?

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

Ctrl + Page Up, és könyvtáron Ctrl + Page Down: könyvtárváltás föl-le, miközben megmarad a (részben) begépelt parancs.

Alt + P, Alt + N volt;  Alt + H - korábbi parancsok listája.  Nem csak a parancssorban, a legtöbb szöveges beviteli mezőben.

Alt + t: oszlopkiosztás váltogatása, most 4 üzemmód között.  A jogosultságok közül az effektívet színnel kiemeli, ha a panelbeállításokban ez be van kapcsolva (alapból nem szokott lenni).

Nem gyorsbillentyű, de hasznos: a parancssorban %f az aktuális panelen aktuális fájl, %d a panel könyvtára, %t a kijelölt fájlok listája.  %F, %D, %T ugyanez a másik panelen.  Szóközök \-sel eszképeltek, nem kell idézőjelezni.  Példák:

  • tar cfz %f.tgz %t
  • mcdiff %t %f
  • mcdiff %f %D/%F

Az F2-es menüt is alakítani szoktam magamnak, illetve a ~/.config/mc/menu szimlink a saját beállításaim repójában a megfelelő fájlra.

Ctrl + \ (már említett) könyvtár-gyorslista Ctrl + 4-gyel is megy, ha valahol az előbbi nem elérhető.  Ezt pedig a ~/.config/mc/hotlist tárolja, nálam az F2-menühöz hasonlóan ez is szimlink a repóra, bár ez erősen gépre jellemző, de legalább a saját gépemen mentem, nem kerül semmibe.

Repóból linkelem a nyelvtani kiemeléshez hozzáírt saját dolgaimat is:

  • ~/.config/mc/mcedit/Syntax: egy szkript fűzi hozzá a gyárihoz a saját sorokat
  • ~/.local/share/mc/mcedit/*.syntax: szkript szimlinkeli a saját fájlokat ide.

... bár a .syntax fájlok nyelvtana (lol) néhol nem barátságos, és nem is profi, mégis használom.

Gombok még:

Ctrl + X, D, M - (magyar beállítás) két panel listájának összevetése (angolban Ctrl + X, D, S)

Alt + , - vízszintes panelek, hosszú fájlnévnél jól jön pillanatra, ugyanez vissza is állítja.

Alt + S keresést én Ctrl + S-sel szoktam.

Alt + ? - részletes keresés.

Alt + . - rejtett fájlok listázása ki-be.

Ctrl + L - terminál frissítése, ha valami összefirkálná.

Ha furcsán beragad a begépelt parancs: ^O ^C ^O (lehet, hogy ez csak régebben kellett, nekem még mindig benne van az ujjaimban).

Érdekes kérdés.  A bash is frissít (töröl), de szerintem az külön dolog, inkább konvenció, hogy Ctrl + L-re frissítsük a terminált.  Nemigen tudná, hogy egy különálló alkalmazás felületét hogyan kell frissíteni, meg az eseményt sem triviális elkapni előle, a bash annyira talán nem rendszerszoftver.

Itt látszik némi explicit kezelés két helyen is: https://github.com/MidnightCommander/mc/blob/master/src/keybind-default…

    {"Refresh", "ctrl-l"},

Nem bash sajátosság, zsh-en is működik. dashben nem, de a legtöbb shellben akkor is bekonfigurálható, ha alapból nem lenne bekapcsolva.

Nekem be kellett konfigolni minden shellben külön, mert nem a szokásos default (Emacs) módot használom a shellekben, hanem a vi módot és abban nem működik sehol alapból.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Szerkesztve: 2021. 02. 28., v – 10:07

(rossz helyre)

A billentyűparancsok azonnal megváltoznak, ha angolról magyarra váltja az mc menüsorát valami...

Hogyan lehet egy magyar nyelven üzemelő mc-t visszaállítani angolra?

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

Nálam meg az egész rendszer LANG=en_US.UTF-8 értékre van beállítva a /etc/locale.conf-ban. Nem csak a konzol, terminál, shell, hanem a GUI is. Nyilván ettől még a magyar ékezetek meg egyebek jól jelennek meg az UTF miatt, meg a billentyűzet is elsődlegesen magyar (~/.xinitrc-ben a setxkbmap felparaméterezve és KEYMAP=hu az /etc/vconsole.conf-ban).

Mindig is feleslegesnek tartottam a magyarított szoftvereket, főleg OS-nél. Hiszen az ember használja, rutinból, nem olvassa el úgy se, hogy mi van kiírva. Cserében viszont magyar nyelvnél mindenféle nyelvi kiegészítő csomaggal kell szenvedni, meg találkozik az ember hibásan lefordított, meg félig lokalizált részekkel. Csak a gond van vele. Tényleg hulla felesleges, különösen olyan szoftvereknél, amiknél úgyis csak a megjelenített adatokat nézi az ember, pl. mpv, Zathura, böngészők (ezekben a webes tartalmat nézzük, és alapból menüsor se látszik), mc, stb..

Különösen előnyös az angol nyelvű lokalizáltan szoftver, ha valami hibaüzenet van, akkor arra keresve angolul nagyságrendekkel több a találat, mintha ugyanazt a hibaüzenetet magyarul keresné az ember. A lokalizáció legkárosabb formái meg pont ezek, hogy a hotkey-k megváltoznak, meg MS Office-ban a makró/függvénynevek is le vannak fordítva, ami különösen kínos, ha a kész doksit az ember nem a magyar verzión akarja használni, mert pl. az nem fogja tudni, hogy mi az az FKERES(). Játékoknál nem különben, gyakran csak menüket, meg 1-2 kiírást magyarítanak, ráadásul emiatt nem kompatibilits patchekkel, meg bugokat okoz, közben meg az egész nem ér semmit, ha csak félig van magyarítva. Akkor is jól jöhet az angol nyelvű rendszer, ha az ember valami netes tutorialt követ, ahol a menükre, hotkey-re, stb. angolul hivatkoznak, amiket magyar nyelvű szoftverben nem fog az ember megtalálni és lehet silabizálni, hogy akkor az most a magyar verzióban minek felel meg. Tisztán időpocsékolás.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Ez attól is függ, hogy ki mire használja a gépet. Ha főleg programozásra, akkor nem international US kiosztás, arról a legjobban elérhető a $, [ ], \, ~, ", stb.. Az international US ékezetekkel vigyázni kell, mert repülő ékezetes megoldást használ. Én főleg magyar szöveget írok, így inkább a hu kiosztást használom, ami persze meg hátrány, mikor épp forráskódot írok.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

én nagyon jól meg tudtam szokni az us-intl layoutot, nem kell váltani programozás és "emberi" szöveg írása közt. minden magyar írásjelet le tudok képezni.

itt egy xmodmap még pár useful matematikai és egyéb jelhez:


! U2260 NOT EQUAL TO
! U2248 ALMOST EQUAL TO
keycode 49 = dead_grave dead_tilde dead_grave dead_tilde U2260 U2248 grave asciitilde

! U2153 VULGAR FRACTION ONE THIRD
keycode 16 = 7 ampersand 7 ampersand onehalf dead_horn onethird U2153

! U2013 EN DASH
keycode 20 = minus underscore minus underscore U2013 yen U2013 dead_belowdot

! U2122 TRADE MARK SIGN
! U00DE LATIN CAPITAL LETTER THORN
keycode 28 = t T t T U2122 U00DE

! U00DF LATIN SMALL LETTER SHARP S
! U00A7 SECTION SIGN
!keycode 39 = s S s S U00DF U00A7
!keycode 39 = s S s S ssharp section

! U2020 DAGGER
! U2021 DOUBLE DAGGER
keycode 42 = g G g G U2020 U2021

! U210F PLANCK CONSTANT OVER TWO PI
! U221E INFINITY
keycode 43 = h H h H U210F U221E

! U00B6 PILCROW SIGN
! U00B0 DEGREE SIGN
!keycode  47 = semicolon colon semicolon colon U00B6 U00B0
!keycode  47 = semicolon colon semicolon colon paragraph degree

! U03C0 GREEK SMALL LETTER PI
! U221A SQUARE ROOT
! U266A EIGHTH NOTE
! U266B BEAMED EIGHTH NOTES
keycode 94 = U03C0 U221A 0x0000 0x0000 U266A U266B

! U2717 BALLOT X
! U2718 HEAVY BALLOT X
! U2612 BALLOT BOX WITH X
keycode 53 = x X x X U2717 U2718 U2612 0x0000

! U2713 CHECK MARK
! U2714 HEAVY CHECK MARK
! U2611 BALLOT BOX WITH CHECK
keycode 55 = v V v V U2713 U2714 U2611 0x0000

! U03BC GREEK SMALL LETTER MU
! U03A3 GREEK CAPITAL LETTER SIGMA
keycode 58 = m M m M U03BC U03A3 U03BC U03A3

! U2190 LEFTWARDS ARROW
keycode  59 = comma less comma less ccedilla U2190 ccedilla Ccedilla

! U2026 HORIZONTAL ELLIPSIS
! U2192 RIGHTWARDS ARROW
keycode  60 = period greater period greater U2026 U2192 dead_abovedot dead_caron

! U2194 LEFT RIGHT ARROW
keycode  61 = slash question slash question questiondown U2194 questiondown dead_hook

en_DK.UTF-8
Ajanlom a US helyett. Sima angol minden, annyi, hogy amikor mertekegysegrol vagy datumformatumrol van szo, metrikus meg YYYY-MM-DD a sorrend.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Ilyen nekem nincs, az alias kiadása után az mc nem indul.

Visszaállítottam hu_HU-ra.

A fő problémám az, hogy

LANG=en_EN.UTF-8 mc

esetén az mc-ben megszűnnek a magyar ékezetes karaktereim, és az mc keretei számokká, betűkké alakulnak.

Kódlap-probléma, vagy fene tudja mi...

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

Mint írtam, en_EN nincs, csak en_US (ez  egyébként az alapértelmezett, ha nincs megadva LANG egy rendszeren, de az UTF-8 tisztázása miatt mégis be szokták állítani), en_GB, stb.. illetve az en_DK-t is ajánlotta valaki. Természetesen ahhoz, hogy ez működjön, a rendszereden lévő /etc/locale.conf fájlban is UTF-8-as kódolásnak kell lennie, pl. LANG=hu_HU.UTF-8, meg a terminálemulátornak is támogatnia kell a Unicode-ot (a modern terminálok mind tudják) és még a használt betűtípusnak is kell tartalmaznia a vonatkozó karaktereket (ezeket megint minden támogatja, ami az elmúlt 20 évben készült, kicsit is használható ttf, otf, stb. font). Illetve fájlneveknél is fontos, hogy UTF-8-cal legyenek mentve, mert ha van valami másik, nem Unicode-képes rendszeren összegányolt régi fájl, annál lehet gond speciális karakterekkel, de ez megint nem életszerű, ha eddig valaki nem a kövek alatt élt, és nem erőltetett valami nagyon egyedi, régi kódolást.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

LANG=en_US mc

esetén sajnos ugyanaz a helyzet. Az általad említett file nálam nem létezik, van helyette ez:

# cat /etc/locale.gen | grep -v "#"


en_US.UTF-8 UTF-8
hu_HU.UTF-8 UTF-8

 

Csakhogy a

LANG=en_US.UTF-8 mc

kiadásakor bejön az mc magyíarul, én meg a hajamat tépem...

Amúgy épp egy Mint distribet tolok, egyelőre szépek és jók a tárolói, egyedül azért.

 

(Slackware-szálamat most hanyagolom, megvárom a rendes 15.0 kijövetelét...)

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

A locale.gen-ben is jó, csak akkor locale-gen kiadásával le is kell generálni vele a beállításokat.

Egyébként rém fura, mert most kipróbáltam Archon, és nekem sem működik ez a LANG=blabla alkalmazásnév megoldás, pedig működnie kéne. Behányja a can't set the locale; make sure $LC_* and $LANG are correct. Ennek majd utánanézek, ha lesz rá időm, ez nekem is teljesen új. Az biztos, hogy nem jogosultságprobléma, mert sudo-val sem megy! Lehet nálam az a baj, hogy csak en_US.UTF-8 van mind a locale.conf-ban mind a locale.gen-ben.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Na, most volt időm hétvégén kipróbálni. Az a megoldás, amit gombóc kolléga ír. Tehát az ilyen LANG=blabla programnév megoldást akkor tudod használni, ha ELŐTTE:
1) engedélyezted az adott blabla lokalizációt extra sorban a /etc/locale.gen vagy /etc/locale.conf fájlban, fontos, hogy nem elég kábére, hanem egész pontosan, kódolással együtt, ha pl. en_US.UTF-8-at engedélyeztél ott, akkor nem használhatsz en_DK-t, meg en_US.ISO-8859-1 lokalizciót.
2) utána kiadtad a lokalizációt ténylegesen legeneráló, életbe léptető parancsot az adott disztrón (ez Arch-on locale-gen, Deb/Ubuntu származokon meg vagy locale-gen, vagy dpkg-reconfigure locales vagy update-locale parancs, root jogokkal kiadva)
3) mindezek után minimum ki/bejelentkezést vagy rebootot is megejtettél az adott userrel!

Csak, és csakis EZUTÁN van az, hogy az aktivált extra LANG lehetőséget használhatod az adott parancs előtt, most próbáltam ki mc-vel, és rendesen megy, angol nyelvű (en_US.UTF-8 ) rendszeren a LANG=hu_HU.UTF-8 mc hatására magyarul jön elő az mc, magyar menükkel, magyar dátum- és időformátummal, és mivel mindkét lokalizáció nálam UTF-8-ként lett beállítva, és a terminál (alacritty) is Unicode-képes, ezért a grafikus karakterekkel sem volt gond, helyesen jelentek meg ékezetek, kereket, görgetősávok, stb..

Egy szó mint száz: győződj meg, hogy minden neked szükséges lokalizáció engedélyezve és aktiválva van, és hogy mindegyik az UTF-8-as fajta, még csak véletlenül sem ISO-s valamelyik. Utána viszont mennie kellene, ha a terminálod nem túl ősi. A modern disztrókon és az mc-n nem múlik, mert azok támogatják.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Valami nagyon komoly gond lehet nálam, hogy ezen lépések után sem megy.
Az mc nyelve átvált angolba a
LANG==hu_HU.UTF-8 mc
hatására, de ékezeteim továbbra sincsenek reboot után se.

A dpkg-reconfigure locales is lefutott, minden szükségeset bejelöltem.

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

A LANG után egyszeres = kell. De ha úgy se megy, akkor nincs ötletem, ha tényleg mindent végigcsináltál. Más ugyanis nem nagyon lehet tenni, eddig nekem minden disztrón ment, Mint, Ubuntu származékokon, Arch alatt.

Egyébként az mc egy nagyon szarul megírt program, vagy csak nem gondozzák, és emiatt modern rendszereken baj van vele. Értsd: nem a funkciójával, tudásával van baj, hanem terminálokban meg konzolban egy csomó beállítással szeret összeakadni, bugzani. Pl. nekem OpenBSD drm ttyC konzoljában van vele most gondom, az istennek nem akarja a tutit. A lokalizációval épp nincs baj, igaz azt nem is feszegetem, de pl. mindegy milyen konzolbeállítást és TERM változót adok meg neki, vagy a karakterkódolás nem jó neki, vagy egyes funkcióbillentyűket nem vesz be. Pedig a konfigurációs beállításai között (Options menü) is túrtam mindent, output encoding, input bits, meg mindenféle varázslás, semmi nem segít, de már rájöttem, hogy ez nem valami rendszerbeállítás, mert csakis az mc szórakozik, meg kicsit a Vifm (amiben a kurzormozgatók, és a téma nem jók), minden más hasonló TUI program eddig jó.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

> mc egy nagyon szarul megírt program

ezzel vitatkoznek... bar teny hogy vannak kevesbe jol megirt reszei, pl. ftp kliens, de azert alapvetoen nem rossz. (leszamitva a 4.5 verziot amibe beleganyoltak a guit/gtk-t is, de aztan 4.6-ra kipucoltak teljesen, amikor Pavel atvette Migueltol)

> mindegy milyen konzolbeállítást és TERM változót adok meg neki

na itt van a kutyi elasva. kulonosen, ha valami generic tipust adsz meg a TERM-ben (pl. vt100, xterm stb).

raadasul a termcap/terminfo fileok nem tartalmazzak az olyan extrabb billentyu kombinaciok esc kodjait, mint pl. ctrl+pgup, shift+del, alt+F4 stb  es ezeket a kulonbozo terminal emulatorok is maskepp kuldik.  en anno irtam mc-hez patchet ami ezeket egesz jol detektalta/kezelte, de nem olvasztottak be, mert elegge gany megkerulese a problemanak.

amiota macos-t es azon iTerm-et hasznalok, az iterm-ben csinaltam egy mc terminal profilt, es ott remappeltem a key code-okat ugy, hogy a gyari mc-nek is megfeleljen, azota nincsenek ilyen gondjaim...

A szarul megírtat nem úgy értem, hogy tudásra, hanem a konkrét implementáció ilyen bizonyos termináltípusra fixen drótozott valami, és az egész S lang-ban van összedrótozva, ami egy primitív szkriptnyelv. Ha mondjuk C-ben lenne megírva, rendes általános implementációval, hogy lehetőleg minden termináltípust támogasson normálisan, akkor is ugyanezt tudná, így nézne ki, csak nem bugzana össze-vissza.

Terminálemulátorban egyébként sose volt vele gondom vele (se xterm-ben, se a többiben, Termite, Alacritty, st lxterm, gnome-terminal, xfce-terminal, Konsole, Retro Term, stb.), de tty-ban (értsd: hardveres konzol, amit az ember grafikus felület, azaz X vagy Wayland nélkül nyit le) viszont meg tudja szivatni az embert rendesen, billentyűk, színek, karakterek, stb. nem jó. Én ezt egyébként annak tudom be, hogy jó ideje nem fejlesztik érdemben, 20 éve csak apró patchek vannak rá, egy legacy program, mert úgy gondolják, hogy már nem sokan használják, közben meg tévedés, mert az egyik legjelentősebb konzolos fájlkezelő. Én abszolúte Vifm-et és fzf-et használok már helyette, de sokszor még nekem is jól jön az mc, ha valami egzotikus rendszeren vagyok, aminek a tárolójából hiányzik a Vifm, és leforgatni sincs idő vagy lehetőség, akkor sokszor ment életet. Routertől szerveren át a desktopig mindenre felteszem, amolyan mentőövként szolgál, ha más nem lenne elérhető, és csak egy konzolom van.

Az nnn, Ranger, lf-et nem bírom megszokni, mármint a logikájukat, hogy nem rendes kétpaneles fájlkezelők, hanem ilyen intézőszerű, de 3 paneles konecpciójuk van, tallózópanel, tartalompanel, előnézetpanel, ami akkor elég, ha az ember csak a partíciót nézi át, de akkor nem, ha valami összetettebb műveletet végez fájlokon, mappákon.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

jesszus ennyi hulyeseget hogy hordtal ossze?

1. az slang nem scriptnyelv hanem egy console i/o library, es nem csak azt tamogatja az mc, hanem az ncurses-t is.

2. az mc-t C-ben irtak!

3. az unix terminal leiro formatumok nem tamogatjak a bonyolultabb funkciobillentyuket es kombinaicokat, sem a kb 40 eves termcap sem a kb 30 eves terminfo. a TERM valtozoval megadott tipust ezek az adatbazisok tartalmazzak, hogy melyik billentyunek mi a kodja, de ha nincs benne akkor az mc sem fogja tudni onnan kiolvasni...  ilyenkor vagy nem mukodne egyaltalan, vagy fallbackel a linux konzolon hasznalatos kodra.  arrol nem az mc tehet, hogy szoveges terminalon azota sincs megoldas erre... mondjuk mc-n kivul nem is sok konzolos program van, ahol igeny volna ra.

4. 20 eve meg nagyon aktivan fejlesztettek, koztuk en is. az utobbi 10 evben valoban elegge megallt, a 4.8 ota, de mar nem is nagyon van rajta fejleszteni valo...

5. azt nem ertem hogy neked hardveres konzolon miert nem jo, ott tokeletesen mukodik nekem minden gepen. hacsak nem rontottad el a TERM bealitasat... vagy valami patchelt verziot hasznalsz amiben valaki atirogatta az esc kodokat, mert nekem a gyari mc az xterm-felekben nem jo, konzolon meg igen.

Igen, a nyelv részében tévedtem. C-ben írták, de valami Slang-ot is használ. Az valószínűleg igaz, amit a terminfóról írsz, de ezt miért nem oldják meg 2021-ben? Mert én abszolúte CLI/TUI, shell párti vagyok, 99%-ban ilyen megoldásokat használom (alig pár szoftver GUI-s már csak nálam), de ez gáz, hogy ez még gondot okozzon. A mai modern terminálos megoldásoknak semmin nem lenne szabad fennakadniuk, se UTF-8/16/32 (közöttük smiley és mindenféle ikonkarakter támogatása), se semmilyen nyelvi beállítás, se termináltípus, alapnak kéne lennie akár a 32 bit truecolornak (24 bit RGB + 8 bit Alpha), vastagítás, döntés kezelésének, mindenféle billentyűk kezelésének (nem csak ilyen alap funkcióbillentyűk, kurzormozgatók, hanem Compose meg mindenféle dead keys, stb.), automatikus kiegészítésnek, terminál és felbontás átméretezést is jól kéne rereagálniuk stb.. Ez a semmilyen spéci billentyűt nem kezelek le (olyanokat, amik egy 40 évvel ezelőtti PC-n, XT-n is jelen voltak már, és ez a platform már támogatta az ASCII 8 bitet is, szóval ilyen commaderekben jók voltak az ablakkeret csíkjai), meg ez a 2-16 színnel szopás még elment 1970-ben, de az eltelt 50+ évben össze kellett volna szedjék magukat, ha Slang, ha Clang, nem érdekel, menjen, ne kelljen vele szívni.

Meg ha ez a terminfo az oka, akkor miért csak az mc-vel van gond? Ezért gondolom, hogy a gondok az mc-ben vannak eltemetve. Egyébként az mc-vel terminálban nincs gondom, tty konzolnál Linux alatt sem, de OpenBSD alatt fájdalmasan szar, igaz ők eléggé limitálják a tty-t, és ultrakonzervatív beállításokkkal dolgoznak, amit még nem sikerült maradéktalanul feloldanom.

Vagyis nem csak az mc-vel van gond, de elég kevés szoftver érintett ilyen blőd hibáktól. Pl. neovimben már 2 éve nem oldják meg azt a bugot, hogy egyes terminálemulátorokban csak fele képernyőn indul, mert többszálú futás miatti téves szinkronizáció miatt nem dolgozza fel az SIGWINCH jelet. Persze a neovim-esek állítják, hogy ez a terminálok hibája, mert minden terminál hülye, csak ők a helikopter, és csak azért se javítják.

Egyébként teljesen megértem a GUI Matyikat meg a normikat, hogy mikor találkoznak ezzel a rosszul beállított CLI/TUI-t érintő terminálos megoldásokkal, akkor ósdinak, szarnak tűnik nekik, és ledobja az agyuk az szíjat, és annyira megundorodnak tőle, hogy többet látni se bírják. Pedig egy nagyon jó dolog lenne, a GUI-nál mindig hatékonyabb, de ahhoz 1) jól kell lennie beállítva, 2) meg kell tanulni használni, kicsit meredek elsőre a tanulási görbéje. DOS/Windows platformokon még rosszabb a helyzet, mert legutóbbi időkig ott nagyon limitált volt nem csak a konzol, de a parancssor/terminál is, így nem csoda, hogy ergyának tűnik egy kívülállónak.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Írtátok már mi az. Ha annyira érdekelne, utánanéznék. Nem láttam még eddig érelmét, hogy foglalkozzak vele, csak láttam, hogy minden platformon behúzza függőségnek. Nem sok ilyen szoftver van, de azért van pár, ami épít erre az Slangra, pl. jed text editor is. Annyiból elnézést kell kérjek, hogy azt hittem emiatt szar, lehet nem ez az oka, én így kívülállóként, aki nem dolgozott még ezzel, azt hittem ezeknek tudhatók be a bugok, de ezek szerint nem. A lényegen ez viszont nem változtat, hogy modernizálni kéne már az mc-t. Jó ideje egyébként én is akarok egy saját fájlkezelőt írni, de az az fzf-szerűségen és modális vim-kiosztáson fog alapulni, és nem ezen a hagyományos nc/mc F1-F10 féle koncepción, utóbbira csak annyiban fog hasonlítani, hogy ortodox 2 paneles lesz. Ha lesz is függősége, az is max. ncurses, és kész. Eddig tökéletes fájlkezelőt nem találtam, a GUI-sok közül a Total és Double Commander (ezt már nem használom, hogy nem windowsosok és másfél éve kerülöm a GUI-s dolgokat), terminálosok közül a Vifm áll hozzá a legközelebb, de még ezek se tökéletesek. Vifm-nek is megvannak a nyűgjei, korlátai. A Ranger-típusú fájlkezelők, mint a lf, nnn, stb. meg nem tetszenek, nem bírom őket megszokni.

Nemrég az awkfm-ről néztem videókat, az awk-ban írt, de nagyon primitív, igaz csak poénnak szánta a fejlesztő is, mert rajta kívül még nem volt olyan elmebeteg, aki tisztán akw-ban megpróbált volna komolyabb alkalmazást írni.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

mert rajta kívül még nem volt olyan elmebeteg, aki tisztán akw-ban megpróbált volna komolyabb alkalmazást írni

Írtam awk-ban USB-n lógó, saját fejlesztésű - nem hobbi, hanem munka - hőmérséklet szabályozó oszcillogramját gnuplottal rajzolgató alkalmazást, amely képes volt arra, hogyha másik példányban elindítottuk ezt a programot, a paramétereit átadta a már futó példánynak, s az adta át a parancsot USB-n a hardware-nek, a választ pedig visszaadta a második példányban indított process-nek, hogy az kiírhassa az eredményt. Ezt azért csináltam így, hogy az USB-n ne legyen ütközés, race condition, hanem összefésülődjenek az USB-s parancsok.

A gnuplot-ot az awk hívta, ideiglenes file-t írogatott tmpfs-re, aztén reread, replot, így lehet oszcilloszkópot csinálni, már, ha nem kell gyors. :)

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

Az igen. Én nem nagyon szeretem, a szintaxisa elég balfék. awk-ward, ahogy mondani szokták. Ez a szóban forgó awkfm is csak azért született, hogy megmutassa, hogy Turing-képes nyelv, elvileg bármit lehet írni benne, gyakorlatilag nagy fájdalom, mert trükközni kell billentyűelkapási események és egyebek miatt, durva hekkeléssel. Épeszű ember ezért nem is nagyon szokott benne írni semmit, max. csak ilyen 1-2 soros valamit. De az alapötlet tetszik, hogy gnuplottal csináljuk szegény embernek oszcilloszkópot.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Miért fájdalmas az awk? Lényegében C szintaxisa van, csak értelemszerűen nincs benne pointerezés meg struktúrák, unionok, mivel script, így gyengén típusos, illetve ismeri helyből a regexpeket.

Ha az a fájdalom, hogy minden recordot feldolgoz, s erre semmi szükséged, írd a teljes programot a BEGIN vagy END szekcióba. Az ARGV[] is elérhető, tehát át tud venni inputot.

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

Pont ez az, hogy nem teljesen C, csak hasonlít, meg kell tanulni, zavaró, keverésre-tévesztésre ad okot, de ugyanez a baj a calc-kal is (amin nem a LibreOffice Calc-ot értem, hanem egy bc-n alapú, CLI matekprogramot, aminek a teljes neve C-style arbitrary precision calculator). Mondom, nem is arra csinálták, hogy komplett szoftvereket írj benne, hanem hogy egy másik parancsból belepipe-olva rövid kimeneteket fel tudjál dolgozni, olyanokat, amik oszlopokra bontva feldolgozhatók, statisztikailag elemezhetők, mert ezeket nehezebb lenne sed, egrep, stb. segítségével megoldani. Kb. ahogy a shell script sem arra való, hogy komplett, nagyobb alkalmazást írjál. Lehetni lehet, mert működik, meg a shellkommandó nem rúgja rád az ajtót, de elég kényelmetlenek, szuboptimálisak erre a feladatra. Kiváltképp olyanra, amit te írtál, mert az oszcilloszkópnak pont az lenne a lényege, hogy ne legyen túl nagy lag kirajzoláskor. Plusz a másik érv pont az ezek ellen, hogy ha már egyszer megírod, meg úgyis C-like a szintaxisa, akkor már onnan csak fél lépés átírni tényleg C-be, és lefordítani natív binárissá, ami tényleg villám mód futkorászik, mivel nem kell interpreternek tekernie a háttérben, és menet közben értelmezgetnie.

A másik, hogy az awkward szintaxis relatív, mert az awk sok másik hagyományos scriptnyelvhez és prognyelvhez képest szokatlan, de pl. sokkal jobb a brainfuck-nál, meg most pl. nemrég néztem videókat az Agda-ról, hát annak valami förtelem a szintaxisa, Unicode karakterekkel és mindennel, az egész egy áttekinthetetlen, cicomázott, átgondolatlan katyvasz, modern és absztrakt akar lenni, de közben csak kínosan szar. De sok embernek az agya már a lisp-től is ledobja a láncot, mikor látják a randomnak tűnő módon egymásba ágyazott zárójelhegyeket, és azonnal elvesztik a fonalat.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

> igaz, amit a terminfóról írsz, de ezt miért nem oldják meg 2021-ben

gondolom olyan ez is, mint az SMTP protokoll, vagy a Radius, es meg sok hasonlot sorolhatunk, amit 30-40 eve talaltak ki az akkori unixokra, es ugyan mara teljesen elavult, korlatozott, de az elterjedesuk miatt nincs alternativaja...

es azert valljuk be az mc extra funkciobillentyus igenyei elegge retegigeny, hogy nagy eroforrasokat mozgositson egy uj terminal leiro formatum fejlesztesere es elterjesztesere minden major OS-ben es terminal programban :)

ncurses VAGY slang kell neki, a konzol matatashoz (input/output).

valaszthato melyik. reg forditottam kezzel, de sztem valahol allithato, configure parameterrel vagy makefileban.

 

https://midnight-commander.org/ticket/3264

mondjuk ez azt irja dobtak az slang-ot, de lehet csak a redhatnal?

https://bugzilla.redhat.com/show_bug.cgi?id=1436394

Ha az a gond, hogy a mc-ben a keretrajzoló karakterek helyett betűk (pl â) látszanak, akkor a LC_CTYPE nincs összhangban a terminállal, ezeket a teszteseteket kellene kipróbálni:


LC_CTYPE=hu_HU.UTF-8 mc
LC_CTYPE=hu_HU.ISO-8859-2 mc

Off: Néha már arra gondolok, valahová be kellene gépelni ezeket a gyakran ismétlődő kérdéseket.

Debian/Ubi meg egyeb, dpkg-t tamogato rendszeren en azt szoktam, hogy:

sudo dpkg-reconfigure locales

Aztan kivalasztom a hu_HU, en_US, en_DK es hasonlo kodolasokat (UTF-8-ast persze), a kovetkezo kerdesnel meg az utobbit beallitom defaultnak. Ha az adott program nem ismeri, fallbackel az en_US-re.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Az összes létező kombinációt kipróbáltam.

Bezavarhat a localepurge? Kilőttem ugyanis a bengáli- és hasonló nyelveket a Holdra...

Végső esetben forráskódból telepítem az mc-t és kilövöm ott a fenébe a magyar nyelvet valahogy...

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

A felhasználói menüben bzip, tar be- és kitömörítés is szerepel. Készített már esetleg itt valaki olyan menüpontot, hogy zip kitömörítése lehetséges legyen, pl. unzip - el? Jó lenne, ha ezt meg lehetne úgy oldani, hogy csomagfrissítéskor ez ne íródjon felül.

az mc a user menut az adott könyvtárból veszi, ha az nincs akkor a user home-jából, ha az nincs akkor marad a rendszeré, amit a csomagkezelő piszkál. én azt csinálnám hogy a per-user konfigban tartom a custom menüpontjaimat és egy szkripttel belehúzom a rendszerét, hogy megkapjam a csomagfrissítéskori változásokat és a sajátjaim is megmaradjanak.

a jó az lenne ha ez a fájl támogatná az include-olást.

ugyanez vonatkozik az mc extension config fájljaira.

Szervusz, köszi a magyarázatot! Létrehoztam a /root/.config/mc/menu filet az alábbi két sornyi tartalommal:

u       Extract *.zip
        unzip %f

Sajnos csak ez az egyetlen menüpont jelenik meg, viszont tökéletesen működik a kitömörítés. Gondolom, ha az eredeti menü tartalmat beszúrom kézzel, akkor valószínűleg együtt lenne minden, de ezt nem érzem szép megoldásnak. Include funkció úgy tűnik, nem működik, vagy nem így lett kitalálva.

Én a sima (sztenderd, pkzip kompatibilis) .zip fájlokat régen Double Commanderben kezeltem, most egy ideje Vifm-ben nyitom meg, ami a fuse-zip modult használja hozzá, és bele tud lépni, mintha mappa lenne, és innen másolom ki belőle a mappákat, fájlokat a másik panel célmappájába. Igaz linuxos környezetben ritkán találkozni .zip-pel, mivel szinte mindenki tar.akármit használ. Egyedül a git jut eszembe, ahol néha jobb tömörítve letölteni az utolsó verziót (teljes clone helyett), ott van sima .zip. Szóval annyira ritkán van szükség, hogy egy unzip *.zip is megtenné shellben, ahogy a .rar is nagyon ritkán fordul elő, azt is megnyitja a Vifm rar2fs-sel, ami szintén fuse modul, de az unrar *.rar-ba se halnék bele, mikor szökőévente egyszer kell. Betömöríteni meg csak és kizárólag tar.zst-vel szoktam tar -I "zstd -T8 -19" -cvf parancsra drótozott shell alias-szal, ez legerősebb tömörítési fokot használ (van erősebb, 20-22-es fokozat, de az spéci --ultra kapcsolóval aktiválható csak és túl lassú be/kitömörítést tekintve is, amivel a zstd elveszti az előnyét), 8 prociszálat.

Igazából erre lehetne írni egy saját shellscriptet, ami grep-pel megnézi a kiterjesztést, és aszerint választ case ... asec szerkezettel kitömörítőt, amivel kitömöríti a $PWD-be, és ezt bedrótozni az mc-be, Vifm-be, vagy shell aliasként. Inkább maradok a Vifm-es módszernél, mert az gyorsabb. Hiszen sokszor nem akarom az egész tömörítvényt kibontani, hanem csak 1-1 fájl kell belőle (vagy csak bele akarok nézni, hogy benne van-e egyáltalán, ami kell, vagy az másik tömörítvényben van), így időben, meg I/O műveleteket tekintve gazdaságosabb, ha normális fájlkelezővel csinálom, és nem shelles gányolással, meg rugalmasabb is, mivel én választom ki előre a célmappát is.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Kösz, ezt ki fogom próbálni. Elég sokféle formátumra felkészítetted. Pl. .jar, .ace, .lha, .zoo fájlokkal utoljára még DOS alatt találkoztam, de rég volt. Az .alz, .a, .ar, .uha formátumokról még nem is hallottam.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

pedig az .a a statikus libraryk, az .ar a deb csomagok formatuma is...

az ace/lha/zoo meg mostanaban nagyon divatos email malware-k eseten, mert a winzip es tarsai kinyitjak, de mivel 20+ eves formatumok, a mai viruskergetok nem ismerik.

en most pont olyan programon dolgzom, ami ezekbe belemaszik es kielemzi mennyire kockazatos... jo moka :(

en most pont olyan programon dolgzom, ami ezekbe belemaszik es kielemzi mennyire kockazatos... jo moka :(

Minek? Ha ma mar csak virusok hasznaljak a formatumot, elemzes nelkul torolheto.

Egy idoben sok heber nyelvu spamet kaptam. Ne tudom, miert, nem beszelem a nyelvet, es szarmazasomat tekintve is nagyon mellelottek. A karakterkeszlet (ill. akkoriban a karakterkodolas, meg nem volt annyira elterjedt a unicode) alapjan konnyen ki tudtam dobni oket. Persze ha kapnek legitim, heber nyelvu leveleket is, akkor jobban kene elemezni.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

hat az ace/lha igen, az 100% virus, de vannak zip-ben, rar-ban es 7z-ben is, es ott mar nem annyira egyertelmu, meg most epp a pdf parseren dolgozom... tudtad, hogy pdf-be lehet javascriptet, es url-eket is elrejteni? es le is fut illetve letolti az url-rol az embedded remote objectet megnyitaskor az acrobat? vagy hogy rtf-be is lehet OLE objektumot tenni? meg xlsx-be is? es OLE-ban meg lehet VBA vagy pl. az egyenletszerkeszto bugjat kihasznalo exploit?  en eddig legalabbis biztonsagosnak hittem a pdf es rtf attachmenteket...

Sztem amiota a winampban az mp3 metainformacioit feldolgozo kodban volt egy buffer overrun hiba (90-es evek), es ezt ki is lehetett hasznalni kodfuttatasra, mar kb. mindennel lehet problema. Az xlsx mondjuk a makrovirusok miatt talan problemasabb (de lehet, hogy ma mar ez kevesbe gond). Az AAPL meg a Unicode-ot szopja be rendszeresen, fura karakter meg lehet a Wifi neveben, SMS-ben, chaten, akarmin. Ilyen szempontbol a fileformatum kevesbe erdekes.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

A statikus .a libeket ismerem, itt feltételeztem, hogy nem erről van szó, hanem valami tömörített formátumról.

Ezt az ace, lha, zoo-ról nem tudtam, érdekes. Nekem e-mailben sem jön ilyen. A WinZip és társain is csodálkozok, mert a legtöbb gépen már nincs is olyan, azt utoljára a Win9x-es korszakban tették fel zömmel ez emberek, mikor még Winamp volt a divat. De mióta az XP óta be van építve alapvető zip-kezelés a Windowsokba, így nem nagyon tesznek már ilyet fel az emberek, kivéve a WinRar Matyik, de a WinRar meg nem támogatja azt a szóban forgó három formátumot. A 7-zip sem támogatja.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

a statikus libek .a formatuma egy tomoritett formatum, az 'ar' parancs szepen ki is bontja:

# ls
libmilter.a
# ar x libmilter.a
# ls
libmilter.a  milter.o  milter8.o  milter_macros.o

 

ahogy a .deb is ugyanilyen 'ar' tomoritmeny:

# ls
klmsui_8.0.3-30_amd64.deb
# ar x klmsui_8.0.3-30_amd64.deb
# ls
control.tar.gz  data.tar.gz  debian-binary  klmsui_8.0.3-30_amd64.deb

en anno Slackwaren at is irtam az mc-t, hogy a .deb-ekbe az ar-el nezzen bele, es ne dpkg-vel, mivel az ott nincs.

Kösz az infót, nekem ezek újdonságok. Eddig azt hittem, hogy az .a libek csak normál gépi kód/ELF binárisok, nem tudtam, hogy tömörítvények. A .deb-ről tudtam, hogy tömörítvény, de arról nem, hogy az is ar-t használ, pedig régről rémlik nekem is valami az ar-ről, hogy kellett egy .deb-hez használnom, akkor még Kubuntut és Mintet használtam, de azt nem tudtam, hogy van ilyen saját .ar formátuma is. Archon viszont régóta nem volt rá szükségem, sok éve. Vagyis ahogy nézem, most fent van Archon az ar, gondolom valami AUR-os program húzta be függőségnek (á, megvan, binutils csomagban van egy csomó GNU dev tool részeként), mert néhány AUR-os csomag valójában megadott URL-ről .deb-et húz le, és kibontja. Kevés ilyen van, de van, a progik többsége forráskódból fordul az AUR-ral.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

igen ilyenkor felülbírálja az egész system-wide configot. erre írtam h olyasmi lenne megoldás (amivel nem kell belenyúlni az mc kódjába), hogy ~/.config/mc/my-custom-menu -ben lenne a saját menupontjaid és csomag frissítéskor, vagy wrapper scriptből generálni a union configot pl:
cat ~/.config/mc/my-custom-menu /etc/mc/menu > ~/.config/mc/menu

Szerkesztve: 2021. 09. 01., sze – 21:48

Kitaláltam egy kőbaltás módszert az mc mindenáron angolul futtatására. (Linux Minten hiába próbáltam már mindenfélét, halott az ügy.)

Leforgattam a gittel letöltött forráskódot, majd az mc forráskönyvtárában lévő src könyvtárat átdobtam a /opt/-ba. Átneveztem mc-re a könyvtárnevet, hogy emlékezzek, mi a fene ez, és onnan indítottam az mc-t.

Angol lett. Kicsit ronda, de az pont nem érdekel. Tőlem akár pink is lehet... (Az azért mégse...)

Csináltam róla egy linket a /usr/local/bin-be és átneveztem az eredetileg apttal telepített mc-t.

Azóta angol minden gyorsbillentyűm.

Ha lefuttatnám a make installt, megmagyarítódna nekem... -- és ismét gőzöm sem lenne, mit kéne tenni vele.

(Kőbaltás módszerem elítélését jelen hozzászólás alá várom -- és már előre bólogatok, hogy igazatok van, marhaságot csináltam. De legalább fut.)

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

Van még egy LANGUAGE nevű egyéni lelemény GNU-specifikus bővítmény, annak meg az `unset` értéket javaslom.

https://www.baeldung.com/linux/locale-environment-variables

https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-vari…

átneveztem az eredetileg apttal telepített mc-t

Minek? A /usr/local/bin hamarabb van a PATH-ban, mint a /usr/bin, így akkor is a te változatod fog futni, ha nem nevezed át az eredetit, s akkor legalább nem lesz bajod frissítésnél.

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

Igazad van, előbb van a PATH-ban.

De így legalább nem találja meg a whereis, meg semmi egyéb... (saját skizofréniám)

Az eredetit egyébként le fogom zúzni, mert az még a régi libek alapján lett forgatva. Minek maradjon, ha az új mc az eredetinél újabb libekkel fut?

Amúgy már úgy működik, ahogy akartam. a hint és a help magyar, minden más angol.

---------------

Most épp azt próbálom kikeresni az mc forráskódjában, hogy a find dialógusdobozában miként tudom átírni a forráskódot úgy, hogy az alapértelmezett mező a kurzornak ne a jelenlegi, hanem a tőle jobbra lévő legyen.

Az F9 -c-f után nem a fájltípust szoktam kiválasztani, hanem azt, hogy MIT KERESEK BENNE. A jelenlegi melómat ez brutálisan begyorsítaná.

Szóval ebben van, amit keresek, de még nemtom, hol állítja be a dialógusdoboz alapértelmezett mezőjét.
/src/mc/src/filemanager/find.c

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.