Fórumok
Sziasztok. Léteznek gyors könyvtárak közötti navigálásra programok, mint a z.lua, autojump, zoxide stb. Esetleg tud valaki olyan programot, ami ugyanezen elven a szerkesztésre megnyitott fileokról készít adatbázist, és ugyanígy gyorsan meg lehet nyitni pár betű megadásával? A legjobb persze, ha mindkettőt tudná, tehát érzékelné, hogy a találat alapján az egy könyvtár, így beleugrik, vagy ha filenak érzékeli, akkor megnyitja mondjuk a $EDITOR-ban megadott programmal.
Akkor az ideiglenes megoldásra ez lett (aztán majd ha megcsinálja a zoxide vagy egyéb fejlesztő file-ra is, akkor váltok):
#!/usr/bin/bash
selection=$(find / -type f ! -path "/proc/*" ! -path "/mnt/*" 2>/dev/null | fzf --exact --multi --height=80% --border=sharp --color='fg+:red' \
--preview='batcat {}' --preview-window='45%,border-sharp' \
--prompt='Files > ' \
--bind='ctrl-d:reload(find / -type d ! -path "/proc/*" ! -path "/mnt/*" 2>/dev/null)' \
--bind='ctrl-d:+change-prompt(Dirs > )' \
--bind='ctrl-d:+change-preview(tree -C {})' \
--bind='ctrl-d:+refresh-preview' \
--bind='ctrl-f:change-prompt(Files > )' \
--bind='ctrl-f:+reload(find / -type f ! -path "/proc/*" ! -path "/mnt/*" 2>/dev/null)' \
--bind='ctrl-f:+change-preview(batcat {})' \
--bind='ctrl-f:+refresh-preview' \
--header '
CTRL-D to display directories | CTRL-F to display files
'
)
if [ -d "$selection" ]; then
cd $selection || exit
elif [ -f "$selection" ]; then
if sudo -u "$USER" test -w "$selection"; then
eval "nano $selection"
exit
else
eval "sudo nano $selection"
exit
fi
fi
Hozzászólások
Létezik. A neve fzf, tőled el is várnám, hogy ismered :D
Nyilván nem önmagában tudja ezt, bele kell tenni egy scriptbe. Én írtam erre egy megnyitó szkriptet, find vagy fd megkeresi a fájlokat (az előre bedrótozott mappákban), beadagolja az fzf-nek, azzal kiválasztom mit akarok megnyitni, ha nem üres karakterlánc, akkor feldolgozom. Ha mappa, akkor újranyitom a scripttel, ha fájl, akkor átadom egy fájlmegnyitó scripttel, ami case asec szerkezettel végigvizsgálja, hogy mi a kiterjesztés, és az alapján nyitja meg a hozzá való, preferált programmal.
Így villámgyorsan nyitok meg mindent. Sokszor fájdalmas is, mikor videókon átlag desktop usert látok, hogy GUI fájlkezelőkból meg GUI programokból milyen körülményesen nyitogat meg mindent, milyen lassan, meg mindent kitesz az asztalra. Közben meg az fzf ezt annyira meggyorsítja, hogy nem igaz. Mindegy neki, hogy hány mappa mélységben, hol van a cucc, 1-3 karakter, de legtöbbször csak 1-2 karakter után felismeri.
Beépíthető más szkriptekbe is, meg pl. Vifm-ben is bedrótoztam, hogy gyorsan mappába vagy fájlba ugorjak. vim-be, neovim-be is drótozható, de szerintem még micro-ba is be tudod tenni. Bashrc-be is csináltam egy cf nevű aliast, ami egy speciális fzf-et használó cd, azzal is nagyon gyors mappát váltani.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
:D Pont ezt akartam elkerülni, mert ez mindent végignéz, nem épít adatbázist, hogy mit mennyire gyakran nyitsz meg. Nekem meg az a módszer lenne az igazi, mint ahogy a zoxide, z.lua stb dolgozik :P
A cél ugyanaz a használat lenne, pl: z ext.c -> ez mondjuk megnyitná az extensions.conf-ot az asterisk mappában. Ez sokkal gyorsabb, mint hogy az fzf elkezdjen dolgozni a / mappában végig keresgélve, hogy mi felel meg neki.
Lf file managerbe amúgy beledrótoztam az fzf-et, de ott csak file/directory keresésre használom.
Akkor módosítod a scriptet, hogy indexeljen, ha nincs indexfájl. Tapasztalatom szerint ez nem szükséges, mert míg mindent átnéz, az az fd + fzf párosnak alig 1-2 mp., első indításkor, 2. indítástól kezdve, meg RAM cache-ből tolja ki azonnal, 0 mp. alatt.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Igen, csak mondjuk beírom, hogy ast, és talál vagy 100db találatot az fzf, míg mondjuk egy z.lua vagy zoxide csak a releváns találatot fogja automatikusan behelyettesíteni, mert frequency és age alapján is meg tudja mondani, hogy mit is akarhatok, és már ott is vagyok a megfelelő útvonalon, míg fzf esetén böngészhetek, hogy mi kell. És most ne home gépre gondolja, hanem adatbázis, web, voip szerverekre, ahol jócskán vannak cuccok, akár redundánsan is. Nem véletlenül írták meg a fent említett progikat.
Ez így van, ezt nem tudja, de azért enyhíthető ez a hiányossága. Ha az indexből nyitsz meg valamit, akkor azt előre teszed az indexfájlban (grep-pel kiszűröd, visszaírod egy új fájl elejére, a többi részét az indexnek hozzácsapod, átnevezed úgy indexnek). Így a leggyakoribb elemeket fogja elöl megjeleníteni. Nem teljesen ugyanaz, mint a zoxide, de valamennyit segít.
Esetleg én egy olyan scriptet is csináltam, ami find-dal kikeresteti az összes 60 percnél újabb fájlt, és abból nyit meg a script. Ez sem gyakoriság, de valamennyire age alapján szűrök ilyenkor. Vannak tehát praktikák, ha neked túl sok az fzf találata. Nekem nem az, mert 1-2 karakter után annyira jól leszűkíti magától is, hogy hozzá lehet szokni.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Ezt még feszegetném egy kicsit. A fzf-et le tudod szűketeni mappákra, akkor kevesebb találat lesz. Illetve ha az ast billentyűkre 100 darab találatot hoz fel, akkor rosszul keresel, meg kell tanulnod jól fzf-ezni. Próbálj más betűkombinációkat, ami jellemzőbb az adott mappára. Nem kell a karaktereknek egymás mellett sem lennie a keresett karakterláncban. Így szerintem a példádban, ha a+s+t helyett valami még jellemzőbb betűtöredékre keresel, akkor nem 100-ra, hanem csak 2-3-ra szűkíti mindjárt.
Persze, így se lesz olyan, mint a zoxide, de azért hagyományos megoldásokhoz képest még így is 100× gyorsabb lesz, és még tovább tudod gyorsítani azzal az indexelős, időbeli használatot is fegyelembe vevő módszerrel.
Ha neked ennyire hiányzik a zoxide-os működés, írj az fzf fejlesztőének egy issue / feature request bejegyzést a git tárolójához.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Nah próbáltam egy fzf-et, a legújabb-at ami még gyorsítva van a debianban levőnél, és gyökérből indítva a keresést (hiszen nem feltétlenül tudom az útvonalat ugyebár), baromi lassan találta meg. Nagyon sokat kellett várni, mire megtalálta amit kerestem.
De ezen semmi meglepő nincs. Több, mint 1 millió file van a szerveren...Ezt magyaráztam, de mindegy.
Próbáld meg az FZF_DEFAULT_COMMAND="fd -H . /" fzf formában, vagy fd -H . / | fzf formában hívni. Az fd egy Rust-ban átírt speciális find, általában bent van minden disztró tárolójában, feltelepíted csomagkezelővel, és nem attól lesz jó, mert rust-os, meg memory safe, hanem sokkal gyorsabb, mint a hagyományos core utils find. Egyszerűen jobban van optimalizálva, viszont cserében erőforrás-igényesebb is.
Mondjuk 1 millió fájlnál mindenképp el fog tartani, de mint mondtam, egy keresésnél kell csak kivárni, míg keresgeti a fájlokat, utána már a 2., 3., n. indításkor cache-ből egy pillanat alatt összeszedi ami kell, és ez tart addig, amíg a cache-t kényszerítetten el nem dobatod a kernellel, vagy a gépet újra nem indítod.
Esetleg azt is csinálhatod, hogy az fd, vagy find parancs kimenetét beleírod egy fájlba, és indexként használod, és csak ritkábban indexelgetsz (bele egy előkészített mappába, fájlba), mondjuk naponta vagy hetente egyszer, akkor újraindításokat is túlél. Ez az fzf egy rugalmas eszköz, bármi a bemenetébe pipe-olható, és a kimenete is tovább vihető egy másik parancs bemeneteként. Így igényel egy kis shellprogramozási tudást, de akármit megoldhatsz vele, mert lényegében egy svájci bicska. Mind a lassúságának a gyorsítása, mind az age/gyakoriság szerinti keresés elérhető vele.
Azt is csinálhatod, hogy ha nem kell mind az 1 millió fájl, hanem csak mappák, vagy bizonyos kiterjesztésű fájlok, akkor csak azokra keresel rá (lásd: man find és man fd) speciális kapcsolókkal, ez is tud gyorsítani rajta, külön index nélkül. Neked kell kitapasztalni, hogy hogyan lesz jó, a te géped, mi nem látunk oda, hogy mire keresel rá, hány találat van, mennyire szűkíthető. Senki nem fog gondolkodni helyetted, neked kell a saját workflow-dat optimalizálni.
Egy fontos tisztázandó: az fzf nem fájlkereső! Ez egy menüprogram, item selector, ami a bemeneteket listázza, és enged laza karakterekre rákeresni, szűrni, így dolgokat nem csak pontos keresési string meg nem csak regexp mágia alapján talál meg. Az megint más, hogy ha nem adsz meg neki paramétert, vagy környezeti változót, akkor alapból a find . parancsot futtatja le, és annak a kimenetét eszi meg, de ez átállítható. Vagy az FZF_DEFAULT_COMMAND környezeti változóban, vagy az fzf elé pipe-olva, pl.:
echo "egy\nkettő\nhárom\nnégy" | fzf
Kipróbáltam neked, nálam a gépen most a felcsatolt partíciókon összesen 974 ezer fájl van, ezt első indításkor az fd + fzf kb. 2 mp. alatt listázza be, de annyit se kell várni, mert folyamatosan tölti fel a listát, tehát az első képernyőt mindenképp azonnal az arcodba vágja, míg növeli a képernyő alján a nem látszó találatokat. Mire odajutsz, hogy gépelnéd be az első keresési karaktert, már kész is van. 2., 3. stb. indításkor meg kb. 0,1-0,2 mp. alatt végez. Azért azt ne mondd, hogy ez olyan lassú. Az is igaz, hogy ez combosabb gép, Ryzen 6800H, NVMe SSD, elég RAM, szóval nem kenyérpirító.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Spotlight ... :D
Gábriel Ákos
Rendes Linux-on Albert-nek hívják! :-DDD
/off
Egy időben használtam az Albert-et, aztán jött az ulauncher, az Albert meg ment is, azóta vissza sem néztem. Amire/ahogyan én használom mindenben jobb, érdemes ránézni.
Ha a history-ban keresel? Pl. ha a vim editort használod, akkor history | grep vim, és ezt adod át pl. az fzf-nek?
Erre is gondoltam, csak a baj az, hogy eredendően én nem akarok mindig listából kiválasztani valami, mert az még mindig lassú megoldás. Ráadásul felmerül az a gond is, hogy bash shell van használatban az összes szerveren, és az berakja a historyba az elgépelt parancsokat is (ez pl rohadt nagy hiányosság a zsh-hoz képest).
Szal ezért is keresek kifejezetten erre való progit, mert kvázi aliasolnia kellene a gyakran használt helyeket. A zoxide ezt nagyon jól csinálja, de csak könyvtárnévre mükszik.
Akkor hogyan szeretnéd? Ha "pár betű megadásával", akkor arra kell figyelned, hogy mindig egyértelmű legyen (különben jön a lista), és a "pár betű" meghatározása egyszerű legyen a fájl nevéből, különben többet gondolkozol a pár betűn, minthogy kiválasztanád a listából
Nem lenne jó és egyszerű kézzel alias-okat létrehozni azokra a fájlokra (ha már úgyis szóba került az alias), amiket gyakran szerkesztesz?
Nézd meg a Zoxide működési elvét (vagy a z.lua -t, githubon fent vannak). Akkor mindjárt érthető lesz, hogy mire gondolok, ezért is írtam a postnak az elején.
Az aliasok jók lennének, ha olyan 10-12db-ról lenne szó, de szerverekről van szó, ennél jóval többet kellene csinálnom, vagyis ez nem járható út.
Láttam a videót, de ott is, ha a betűkombináció nem egyértelmű, menüből kell választani.
Attól függ. Ha úgy indítja el. Ha nem, akkor semmilyen menü nem jön elő, hanem a program választja ki a legjobban hozzáillőt 2 féle minta alapján: 1. frequency , 2. ages alapján.
Ja, értem. És ha pont nem azt akartad, akkor kilép és újrapróbál :)
Nem tudom, mi lehet a megoldás, már csak azért sem, mert hogyan lehetne követni, ha egy fájlt megnyitsz, ez indexeled, és a szerkesztőből nyitsz meg egy másikat - ezt szerintem shellből nem olyan egyszerű elkapni, esetleg strace vagy valamivel követni, mik nyílnak meg.
Ha esetleg van valami "programozható" kritérium a fájlnévre (pl. *.txt), akkor akár a "last access time" segítségével is lehet indexet építeni. De ha lenne kész program (ami kb. a topik), engem is lehet, hogy érdekelne.
Albert laucher, ha jó GUI-s cucc, nem kifejezetten CLI-only megoldást keresel.
Egy csomó szabályt fel lehet venni, mit indexeljen, hol keressen, mi történjen a találattal különböző gombok megnyomására. Plugin-ekkel bővítható, így a keresősor követlenül is tud műveleteket végrehajtani.
Köszi az infót, de kifejezetten CLI-s megoldást keresek, mert szerver környezetben használnám, ergo besshzom, és csak terminal.
Most futottam bele, esetleg az atuin?
Köszi az infót. Megnéztem, és még akár jó is lehetne, de tele van felesleges funkciókkal, bonyolításokkal. Most van egy shell scriptem, ami 90%-ban működik. Egyedül a könyvtárváltást nem acceptálja valamiért. Ha sima parancsként nézem, akkor meg jó. Elég fura. Mondjuk sok időm nincs vele foglalkozni, mert közben dolgozni is kellene, este meg megint más programjaim vannak.
A shell-scriptek önálló processzben futnak. Abban nyugodtan válthatsz könyvtárat, attól az indító (szülő) processzben nem fog látszani.
Ha nagyon kell ez a funkció, akkor shell-függvényként töltsd be a scriptedet, és használd úgy - akkor menni fog. (Akár használhatsz "autoloaded function" megoldást is, akkor kizárólag akkor foglal memóriát, ha legalább egyszer lefuttatod.)
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Óóó basszus tényleg...Subshellben futnak ilyenkor, ezért nem látszik, és nincsen hibakód se :D Végülis csináltam rá egy alias-t, és source -al indítom el. Köszi!
Akkor az ideiglenes megoldásra ez lett (aztán majd ha megcsinálja a zoxide vagy egyéb fejlesztő file-ra is, akkor váltok):
Ha a find-ban előbb vannak a ! -path feltételek és csak utána a -type f, akkor a lehetőségekhez képest még optimalizáltál is - ezáltal némileg gyorsabb is lenne (és kevesebb erőforrást zabálna). Amúgy a find manualja explicit leírja, hogy alkönyvtárstruktúrát az általad használt -path forma helyett a -prune segítségével érdemes kihagyni, és azzal további gyorsulást lehetne elérni. Sajnos az már eléggé rusnya - más kérdés, ha nem naponta gépelgeted, hanem egyszer kell begépelni egy konfig fájlba, akkor akár lehet rusnya is:
find / \( -path /proc -o -path /mnt -prune \) -type f .....
Első ránézésre.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Thx. Kipróbáltam, de ezzel a módszerrel semmit se talál. Konkrétan semmilyen filet nem jelenít meg még úgysem, hogy nem szűrök.
Ja, persze a -prune miatt kell az a -print.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Módosítottam a leírás alapján és így már van találat, de nagyon nem veszi figyelembe, hogy file-t vagy könyvtárat akarok:
Tök mindegy hova írom a type -ot.
Szerintem vedd ki a -print elől a -o flaget (ugyanis ettől VAGY-kapcsolatba kerülnek, itt pedig ÉS kellene.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Átírtam, hogy könyvtárakat keressen, és kiderült, hogy így csak az mnt és proc könyvtárat találja meg, pedig pont az van kivételben :D
Nekem ez már jónak tűnik:
- zárójeles rész:
Ha /proc VAGY /mnt az épp vizsgált elem neve akkor ÉS kapcsolat a prune-nal (ami viszont mindig igaz) - e miatt ilyenkor nem megy a -o utáni részre, és a prune miatt ezt a két könyvtárat mindenestül kihagyja. (Ellentétben a -path /proc/* -gal, ami belemegy és minden rohadt fájlon ellenőriz)
- zárójel utáni rész:
A -o miatt csak akkor hajtódik vissza, ha ott nem futott rá a prune-ra, azaz minden egyéb fájlra és könyvtárra elkezd tesztelni. Ha az aktuális fájl közönséges fájl, akkor kiírja, egyéb esetben nem.
Márpedig szerintem neked pont az kell.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Már sokkal jobb, de a proc mappában levő fileokat továbbra is megtalálja. Úgy érzem a régi módszert sikerült annyira elbonyolítaniuk, hogy az valami elképesztő.
Esetleg elcsesztem, és nem -o hanem -or ? (Bár a gnu find maualja szerint a -or non-POSIX, és az eredetileg írt -o a jó.) Netán dupla zárójel a két -path köré ?
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Szerintem hagyd. A régi formátumban teljesen jól működik, és sokkal érthetőbb a szintaxisa. Egy ideig még úgyse fogják kivonni a "forgalomból".
Kihívás. Ugyan nem világos, hogy miért kell (ezt a felét még ki kell gyökölnöm), de végre meglett a megoldás.Ellenőrizve a FreeBSD saját (nem GNU-) findjával, a Linux alatt jellemzően használt findutils-beli GNU-find-dal (4.9.0) , a busybox-ba épített find-dal (v1.36.1) és egy Rust-ban implementált verzióval (0.4.2) . Szóval kell a dupla zárójel:
find / \( \( -path /proc -o -path /mnt \) -prune \) -o -type f -print
És nyilván ha több könvytárat kell kizárni, akkor azt is -o path /x formában kell a belső zárójelek közé írni. Most ezért nem keresek egy Linuxot, de ennek már azon is mennie kellene - jól. Te meg eldöntöd, hogy nem akarod így használni - ez meg a te dolgod.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Igen, így valóban működik. Köszönöm. Érdekes, hogy a neten levő leírások alapján sem dupla zárójelet írnak. Pedig csak kipróbálták, mielőtt cikket írnak róla. Legalábbis ez lenne a logikus.
Sajnos a find ilyen mélységben elég pain in the ass. Egy régi tool, a szintaxisa elég bonyolulttá válik, ahogy növeled az igényeid vele szemben. Én ezért is preferálom az fd-t, a egy mód van rá, mert nem csak gyorsabb, de a paraméterezése is jóval egyszerűbb. A find csak akkor fontos, ha hordozható szkriptet akarsz tényleg írni, aminek olyan rendszeren is kell mennie, ahol nincs fd, vagy nem lehet feltenni (nincs a joga a usernek telepíteni, nincs a tárolókban, nincs az adott platformra, stb.), mert find az biztosan lesz minden unixlike rendszeren a POSIX előírásai miatt.
Kicsit meg tudod kerülni a find nehézségét, ha nem zársz ki mappákat, mindent végigkeres, és a végeredményből grep-pel kiszűröd a neked kellő, nem kellő dolgokat, úgy látod is hogyan működik. Lehet lassabb lesz, kevésbé optimalizált, de jobban át lehet látni, mint ezt az agyonzárójelezett, egymásba ágyazott -prune és -o hegyeket.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
A find | grep formát csak azért nem javaslom, mert könnyű vele magad lábonlőni. (Keresztbe-kasul felcsatolt hálózati fájlrendszerek esetén nem biztos hogy az a jó megoldás, hogy igenis belelépünk és végigkeressük azokat a könyvtárakat, amikről amúgy tudjuk, hogy nem kéne és majd amúgy eldobjuk a találatot; akár NFS, akár Samba, akár AFS. Én már futottam bele ilyen jellegű keresésnél abba, hogy nem gondoltam végig a struktúrát.)
Sajnos tökéletesen nem könnyű megoldani a dolgot, mert a POSIX-szerint nincs -path "primary", márpedig a
find / -name tmp -prune ....
az teljesen jól kizárja a /tmp -t, de sajnos a /usr/tmp -t, /var/tmp -t is, ami nem biztos, hogy kívánatos.
(Amúgy érdekességképpen, a fenti sokféle find implementáció, meg a busybox-beli find mellett megnéztem a toybox-ban levő find-dal is: FreeBSD-n dob egy core-t az első jogosultsági probléma környékén, de egy random Ubuntu-n ugyanúgy működni látszik. Most több find-ot nem találtam, bár nyilván van. Érdekességként meg kéne nézni a DOS-os MKS Toolkit-et, meg pár hasonló elmebeteg implementációt. )
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Jav: a parancsban nem, de a magyarázatban elírtam. Helyesen:
ha több könvytárat kell kizárni, akkor azt is -o -path /x formában kell a belső zárójelek közé írni
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Ez jónak néz ki. Pár javaslat: find helyett próbáld ki az fd-t is. Mint írtam, gyorsabb. A másik, hogy semmi bashizmus nincs a scriptedben, így én az elejére fejlécnek #!/bin/sh sort tennék, ne hozd be függőségnek feleslegesen a Bash-t. Így hordozhatóbb lesz a script. Plusz ha Linux only-nak is szánod, pár ember jobban szereti a dash-ra irányítani a /bin/sh-t, az egy kicsit minimalistább, gyorsabb, de szigorúbban POSIX kompatibilis shell.
A másik, hogy ne a nano-t konkrétan hívd meg, hanem az $EDITOR vagy $VISUAL változóban lévő default editort, ha ezek nem léteznének, akkor mehet a fallback nano, de arról is érdemes meggyőződni, futtatás előtt, hogy létezik-e. Lehet neked ugyanis az a kedvenc editorod, ezzel most nem is vitatkozok, mert ízlések és pofonok, de nem biztos, hogy minden célrendszeren létezni fog. Ha mégis komolyabban veszed a hordozhatóságot, akkor a POSIX miatt a vi fallback a legjobb megoldás, bár már ez is inog, mert pl. Arch-on meg 1-2 disztrón nincs már ott alaptelepítésben, csak ha külön te felteszed. Mondom, csak fallback-nek, attól még hogy a vi a fallback, attól még az EDITOR meg VISUAL változót beállíthatod magadnak az adott rendszeren nano-ra, és azt fogja akkor a script használni.
Persze a find se rossz, mert a POSIX miatt az biztosabban ott van a rendszeren, mint az fd, de erről meg lehet győződni megint, hogy az fd elérhető-e, ha nem, akkor fallback find-ra.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Tudom, hogy mit csinál az fd, és anno mikor tán ide írtam hogy gyorsabb, akkor páran meg akartak cáfolni. De mindegy is, ez csak időleges használat lesz. Zoxide fejlesztője még nem reagált, de lehet hogy május eleje környékén több időm lesz, és akkor megcsinálom magamnak az indexelős adatbázisos megoldást, de most tuti nincs erre időm.
Nem véletlenül nem használok $EDITOR-t, és az sh is teljesen felesleges jelen esetben. Az sh azért is, mert olyan picike script, hogy semmi érdemleges sebességet nem nyújt (nem úgy, mint pl az otthon használt lf file manager), EDITOR változót meg azért nem állítok be, mert ezt csak én fogom használni más nem, és a szerver tulaja nem szereti, ha felesleges cuccokat pakolgatok rá. Amúgy a sajátomon a micro-t használom. Amúgy meg arra a kevés script vagy beállítás módosításokra a nano is untig elég, sőt. A vi, vim, neovim -től meg hányingerem van.
Fallback-et meg pláne nem fogom külön megírni, mert nem a nagy közönségnek írtam meg ezt a scriptet, így megint felesleges bloat.
Persze aki akarja, használhatja, és majd módosít rajta azt, amit szeretne.
Ebben ezek szerint nagyon nem értünk egyet. Régen én is úgy voltam vele, mint te. Összereszeltem magamnak egy kódot, ami jó fixre drótozott, volt, nem volt benne rugalmasság, olyan indoklással, hogy úgyis csak ideiglenes és saját használatra lesz. Aztán az idő mindig úgy hozza, hogy mégis bele kell javítani ezekbe, mert fél év után az igényeim meg a futtató környezet változik, így egy idő után beláttam, hogy nem több menetben javítgatom ezeket, hanem egyszer csinálom meg rendesen, mert a rest kétszer fárad.
Ez nem csak a shellscriptek műfajára igaz, hanem mindenféle kódolásra. Az ember könnyelműen csap össze valamit, olyan indoklással megint, hogy ő érti hülye változó/függvénynevekkel is a kódot, meg neki nem kell a komment, mert ő írta a kódot, érti, nem másnak írta, másnak nem kell értenie. Közben meg ő lesz az a más, aki fél év múlva ránéz a kódra, és már nem érti, hogy mit miért írt anno úgy benne. Ezt is többször tapasztaltam már a bőrömön, mire leszoktam róla.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Kde alt+space