Láma kérdés, mert ezidáig nem nagyon kellett X nélkül konzolos felületen matatnom. Most jó lenne vissza nézni a képernyő tartalmat. FreeBSD telepítésben vagyok még GUI nélkül.
A Ctrl S/Q azért kicsit más, mint a Scroll Lock. Azok a terminált állítják meg, meg indítják újra, inkább a Pause billentyűhöz hasonlít, de annak sem egészen felel meg.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Unless configured otherwise or in raw mode, Ctrl+S (DC3 in ASCII) and Ctrl+Q (DC1 in ASCII) can be used instead of Scroll Lock in Unix-likesystems to freeze and unfreeze the tty output respectively.
A unix terminál: stdin, stdout, stderr csatornákon keresztül működik. Mindegy, hogy konzolnak hívod vagy valódi soros terminál. A DOS is kb. ezt majmolja. Lényegében az stdin-en érkező ^X befolyásolja a kernel tty driveren keresztül az stdout működését.
Persze a működését befolyásolhatod az stty ixon stb. paranccsal. A helyzet nem ennyire egyszerű, mert pl. AIX alatt egy bemenő karakter 8, míg a kimenő karakter 6 map lehetőségen mehet keresztül. Nem beszélve arról, ha a terminál valamilyen pécén fut. Az utóbbi miatt létezhet speciális pécé billentyű, ami esetleg összezavarhat. Az alap mindig a DEC VT100/220.
A kedvencem a terminálos compose: Ctrl+. - ' - a == 'a = á, ahol a Ctrl+. == compose char. ;)
FreeBSD-konzolon a Linuxszal ellentétben az elsőként Mauzi által emlegetett ScrollLock utáni nyíl, PgUp/PgDn gombok működnek a ScrollLock újbóli megnyomásáig. És szintén ellentétben a Linuxszal, lehet váltogatni a virtuális képernyők között és nem veszik el a tartalom, mindegyik vtynek saját puffere van, ráadásul a puffer mérete módosítható.
Ellenben ha a ScrollLock-ot nem lehet kicsiholni a billentyűzetből, akkor sok lehetőség nincs, mint át kell definiálni a funkciót egy másik - elérhető - billentyű(kombó)ra.
Itt pont le van írva, hogy hogyan lehet átdefiniálni. Ő konkrétan a Ctrl + NumLock-ra programozza fel, ha jó képet találtam a billentyűzetedről, az akár még jó is lehet.
Az összes létező variációt végig próbáltam, amit a linken mutatnak. Lényegében ami működik, az a history visszaadása. Milyen parancsokat gépeltem be "addig".
Nekem az kellene, hogy egy hosszabb szöveges fájl tartalmát vissza tudjam olvasni az elejéig. Mintha egérrel vissza görgetnék terminálban.
Eddig a kepernyo tartalma kellett. File-ra a less vagy a more jo. Utobbi a "hagyomanyos", biztos fel van teve meg ilyen felig telepult rendszerre is. A less ennek a tovabbfejlesztett valtozata, ez vissza tud tekerni, meg egy csomo mindenben tobbet tud. Legtobb esetben elerheto, de nem mindig, emiatt a more-rol is jo tudni.
A strange game. The only winning move is not to play. How about a nice game of chess?
Most értettem meg én is mit akar a kérdező, csak egy elméleti kérdés: ezt amúgy mi indokolja? Én megnyitnám vim-ben aztán hadd szóljon ha fájlról van szó, lapozni ott is tudok, ha nem használok semmi mást, akkor is. Feltételezem a less/more inkább paraméterezve pipeline esetén hasznos leginkább, nem?
[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS
Megértem a kérdésed. Csupán csak egy-két konfigurációs fájlt szerettem volna végig nézni, a lokalizációt és billentyűzet kiosztást illetően. Párhuzamban olvastam a freebsd handbook-ot. Meg volt a rendszerem root-al és egy user-el.
Xorg-ot meg GUI-t szerettem volna telepíteni (fel is ment azóta), de ilyenek után mindig "elszaródik" lokális beállítás.
Érts úgy, hogy a fbsd telepítő snasszul lefut magyar nyelvi és billentyűzet beállításokkal. Csak miután xorg-ot meg de-t tolok rá, kezdhetek mindent előrről.
Ennyi. Konzolban szerettem volna szöveges konfig fájlokat olvasni, görgetni bennük.
Nem véletlen tettem oda a [LÁMA] jelzőt.
Nano-val tudok szerkeszteni, nem kell GUI. Viszont a vi/vim az sokkal messzebb van tőlem, mint Makó Jeruzsálemtől.
Ennyi. Konzolban szerettem volna szöveges konfig fájlokat olvasni, görgetni bennük.
Félreértettél, én nem mondtam hogy rosszul csinálod vagy hogy rossz ötletet írt volna bárki, csak hogy nekem személy szerint nem tűnik logikusabbnak mint akkor pl. esetedben nano-ban megnyitni a fált amit olvasni akarok.
[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS
A less alapvetően vi/vim-billentyűkkel működik, de érti a kurzormozgató billentyűket is, nyilak, PgUp/Dn, End, stb..
FreeBSD-n még jól jártál, mert az konzervatív, engedi ezt a Scroll Lock-trükköt tty-ban, ami Linuxon az 5.9 és újabb kerneleken le van tiltva. Utóbbiaknál a less, more, bat, vi/vim, screen, tmux, stb. szolgál arra, hogy visszagörgess. A nano is elég, ha fájlokat szeretnél megnézni. FreeBSD-n van egy másik text editor is alaptelepítésben, az easy editor, amit az ee vagy edit paranccsal tudsz meghívni.
Amit még tilos, hogy cat fájl | less módon használd a less-t. Azért asztalborogatás jár azonnal. Helyette: less fájl.
A vi vagy vim megtanulásának az előnye, hogy a vi az ed-del együtt a POSIX kompatibilitás miatt minden rendszeren elérhető, kivéve néhány különc, pl. Arch, ahol nincsenek fent, csak ha kifejezetten feltelepíted őket. Plusz a vi-os billentyűket sok szoftver érti, Bash, (k)sh, less, tmux, bat, meg még van egy rakat. Elsőre agyrém megtanulni, de utána sok mindenhez hasznos. Sok tiling ablakkezelőnek is vi/vim-szerű a kiosztása. Ha megtanulsz vi-jul, egy egész univerzumot kinyithat, egyfajta univerzális interface formájában.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
> Amit még tilos, hogy cat fájl | less módon használd a less-t.
Persze ez a tilalom csak hiszti, nem érdemes törődni vele. Sőt, ha megszokjuk ezt a formát, könnyebben jutnak eszünkbe olyanok, mint a cat program -v meg -n opciói, vagy az xzcat file.xz | less lehetősége.
A "tilos" része pedig ugyanaz, mint a világ minden egyéb helyén: az erőforrást nem pazaroljuk. Pont.
Kicsit olyan ez, hogy van aki érti, hogy miért gyűjtik egyesek szelektíven a szemetet, van aki nem. Van aki érti, hogy egyesek miért mondanak le a repülésről (és vonatoznak helyette)környezetvédelmi okokból, mások azt se fogják fel, hogy ha teljes gőzzel megy a légkondi, akkor ne nyissa ki az ablakot. Lehet a végtelenségig sorolni a jobb-rosszabb hasonlatokat. Általában azt tartják, hogy könnyebb a rossz (kevésbé jó) megoldást meg se tanulni (hanem helyette a jobbat), mint később tudatosan leszokni a rosszról. Pláne le se szokni.
Ilyenkor mindig eszebe jut a vicc, amit természetesen nem tudok pontosan idézni. ;)
Amerikában egy felhőkarcoló 100. emeletén ott áll a felirat:
Emberek! Ne dohányozzatok! Ne feledjétek a nagy San Francisco-i tűzvészt!
Egy tréfás kéz aláirta:
Emberek! Ne köpködjetek! Ne feledjétek a Mississipi 18..-es áradását.
Egyébként is, ilyen parancsokat legalább POWER5-ön érdemes futtatni, mert ott 100% a context swich átlapolása. Esetleg a parancs futhat több core-on és akkor még gazdaságosabb! Egyébként is, a less helyett érdemesebb használni a more-t, mert az egyszerűbb program - így kevesebbet fogyaszt. Egy jó rendszeren, ha sorbakötsz 50db cat-ot, akkor észre sem veszed a lassulást. Ha szerinted nem így van, akkor itt az idő AIX-re váltani! Ez az erőforrás pazarlásos duma pont olyan, mont a régi szakirodalomban a a loadavg legyen <<10. Amihez mindig hozzáteszem: az akkori CPU-kon.
A régi szakirodalomra hivatkozás garantáltan hibás, ugyanis a processzor "akkori" tulajdonsága mellett valószínűleg legalább annyira számít a *számossága*. Én speciel úgy ismerem, hogy numproc * 4.
- Aztán megakadtam minden UNIXosok bibliájánal: Maurice Bach: The Design of the UNIX Operating System. Első kiadás '86-ból. Ez már talán elég régi ahhoz, hogy megnyugodhassunk, hiszen már ebben is van szó többprocesszoros UNIX rendszerekről.
Szóval nem tudom mit akartál mondani, de kb. semmit se sikerült.
Egyet árulj el nekem: mi a baj azzal, ha felhívjuk a figyelmét egy - gyaníthatóan - kezdőnek arra, hogy vannak jó és kevésbé jó megoldások ugyanarra a problémára?
Nevemteve "cat -v" -je hasznos (mondjuk én "cat -teve" -ként szoktam javasolni megszokni - a redundáns 2 db "-e"-vel együtt is szerintem könnyebb így memorizálni); a "cat f1 f2 f3 f4 ... | xxx" forma is hasznos, de fenntartom azt a véleményemet, hogy a cat egy_darab_valami | more (vagy less, vagy pg vagy ...) az simán csak trehányság, és *SZERINTEM* nem ad semmit pluszt a "more egy_darab_valami" -hez képest. És hogy még egy mély bölcsességet hozzátegyek. Sajnos vannak parancsok, amelyek nem fogadnak el feldolgozandó paraméterként fájlnevet; pl. klasszikusan ilyen a "tr". Akkor sem az a helyes megoldás, hogy "cat valami | tr", hanem az, hogy "tr < valami" . De nehogy bárkit megsértsek: nem "helyes", hanem "kevesebb erőforrást igényló". És mivel általánosságban az igaz, hogy a meglevő erőforrások pazarlásánál jobb azokat értelmesebb dolgokra használni, megfontolandó lehet 2 funkcionálisan azonos megoldásból az olcsóbbat (s egyben kevesebb gépelést is igénylő) formát használni.
Probalgataskor szoktam "cat valami|parancs" format hasznalni. Egyreszt azert, mert igy rendezettebb a formaja, es mindig csak a veget kell atirni. Masreszt a vegen nem biztos, hogy file-bol jon az input.
Pl.: Van valmi oldal, onnan akarok valamit kiszedni (jo, erre mostanaban inkabb bs4-et vagy seleniumot hasznalok, de regebben siman ment bashbol). Akkor letoltom curl-lel/wgettel egy fileba, aztan:
cat lementett.html|less # megnezzuk hogy nez ki, aztan atirom a veget:
cat lementett.html|grep bizbasz # hopp, ez hosszabb, mint vartam..
cat lementett.html|grep bizbasz|less # ok, hany darab is van abbol?
cat lementett.html|grep bizbasz|wc -l # alakul.. eleg lesz nekem az elso
cat lementett.html|grep bizbasz|head -n 1 # stb.
...
cat lementett.html|grep bizbasz|... # tokeletes!
curl "$url"|grep bizbasz|... # aztan ez lesz a vege, ami bekerul a scriptbe
Persze ez akkor is mukodik, ha nem webrol jon az input, hanem valami parancs vagy script az, de sokaig fut, es probalgataskor nem akarom ujrafuttatgatni. Mindenesetre kenyelmesebb cat-tel, mint egyszer a less-el etetni meg, aztan a greppel, aztan ha az nem jo, esetleg a 3. programmal ami esetleg nem is eszik filenevet, vagy csak valami kulon kapcsoloval. Futasidoben/eroforrasban meg nem ez fog szamitani.
A strange game. The only winning move is not to play. How about a nice game of chess?
Sajnos Nyosigomboc szinte szóról szóra leírta amit én is írtam volna.
Másrészről a cat nem más, mint egy mindenáteresztő filter és nem az ördögtől való. Alkalmazása nem erőforrászabáló, jómagam is alkalmazom akár bomyolultabb pipeline közepében is, akár nagymennyiségű adat feldolgozása közben. Ezek olyan esetek, amikor oda kell tenni valamit, ami csak átereszti a bájtokat. Alkalmazása nem különb. mint a pipe használata. És pont ez a szép a unix filozófiájában, hogy már mindent megírtak csak össze kell kapcsolni a kész programokat. A mindent megírtak alatt nem szeretném azt állítani, hogy pozitívnak tartom a GNU awk fícsöreit, miszerint vérpistike belerakta a csillagászati számításokra és a mélytengeri merülésre is optimalizált kiegészítéseket.
"cat valami | tr", hanem az, hogy "tr < valami"
Na, pont erről beszélek! De ez az okoskodás legfeljebb a parancsok kézi próbálgatására jó. A való világban általában van egy "előző program", tehát a harmadik alak a tipikus: "valami | tr".
Nem állítottam, hogy korábban (legyen a határ '90) mem léteztek többprocesszoros számítógépek vagy többprocesszoros UNIX rendszerek. Viszont a numproc paraméter (core count vagy virtual processor count) nem igazán létezhetett és nem volt értelmezhető akkoriban. Ennek egy nagyon egyszerű oka van: a hardver. Akkoriban nem létezett multicore arch, de egy 8086 bus arbiter sem pont úgy működött, mint egy 860 vonalas fabric bus. Sőt még az IBM is készített egy tanulmányt, hogy 8 CPU felett az SMP nem gazdaságos. Nem sokkal később 32 CPU összeragasztásával nyerték sorra az adatbázisversenyeket. ;) Bár voltak igazán multiprocesszoros gépek amiken biztosan elfutkározott volna még a linux is - már ha létezett volna. Vagyis akkoriban abszolút nem volt tipikus egy többprocesszoros UNIX gép, de ha létezett is, a numproc értelmezése a mai hardverek alapján igen nehéz lett volna.
Van egy javaslatom. Ha szerinted a "p1 | p2 | cat | p3" parancssorozatban helyénvaló az opciók és egyéb paraméterek nélküli cat (*),
- akkor használd így igazad boldog tudatában, hisz nem erőforrászabáló - amiben egyetértünk. Esetleg javasolnám továbbfejleszteni "p1 | cat | p2 | cat | p3 | cat" alakra, extrém esetben pirosbetűs ünnepeken még az elejére is biggyessz oda egy fölösleges "cat | "-ot;
- cserébe kérlek ne tanítsd kezdőknek és ne javasold senkinek, ugyanis erőforráspazarló
Ha pedig nem tűnik fel, hogy teljesen másról próbálsz meggyőzni (vagy mi a fene is akar ez lenni), mint amit mondtam, azt betudom éltes korodnak.
(*) a spéci opciók, vagy extra fájlnév paraméterek esetén én magam is leírtam, hogy helyes cat-et használni - a hozzászólásban, amire válaszoltál
Ui: Ez lemaradt:
"Ezek olyan esetek, amikor oda kell tenni valamit, ami csak átereszti a bájtokat."
Speciel a pipe pont erre való, de lelked rajta, bonyolítsd.
InsertTimestamp()
{
print -n $1 |
case ${2:-N} in
N)
cat
;;
S)
sed 's/.log$/_??????????????.log/'
;;
D)
sed 's/.log$/_????????.log/'
;;
R)
if ParamExists wide_backup_timestamp
then
sed 's/\(\.BAK\|\.TRN\)$/_????_??_??_??????_???????\L\1/;s/\(_tlog_\|_db_\)/_backup_/'
else
print -n $1|sed 's/\(\.BAK\|\.TRN\)$/_????????????\1/'
fi
;;
X)
sed 's/.log$/-???????????????.log/'
;;
*)
cat
;;
esac
}
SetParam $File.filename $(Cygpath $(InsertTimestamp $(ReadReg $(GetParam $REGISTRY_PATH $SYSTEM)) $(GetParam $TIMESTAMP.$File $SYSTEM)))
Itt egy példa arra, amit el sem tudsz képzelni. :-D Egy pipeline két helyen is tartalmazza a cat-ot. Az utolsó sor példa a felhasználásra.
A függvény a linux alatt filesystemben leképzett Windows registry-ben tárolt fájlnév patternbe illeszt be egy timestamp értéket az aktuális adattípusnak megfelelő módon. Ráadásul az elején szereplő print -n alias cat -n. Persze még a sed is kiutálható a parancsból.
Személy szerint a case-beli N és * mintákat egybevonnám N | * ) formában, deazonbanplánesőt eszembe nem jutna egy külső parancsot egy mást csináló külső parancsra ráaliasolni (különös tekintettel arra, hogy a sokak által lesajnált ksh-ban implementáció függő módon a print még csak nem is külső, hanem vagy belső parancs, vagy az echo aliasa), de ezek apróságok. (*)
Azt mondjuk nem értem, hogy az R esetén mi a bánatnak van az if hamis ágában megismételve a "print -n $1 | " a sed előtt, ha az igaz ágban meg nincs, hanem feldolgozod amit a legelején állítasz elő - de elmém bölcsességedet átlátni képtelen.
Ettől még előző megjegyzésben említett javaslatomat fenntartom.
(*) javaslom még a print cat alias mellé az alias ln "ln -s" (megtörtént), és a neten kerengő egyéb #Happydebuggingsuckers megoldásokat is alkalmazni az éppen aktuális nyelv függvényében. Ezzel lehet igazán nélkülözhetetlenné válni.
Jogosak az észrevételeid. A printet tévesen catnak írtam. A print az AIX gyökerek miatt kerüllt oda, mert ők nem támogatják az echo használatát. A megismételt print nyilvánvalóan az egér bosszúja. :-D Elméletileg igazad van az összevonásban. Logikailag meg N|*==*, ez is igaz. Az N különállása mégis szükséges a karbantarthatóság miatt. Az a cél, hogy az N-re (addattípus) vonatkozó tevékenységek álljanak kükön a program minden szakaszában. Nem szabad úgy gondolkodni, mint a C fordító, mikor a switch elemeire felállít egy De Morgan táblát és csak a megoldást alakítja kóddá. Sok esetben jobb, ha minden töredelmesen le van írva - ezzel áttekinthetőbb a program, nem kell fejben dekódolni a jelentését. Igaz, elméletileg futhat lassabban. * Pont ilyenen szoktam vitatkozni egy kollégával. Szerinte egy változó mindig legyen a program elején inicializálva. Szerintem meg elegendő az if/else ágakban értéket adni, mert ebben az esetben pontosan látod, hogy mi történik az egyes ágakban. Tehát felesleges az X=0 deklaráció, ha a felhasználás hekyén úgy is 1 és 3 lesz az értéke. A lényeg: Minden ekőforduló esetre gondosan értéket kell adni. Ha nem így van, azon az inicializálás nem segít.
*Ez egy napi 90M processzt indító rendszer. Hiába az összevonás, a sok felesleges cat és társai kigyomlálása, mert nettó 30TB adatot kezel ~25M tömörített darabban. És nem is a diszk a szűk keresztmetszet, hanem a log és a tranzakciók diszkre kerülése és lockolása.
Az ln -s megoldást támogatom, mert a hardlink már úgy sem trendi. ;)
A kérdező esetére: természetesen az is jó megoldás, amit te írsz, ilyen esetben már egyéni preferencia kérdése. Ahol lehet, vimet használok, de ha gyorsan meg akarok nézni valamit, less-szel szoktam belenézni. Pontosan nem tudnám megindokolni, de talán azért, mert picit gyorsabb. :)
Igen, én is gyorsan szerettem volna megnézni valamit. Ilyenkor terminálban a cat parancsot használom, ott meg tudok görgetni egérrel. Most konzolon is automatice jött a cat, csak nem tudtam hogyan görgessek. Így jött a láma kérdés. Szövegszerkesztővel nem akartam nyitogatni a fájlokat.
A less oké, az működik, hosszabb szöveges fájlok gyors átolvasásához.
Ami nem, az a képernyő tartalom vissza lapozása. Pl. egy inxi -Fxx kimenet jóval hosszabb, mint ami a képernyőre kifér.
Terminálban ez egyszerű egérrel, itt most konzolon semmi nem működik a javasoltakból.
és képernyőnként írja ki. Azt hiszem, visszafelé lapozni nem lehet, de ez a konzol tulajdonsága: ha leporellóra gépelős a konzolod, akkor a papíron vissza tudod nézni akár az egész hetet. :)
"Normális ember már nem kommentel sehol." (c) Poli
úgyrémlik az általános megoldás a "pager", ahogy nézem nálam a less-re symlink, de emlékszem olyanra ahol nem volt less, ott meg a more-ra volt symlink, szóval akkor a pager általánosságban működik (valamilyen szinten), mondjuk az ősidőkből rémlik a pg parancs, na az tényleg csak ezt tudta...
Igen, egyes programok (pl. a man(1)) a $PAGER nevű programot futtatják, ha a hívó nem felejtette el az `export PAGER=$(which less)`-t beletenni valamilyen profile-ba.
Sőt, Linuxon se. Mármint, egyes grafikus terminál emulátorokban lehet, de a konzolon nem.
ctrl-shift-up/down sosem volt szerintem, ctrl-pgup/down helyett shift-pgup/down volt, de az utóbbi időben már ez sincs, a scrollback puffer feature-t kidobták.
Offtopik kicsit, de ha konzol kérdés, akkor nézd majd meg a tmux-ot. Most ezt a jó videót találtam: https://www.youtube.com/watch?v=nTqu6w2wc68 de van fent több is a YT-on.
Hozzászólások
Scroll Lock a barátod
:-) Magyar 102 gombos HP noti billentyűzet. Jól van beállítva, Scroll Lock-ot nem látok rajta. :-)
Ha esetleg elárulod a notebook pontos típusát, segíthetünk megkeresni rajta a Scroll Lock-ot...
Wikipedia ezt mondja:
https://en.wikipedia.org/wiki/Scroll_Lock
HP ZBook 17 G3
Az Fn+C nem működik?
A ZBook 17 G3 leírása nem ír a Scroll Lock-ról, de egy vele egy termékcsaládba tartozó másik, hasonló modellnél írják az Fn+C -t.
Nincs semmi reakció.
Itt pl. fn + jobb shift-et emleget valaki egy HP-s laptopra.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Bingó :-) Köszi szépen. Fel-le nyilakkal lehet "görgetni" a képernyőt, amíg meg nem nyomom újra. Ezután vissza vált a history-ra.
Működik. Tegnap elbénáztam valamit. Sorry.
Köszi szépen.
A scroll lock/unlock == ctrl S/ ctrl Q, ami nem más, mint az xon/xoff.
Legalábbis *nix terminálon, de asszem még DOS alatt is működik.
Az egéren nincs ilyen. :-D
A Ctrl S/Q azért kicsit más, mint a Scroll Lock. Azok a terminált állítják meg, meg indítják újra, inkább a Pause billentyűhöz hasonlít, de annak sem egészen felel meg.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Forrás: https://en.wikipedia.org/wiki/Scroll_Lock (kiemelés tőlem)
A unix terminál: stdin, stdout, stderr csatornákon keresztül működik. Mindegy, hogy konzolnak hívod vagy valódi soros terminál. A DOS is kb. ezt majmolja. Lényegében az stdin-en érkező ^X befolyásolja a kernel tty driveren keresztül az stdout működését.
Persze a működését befolyásolhatod az stty ixon stb. paranccsal. A helyzet nem ennyire egyszerű, mert pl. AIX alatt egy bemenő karakter 8, míg a kimenő karakter 6 map lehetőségen mehet keresztül. Nem beszélve arról, ha a terminál valamilyen pécén fut. Az utóbbi miatt létezhet speciális pécé billentyű, ami esetleg összezavarhat. Az alap mindig a DEC VT100/220.
A kedvencem a terminálos compose: Ctrl+. - ' - a == 'a = á, ahol a Ctrl+. == compose char. ;)
Shift+page up-ra emlekszem, de lehet, hogy FreeBSD-n mas. De eleg rovid a history tipikusan, meg ha eltekersz masikra, akkor talan torli is.
A strange game. The only winning move is not to play. How about a nice game of chess?
FreeBSD-konzolon a Linuxszal ellentétben az elsőként Mauzi által emlegetett ScrollLock utáni nyíl, PgUp/PgDn gombok működnek a ScrollLock újbóli megnyomásáig. És szintén ellentétben a Linuxszal, lehet váltogatni a virtuális képernyők között és nem veszik el a tartalom, mindegyik vtynek saját puffere van, ráadásul a puffer mérete módosítható.
Ellenben ha a ScrollLock-ot nem lehet kicsiholni a billentyűzetből, akkor sok lehetőség nincs, mint át kell definiálni a funkciót egy másik - elérhető - billentyű(kombó)ra.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Itt pont le van írva, hogy hogyan lehet átdefiniálni. Ő konkrétan a Ctrl + NumLock-ra programozza fel, ha jó képet találtam a billentyűzetedről, az akár még jó is lehet.
https://lists.freebsd.org/pipermail/freebsd-questions/2007-September/15…
(Még az is lehet, hogy egyszerűen a kbdctrl -f opciója lehet erre jó, most nem tudom kipróbálni.)
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
scroll-lock?
up/down - pageup/down
scroll-lock
https://unix.stackexchange.com/questions/60382/how-to-scroll-in-a-termi…
Az összes létező variációt végig próbáltam, amit a linken mutatnak. Lényegében ami működik, az a history visszaadása. Milyen parancsokat gépeltem be "addig".
Nekem az kellene, hogy egy hosszabb szöveges fájl tartalmát vissza tudjam olvasni az elejéig. Mintha egérrel vissza görgetnék terminálban.
Azt a `less(1)` csinálja.
Eddig a kepernyo tartalma kellett. File-ra a less vagy a more jo. Utobbi a "hagyomanyos", biztos fel van teve meg ilyen felig telepult rendszerre is. A less ennek a tovabbfejlesztett valtozata, ez vissza tud tekerni, meg egy csomo mindenben tobbet tud. Legtobb esetben elerheto, de nem mindig, emiatt a more-rol is jo tudni.
A strange game. The only winning move is not to play. How about a nice game of chess?
Sorry! Félreérthetően fogalmaztam. Egy olyan szöveges fájlban szeretnék visszagörgetni, ami nem fér ki a képernyőre.
Erre jó a less. Beírod, hogy
less fájlneve
és fel-le nyíllal görgetsz, pgup, pgdn segítségével lapozol, /-rel keresel, q-val kilépsz. :)
Most értettem meg én is mit akar a kérdező, csak egy elméleti kérdés: ezt amúgy mi indokolja? Én megnyitnám vim-ben aztán hadd szóljon ha fájlról van szó, lapozni ott is tudok, ha nem használok semmi mást, akkor is. Feltételezem a less/more inkább paraméterezve pipeline esetén hasznos leginkább, nem?
[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS
Megértem a kérdésed. Csupán csak egy-két konfigurációs fájlt szerettem volna végig nézni, a lokalizációt és billentyűzet kiosztást illetően. Párhuzamban olvastam a freebsd handbook-ot. Meg volt a rendszerem root-al és egy user-el.
Xorg-ot meg GUI-t szerettem volna telepíteni (fel is ment azóta), de ilyenek után mindig "elszaródik" lokális beállítás.
Érts úgy, hogy a fbsd telepítő snasszul lefut magyar nyelvi és billentyűzet beállításokkal. Csak miután xorg-ot meg de-t tolok rá, kezdhetek mindent előrről.
Ennyi. Konzolban szerettem volna szöveges konfig fájlokat olvasni, görgetni bennük.
Nem véletlen tettem oda a [LÁMA] jelzőt.
Nano-val tudok szerkeszteni, nem kell GUI. Viszont a vi/vim az sokkal messzebb van tőlem, mint Makó Jeruzsálemtől.
Sorry
:-)
Félreértettél, én nem mondtam hogy rosszul csinálod vagy hogy rossz ötletet írt volna bárki, csak hogy nekem személy szerint nem tűnik logikusabbnak mint akkor pl. esetedben nano-ban megnyitni a fált amit olvasni akarok.
[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS
No problem. A nano-t ismerem ilyenekre, meg a cat parancsot.
Hobby linuxos, hobby bsd-s vagyok.
A less alapvetően vi/vim-billentyűkkel működik, de érti a kurzormozgató billentyűket is, nyilak, PgUp/Dn, End, stb..
FreeBSD-n még jól jártál, mert az konzervatív, engedi ezt a Scroll Lock-trükköt tty-ban, ami Linuxon az 5.9 és újabb kerneleken le van tiltva. Utóbbiaknál a less, more, bat, vi/vim, screen, tmux, stb. szolgál arra, hogy visszagörgess. A nano is elég, ha fájlokat szeretnél megnézni. FreeBSD-n van egy másik text editor is alaptelepítésben, az easy editor, amit az ee vagy edit paranccsal tudsz meghívni.
Amit még tilos, hogy cat fájl | less módon használd a less-t. Azért asztalborogatás jár azonnal. Helyette: less fájl.
A vi vagy vim megtanulásának az előnye, hogy a vi az ed-del együtt a POSIX kompatibilitás miatt minden rendszeren elérhető, kivéve néhány különc, pl. Arch, ahol nincsenek fent, csak ha kifejezetten feltelepíted őket. Plusz a vi-os billentyűket sok szoftver érti, Bash, (k)sh, less, tmux, bat, meg még van egy rakat. Elsőre agyrém megtanulni, de utána sok mindenhez hasznos. Sok tiling ablakkezelőnek is vi/vim-szerű a kiosztása. Ha megtanulsz vi-jul, egy egész univerzumot kinyithat, egyfajta univerzális interface formájában.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
> Amit még tilos, hogy
cat fájl | lessmódon használd aless-t.Persze ez a tilalom csak hiszti, nem érdemes törődni vele. Sőt, ha megszokjuk ezt a formát, könnyebben jutnak eszünkbe olyanok, mint a
catprogram-vmeg-nopciói, vagy azxzcat file.xz | lesslehetősége.Khm...xzless...khm ;)
A "tilos" részét, persze, én is csak hisztinek tartom: kárt nem okoz és a parancssorrendőrség sem fogja rád törni az ajtót. :D
xz -dc filename.xz | less
Nagy eséllyel az xzless se csinál mást odabent.
A "tilos" része pedig ugyanaz, mint a világ minden egyéb helyén: az erőforrást nem pazaroljuk. Pont.
Kicsit olyan ez, hogy van aki érti, hogy miért gyűjtik egyesek szelektíven a szemetet, van aki nem. Van aki érti, hogy egyesek miért mondanak le a repülésről (és vonatoznak helyette)környezetvédelmi okokból, mások azt se fogják fel, hogy ha teljes gőzzel megy a légkondi, akkor ne nyissa ki az ablakot. Lehet a végtelenségig sorolni a jobb-rosszabb hasonlatokat. Általában azt tartják, hogy könnyebb a rossz (kevésbé jó) megoldást meg se tanulni (hanem helyette a jobbat), mint később tudatosan leszokni a rosszról. Pláne le se szokni.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Ilyenkor mindig eszebe jut a vicc, amit természetesen nem tudok pontosan idézni. ;)
Amerikában egy felhőkarcoló 100. emeletén ott áll a felirat:
Emberek! Ne dohányozzatok! Ne feledjétek a nagy San Francisco-i tűzvészt!
Egy tréfás kéz aláirta:
Emberek! Ne köpködjetek! Ne feledjétek a Mississipi 18..-es áradását.
Egyébként is, ilyen parancsokat legalább POWER5-ön érdemes futtatni, mert ott 100% a context swich átlapolása. Esetleg a parancs futhat több core-on és akkor még gazdaságosabb! Egyébként is, a less helyett érdemesebb használni a more-t, mert az egyszerűbb program - így kevesebbet fogyaszt. Egy jó rendszeren, ha sorbakötsz 50db cat-ot, akkor észre sem veszed a lassulást. Ha szerinted nem így van, akkor itt az idő AIX-re váltani! Ez az erőforrás pazarlásos duma pont olyan, mont a régi szakirodalomban a a loadavg legyen <<10. Amihez mindig hozzáteszem: az akkori CPU-kon.
Melléduma.
Szó sem volt lassulásról, ezt írtam le:
"erőforrást nem pazarlunk"
A régi szakirodalomra hivatkozás garantáltan hibás, ugyanis a processzor "akkori" tulajdonsága mellett valószínűleg legalább annyira számít a *számossága*. Én speciel úgy ismerem, hogy numproc * 4.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Igazából erre a részre nem reagált senki, szóval úgy veszem, hogy ezt elfogadhatjuk konszenzusnak:
> [ha a cat-tal kezdődik a parancssor, akkor] könnyebben jutnak eszünkbe olyanok, mint a
catprogram-vmeg-nopcióiPedig, ha pazarlod az erőforrásokat, attól nem szokott gyorsulni egyik gép sem. ;)
A numproc még a holdban volt, amikori irodalmakra gondoltam. Pl. az 50db cat-ot RS6000/53H (POWER1, 33MHz,1991) gépen mértem.
Itt egy konkrét szakkönyv: System Performance Tuning: Help for Unix Administrators (First edition:november 1990), bár a linken a 2002-es második kiadás látszik. Az első meg itt van a kezemben. ;)
Off: ha a performancia számít, akkor shell script helyett használjunk valódi programozási nyelvet, pl. awk-t vagy perl-t.
Ez jó! Mindegyik interpreteres. :-D
Van egy fordítási fázis az elején, de nem ez a fő előny, hanem az, hogy elmarad a végtelen+1 fork, ami a shell-scripting-gel jár.
Most riadtan a polchoz léptem, és lapozgatni kezdtem a különböző könyvekben.
- '98-as Sun performance tuning. Pfuj, túl új.
- '89-es 4.3BSD. Ez már jobb.
- Aztán megakadtam minden UNIXosok bibliájánal: Maurice Bach: The Design of the UNIX Operating System. Első kiadás '86-ból. Ez már talán elég régi ahhoz, hogy megnyugodhassunk, hiszen már ebben is van szó többprocesszoros UNIX rendszerekről.
Szóval nem tudom mit akartál mondani, de kb. semmit se sikerült.
Egyet árulj el nekem: mi a baj azzal, ha felhívjuk a figyelmét egy - gyaníthatóan - kezdőnek arra, hogy vannak jó és kevésbé jó megoldások ugyanarra a problémára?
Nevemteve "cat -v" -je hasznos (mondjuk én "cat -teve" -ként szoktam javasolni megszokni - a redundáns 2 db "-e"-vel együtt is szerintem könnyebb így memorizálni); a "cat f1 f2 f3 f4 ... | xxx" forma is hasznos, de fenntartom azt a véleményemet, hogy a cat egy_darab_valami | more (vagy less, vagy pg vagy ...) az simán csak trehányság, és *SZERINTEM* nem ad semmit pluszt a "more egy_darab_valami" -hez képest. És hogy még egy mély bölcsességet hozzátegyek. Sajnos vannak parancsok, amelyek nem fogadnak el feldolgozandó paraméterként fájlnevet; pl. klasszikusan ilyen a "tr". Akkor sem az a helyes megoldás, hogy "cat valami | tr", hanem az, hogy "tr < valami" . De nehogy bárkit megsértsek: nem "helyes", hanem "kevesebb erőforrást igényló". És mivel általánosságban az igaz, hogy a meglevő erőforrások pazarlásánál jobb azokat értelmesebb dolgokra használni, megfontolandó lehet 2 funkcionálisan azonos megoldásból az olcsóbbat (s egyben kevesebb gépelést is igénylő) formát használni.
offtopic vége
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Probalgataskor szoktam "cat valami|parancs" format hasznalni. Egyreszt azert, mert igy rendezettebb a formaja, es mindig csak a veget kell atirni. Masreszt a vegen nem biztos, hogy file-bol jon az input.
Pl.: Van valmi oldal, onnan akarok valamit kiszedni (jo, erre mostanaban inkabb bs4-et vagy seleniumot hasznalok, de regebben siman ment bashbol). Akkor letoltom curl-lel/wgettel egy fileba, aztan:
cat lementett.html|less # megnezzuk hogy nez ki, aztan atirom a veget:
cat lementett.html|grep bizbasz # hopp, ez hosszabb, mint vartam..
cat lementett.html|grep bizbasz|less # ok, hany darab is van abbol?
cat lementett.html|grep bizbasz|wc -l # alakul.. eleg lesz nekem az elso
cat lementett.html|grep bizbasz|head -n 1 # stb.
...
cat lementett.html|grep bizbasz|... # tokeletes!
curl "$url"|grep bizbasz|... # aztan ez lesz a vege, ami bekerul a scriptbe
Persze ez akkor is mukodik, ha nem webrol jon az input, hanem valami parancs vagy script az, de sokaig fut, es probalgataskor nem akarom ujrafuttatgatni. Mindenesetre kenyelmesebb cat-tel, mint egyszer a less-el etetni meg, aztan a greppel, aztan ha az nem jo, esetleg a 3. programmal ami esetleg nem is eszik filenevet, vagy csak valami kulon kapcsoloval. Futasidoben/eroforrasban meg nem ez fog szamitani.
A strange game. The only winning move is not to play. How about a nice game of chess?
Sajnos Nyosigomboc szinte szóról szóra leírta amit én is írtam volna.
Másrészről a cat nem más, mint egy mindenáteresztő filter és nem az ördögtől való. Alkalmazása nem erőforrászabáló, jómagam is alkalmazom akár bomyolultabb pipeline közepében is, akár nagymennyiségű adat feldolgozása közben. Ezek olyan esetek, amikor oda kell tenni valamit, ami csak átereszti a bájtokat. Alkalmazása nem különb. mint a pipe használata. És pont ez a szép a unix filozófiájában, hogy már mindent megírtak csak össze kell kapcsolni a kész programokat. A mindent megírtak alatt nem szeretném azt állítani, hogy pozitívnak tartom a GNU awk fícsöreit, miszerint vérpistike belerakta a csillagászati számításokra és a mélytengeri merülésre is optimalizált kiegészítéseket.
Na, pont erről beszélek! De ez az okoskodás legfeljebb a parancsok kézi próbálgatására jó. A való világban általában van egy "előző program", tehát a harmadik alak a tipikus: "valami | tr".
Nem állítottam, hogy korábban (legyen a határ '90) mem léteztek többprocesszoros számítógépek vagy többprocesszoros UNIX rendszerek. Viszont a numproc paraméter (core count vagy virtual processor count) nem igazán létezhetett és nem volt értelmezhető akkoriban. Ennek egy nagyon egyszerű oka van: a hardver. Akkoriban nem létezett multicore arch, de egy 8086 bus arbiter sem pont úgy működött, mint egy 860 vonalas fabric bus. Sőt még az IBM is készített egy tanulmányt, hogy 8 CPU felett az SMP nem gazdaságos. Nem sokkal később 32 CPU összeragasztásával nyerték sorra az adatbázisversenyeket. ;) Bár voltak igazán multiprocesszoros gépek amiken biztosan elfutkározott volna még a linux is - már ha létezett volna. Vagyis akkoriban abszolút nem volt tipikus egy többprocesszoros UNIX gép, de ha létezett is, a numproc értelmezése a mai hardverek alapján igen nehéz lett volna.
Van egy javaslatom. Ha szerinted a "p1 | p2 | cat | p3" parancssorozatban helyénvaló az opciók és egyéb paraméterek nélküli cat (*),
- akkor használd így igazad boldog tudatában, hisz nem erőforrászabáló - amiben egyetértünk. Esetleg javasolnám továbbfejleszteni "p1 | cat | p2 | cat | p3 | cat" alakra, extrém esetben pirosbetűs ünnepeken még az elejére is biggyessz oda egy fölösleges "cat | "-ot;
- cserébe kérlek ne tanítsd kezdőknek és ne javasold senkinek, ugyanis erőforráspazarló
Ha pedig nem tűnik fel, hogy teljesen másról próbálsz meggyőzni (vagy mi a fene is akar ez lenni), mint amit mondtam, azt betudom éltes korodnak.
(*) a spéci opciók, vagy extra fájlnév paraméterek esetén én magam is leírtam, hogy helyes cat-et használni - a hozzászólásban, amire válaszoltál
Ui: Ez lemaradt:
"Ezek olyan esetek, amikor oda kell tenni valamit, ami csak átereszti a bájtokat."
Speciel a pipe pont erre való, de lelked rajta, bonyolítsd.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Itt egy példa arra, amit el sem tudsz képzelni. :-D Egy pipeline két helyen is tartalmazza a cat-ot. Az utolsó sor példa a felhasználásra.
A függvény a linux alatt filesystemben leképzett Windows registry-ben tárolt fájlnév patternbe illeszt be egy timestamp értéket az aktuális adattípusnak megfelelő módon. Ráadásul az elején szereplő print -n alias cat -n. Persze még a sed is kiutálható a parancsból.
Meghajlok bölcsességed előtt.
Személy szerint a case-beli N és * mintákat egybevonnám N | * ) formában, deazonbanplánesőt eszembe nem jutna egy külső parancsot egy mást csináló külső parancsra ráaliasolni (különös tekintettel arra, hogy a sokak által lesajnált ksh-ban implementáció függő módon a print még csak nem is külső, hanem vagy belső parancs, vagy az echo aliasa), de ezek apróságok. (*)
Azt mondjuk nem értem, hogy az R esetén mi a bánatnak van az if hamis ágában megismételve a "print -n $1 | " a sed előtt, ha az igaz ágban meg nincs, hanem feldolgozod amit a legelején állítasz elő - de elmém bölcsességedet átlátni képtelen.
Ettől még előző megjegyzésben említett javaslatomat fenntartom.
(*) javaslom még a print cat alias mellé az alias ln "ln -s" (megtörtént), és a neten kerengő egyéb #Happydebuggingsuckers megoldásokat is alkalmazni az éppen aktuális nyelv függvényében. Ezzel lehet igazán nélkülözhetetlenné válni.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Jogosak az észrevételeid. A printet tévesen catnak írtam. A print az AIX gyökerek miatt kerüllt oda, mert ők nem támogatják az echo használatát. A megismételt print nyilvánvalóan az egér bosszúja. :-D Elméletileg igazad van az összevonásban. Logikailag meg N|*==*, ez is igaz. Az N különállása mégis szükséges a karbantarthatóság miatt. Az a cél, hogy az N-re (addattípus) vonatkozó tevékenységek álljanak kükön a program minden szakaszában. Nem szabad úgy gondolkodni, mint a C fordító, mikor a switch elemeire felállít egy De Morgan táblát és csak a megoldást alakítja kóddá. Sok esetben jobb, ha minden töredelmesen le van írva - ezzel áttekinthetőbb a program, nem kell fejben dekódolni a jelentését. Igaz, elméletileg futhat lassabban. * Pont ilyenen szoktam vitatkozni egy kollégával. Szerinte egy változó mindig legyen a program elején inicializálva. Szerintem meg elegendő az if/else ágakban értéket adni, mert ebben az esetben pontosan látod, hogy mi történik az egyes ágakban. Tehát felesleges az X=0 deklaráció, ha a felhasználás hekyén úgy is 1 és 3 lesz az értéke. A lényeg: Minden ekőforduló esetre gondosan értéket kell adni. Ha nem így van, azon az inicializálás nem segít.
*Ez egy napi 90M processzt indító rendszer. Hiába az összevonás, a sok felesleges cat és társai kigyomlálása, mert nettó 30TB adatot kezel ~25M tömörített darabban. És nem is a diszk a szűk keresztmetszet, hanem a log és a tranzakciók diszkre kerülése és lockolása.
Az ln -s megoldást támogatom, mert a hardlink már úgy sem trendi. ;)
Általánosságban: a szerkesztők több erőforrást használnak, és pl. a pipe-olt inputot jobban kezelik, főleg ha az folyamatosan keletkezik. Néhány fejtegetés itt: alias - are there side-effects to remapping/aliasing less to vim? - Unix & Linux Stack Exchange
A kérdező esetére: természetesen az is jó megoldás, amit te írsz, ilyen esetben már egyéni preferencia kérdése. Ahol lehet, vimet használok, de ha gyorsan meg akarok nézni valamit, less-szel szoktam belenézni. Pontosan nem tudnám megindokolni, de talán azért, mert picit gyorsabb. :)
Igen, én is gyorsan szerettem volna megnézni valamit. Ilyenkor terminálban a cat parancsot használom, ott meg tudok görgetni egérrel. Most konzolon is automatice jött a cat, csak nem tudtam hogyan görgessek. Így jött a láma kérdés. Szövegszerkesztővel nem akartam nyitogatni a fájlokat.
A FreeBSD-s fiúk néha igen viccesek tudnak lenni.
Pár régi fórum téma:
- https://forums.freebsd.org/threads/solved-scrolling-without-scroll-lock…
- https://forums.freebsd.org/threads/scrolling-back-without-scroll-lock-k…
Röviden: Fn+F6 vagy Fn+S vagy Fn+K segíthet. Laptopfüggő, sajnos.
Mondjuk ahol lehetett csak bal shift-el operaltam. A jobb shift-et nem is probaltam.
A less oké, az működik, hosszabb szöveges fájlok gyors átolvasásához.
Ami nem, az a képernyő tartalom vissza lapozása. Pl. egy inxi -Fxx kimenet jóval hosszabb, mint ami a képernyőre kifér.
Terminálban ez egyszerű egérrel, itt most konzolon semmi nem működik a javasoltakból.
És a more?
Mögé írod:
| more
és képernyőnként írja ki. Azt hiszem, visszafelé lapozni nem lehet, de ez a konzol tulajdonsága: ha leporellóra gépelős a konzolod, akkor a papíron vissza tudod nézni akár az egész hetet. :)
"Normális ember már nem kommentel sehol." (c) Poli
Esetleg így:
inxi -Fxx 2>&1 | less -SKésőbb kipróbálom.
Én ilyenkor beteszem egy fájl-ba. inxi -Fxx 2>&1 > kimenet.txt Majd less kimenet.txt
pch
SB-soft online ügyviteli rendszer
Nem feltétlen kell kirakni file-ba, elég bepipe-olni less-be ha nem kell később a kiemenet :)
kiskutyaparancs | less
Ez is jó. Köszi szépen.
Esetleg ránézhetnél a tee parancsra, amivel az egyes parancs kimenetét el lehet menteni fájlba, s majd azt listázni.
Pár alapvetés: https://youtu.be/DwfncFCrkHc?si=TJjOszlpfsCI1agB
AL
úgyrémlik az általános megoldás a "pager", ahogy nézem nálam a less-re symlink, de emlékszem olyanra ahol nem volt less, ott meg a more-ra volt symlink, szóval akkor a pager általánosságban működik (valamilyen szinten), mondjuk az ősidőkből rémlik a pg parancs, na az tényleg csak ezt tudta...
Igen, egyes programok (pl. a man(1)) a $PAGER nevű programot futtatják, ha a hívó nem felejtette el az `export PAGER=$(which less)`-t beletenni valamilyen profile-ba.
ctrl-shift-up/down
ctrl-pgup/down
Ez a pufferen belül, annak pedig nézz utána, hogy pufferméretet hol növelheted, ha kevés.
Linuxon, és X-es terminál emulátoroknál. FreeBSD konzol-driverben nem.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Sőt, Linuxon se. Mármint, egyes grafikus terminál emulátorokban lehet, de a konzolon nem.
ctrl-shift-up/down sosem volt szerintem, ctrl-pgup/down helyett shift-pgup/down volt, de az utóbbi időben már ez sincs, a scrollback puffer feature-t kidobták.
Offtopik kicsit, de ha konzol kérdés, akkor nézd majd meg a tmux-ot. Most ezt a jó videót találtam: https://www.youtube.com/watch?v=nTqu6w2wc68 de van fent több is a YT-on.
Zseniális dolog szerintem.
HP ZBook 17 G3
102 gombos magyar billentyűzet.
Scroll Lock=FN + jobb Shift
Scroll Lock=FN + C