[MEGOLDVA] CLI-s másoló/mozgató program cp és mv helyett

Fórumok

Esetleg valaki tud olyan programról, fejlesztésről, amivel le lehetne cserélni a "gyári" cp és mv programot, mert sokkal több mindenre képes?

Konkrétan az lenne a cél, hogy mind másoláskor, mind mozgatáskor mutassa, hogy éppen hány %-nál tart, és kb mennyi idő lehet hátra összesítve.

Az rsync épp ezért nem jó, mert az fileonként mutatja a progress-t, nekem pedig összesítve kellene. Találtam még githubpon egy cp-p programot, ami elvben képes lenne rá, de nem működik. Régi fejlesztés, és valszeg a Linux "változásait" nem követte, így használhatatlan lett.
Fontos, hogy CLI-s megoldás legyen, mert az lf file managerbe szeretném beleintegrálni.

Hozzászólások

Itt adnak jó tippeket, pv, rsync --progress, cp + progress. Alapvetően komolyabb nem létezik, mert amikor cp-vel, mv-vel, rsync-kel mozgatsz, akkor minden fájl külön művelet, nem méri fel egyben, hogy mekkora lesz az összes elvégzendő művelet, így nem tudja kijelezni hogy hol tart, csak egy fájlon belül. Ez valóban egy nagy fogyatékossága ezeknek az alap shell-ben futó CLI megoldásoknak. Elvileg írható ilyen tool, ami előre felmér mindent, de nem tudok róla, hogy létezne.

Ezt a GUI toolok is úgy szokták megoldani, hogy előre lemérik az egészet, és ez sokszor idő is, pár másodpercig nem hajtják végre még a kért műveletet, hanem felmérnek, pl. Double Commander így csinálja, talán a Krusader is.

The world runs on Excel spreadsheets. (Dylan Beattie)

Szerintem nem olyan rettentő nehéz ezt megírni C-ben. Ha elég a progresszbárnak file-os felbontásban működni, azaz inkább kisebb file-okból van sok, akkor pedig akár egy shell scripttel is megoldható a feladat.

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

Köszönöm Mindenkinek a segítséget!

Az ideiglenes befutó az rsync --info=progress2 (amit próbáltam, de ugyanúgy működött, mint a --progress, míg az egyik fórumon meg nem említették, hogy a -v kapcsolót nem szabad használni, és akkor rendesen mutatja a teljes overall-t). A tuti a gcp program lenne, de ezt valamiért nem tudom az lf program alsó sávjába kiiratni, míg a sima cp, és rsync esetén igen az alábbi kóddal:

rsync -ah --info=progress2 -- "$@" . |
stdbuf -i0 -o0 -e0 tr '\r' '\n' |
   while IFS= read -r line; do
lf -remote "send $id echo $line"
done

Majd írok a fejlesztőnek, hűtha válaszol, hogy mi lehet a probléma, vagy esetleg mi a megoldás. Ha nem reagál, akkor marad az rsync a progress2-vel.

Ez a megoldva most mit takar? Találtál valami használhatót, vagy feladtad a keresést?

lf-et használnám én is, nekem azzal az a bajom, hogy ilyen intéző/ranger-szerű, Miller-oszlopos fájlkezelő, és nem a hagyományos, kétpaneles, commander szerű a felépítése. Én majd egy fzf-en alapuló szkriptes megoldás akarok írni, ami fzf-fel lépked mappák és fájlok között, fájlmegnyitásra, mappaváltásra, fájlműveletekre befogva.

Jelenleg a Vifm-et használom még mindig, abban van ilyen folyamatkijelzés, de az sem teljesen olyan, amilyet te keresel. Egy fájlon belül mutatja csak a százalékokat, ha több darab is van, akkor a fájlok darabszámát (pl. 3/15). Csíkot meg semmi mást sem rajzol, szóval elég fapados megoldás ez is, nem olyan, mint a rendes GUI fájlkezelők jobban látható megoldásai. Ezek az apróságok nekem is hiányoznak Double Commanderből, amit régen használtam még kezdőbb, GUI-s koromban.

The world runs on Excel spreadsheets. (Dylan Beattie)

Találtam két jó programot is:

- gcp (Raynes -nek hála)

- rsyncy (erre véletlenül akadtam)

Mindkettő mutatja %-osban is, progress bar-t is megjelenít, és ETA-t is mutat.,

Ebből a gcp kimenetét tudtam rendesen beilleszteni az lf fájlkezelőbe, így azt tartottam meg, ráadásul ez a Debian repojában is benne van.

Debian alatt semmi ilyen nem kell (de csak azért, mert a python3-progressbar már fent van automatikusan). Arch alatt próbáld meg feltenni a pip3-at, és azzal telepíteni: pip3 install gcp.

Gondolom a nyomorék Python nyelv miatt van ennyi függőség. Debián alatt szerencsére nem kell cairo, egy csomagja sincsen fent nekem.

Nagyon nem lepődöm meg. Nem véletlenül váltottam x év utána Archról másra. És ahogy olvastam 2-3 hete újabb bahés csomagtöréseket produkál a pacman, meg úgy általánosságban is vannak szívások. Több olyan időszak után, mikor az Arch-al többet szívtam, raktam rendbe, mint egy Windowst, döntöttem, hogy váltok.

Próbáld meg felrakni ezeket: sudo pacman -S cairo pkgconf gobject-introspection gtk3

Mire váltottál? Void, Artix? Nekem nagy bajom nincs az Arch-csal, de ja, néha előfordul vele ez-az. Nem olyan mennyiségben, hogy zavaró legyen, így én még kitartok. Lehet új esélyt kéne adnom a Gentoo-nak is. Iletve pótgépeken játszok FreeBSD-vel és OpenBSD-vel, egyelőre még nem váltak be.

Felrakom ezeket, a gtk3 már eleve fent van a Firefox meg pár program miatt. Ezt a cairo-t nem értem, hogy egy CLI programnak minek ilyen GUI függőség. Tipikus pythonos lámulásnak tűnik.

The world runs on Excel spreadsheets. (Dylan Beattie)

Egyiksem. Egyszerű minimal Debian telepítés, és úgy építgettem fel kézzel, mint az Arch-os konfigomat (csak a szükséges csomagok, még az Xorg csomagokból is csak amire szükségem van), így ugyanúgy minimalista, de gyors, és mentes a függőségi kalamajkáktól. Nincs naponta felesleges frissítések sem, amik először jópofák voltak, aztán már idegesítőek. Egyszerűen csak működik gond nélkül.

Ja, igen, most már én is emlékszem, hogy egy másik topikban is írtad a Debaint. Azon én is gondolkodtam, de nekem túl régiek benne a verziók, ami tompítható, ha Sid tárolókat használ az ember, de akkor meg nem lesz túl más az Archhoz képest, és néhány verzió még akkor is túl régi benne 1-1 csomagnál. Bár a Debian nálam is B terv, arra az esetre, ha megint valami olyan helyre költöznék, ahol nagyon szar a net, és nem akarnék sok frissítést lehúzni, arra a felhasználási körre viszont elég jó, más bajom nincs vele. Régen még az nem tetszett benne, hogy a nonfree tárolókat külön kellett bekapcsolni, de már ez is megoldódott náluk a legutóbbi váltásnál. Hasonlóan alternatíva még a Void Linux is, az kicsit köztes, több a frissítés, mint Debain-on, de nem annyi, mint Archon, annyira vadul nem haladnak a verziókkal. Esetleg Gentoo, de ott meg az embertelen sok fordítgatás.

The world runs on Excel spreadsheets. (Dylan Beattie)

Míg Archot használtam én mindig azzal pedáloztam, hogy a Debian és társai hogy le vannak maradva a csomag verziókkal. Nos amikor kipróbáltam az átállást, és felconfigoltam mindent, tudod mi történt? Semmi. A 2-3 verzióval ezelőtti csomagokkal ugyanúgy működtek a programok, még az egyedi felprogramozott vifm is, polybar is, rofi is. Semmi hiány nem volt, minden működött rendben, úgyhogy be kellett látnom, hogy azért túl van tolva az, hogy mindenből a legújabb verzió kell. Amúgy meg ha valamilyen progi hiba miatt mégis kellene a legújabb, akkor fogom, felmegyek a githubra, és letöltöm az új verziót oszt kész. De például vifm-ből van appimage, tehát még telepíteni sem kell az új verziót, csak szimplán használni kell, szal semmi szükség Debian esetén a testing, vagy unstable verzió az újabb programok esetén. Én azért gondoltam első körben a Debian-ra, hogy ha már a melóhelyen az összes szervernek azt kérték, akkor miért ne próbáljam magán használatra is felkonfigolni. Aztán jött a meglepetés, hogy régebbi verziókkal is minden működik kapásból, hogy alapból ugyanazon progikkal, csomagokkal, konfiggal 255MB memória helyett csak 193MB-ot eszik, tehát még takarékosabb is. A gyári 5.10-es kernel kicsit elavult, de fél perc alatt beüzemeltem egy 5.15-ös Xanmod kernel-t (nem mintha az 5.10-es gyárival bármi bajom lett volna...). Szal nekem a minimal Debian saját custom config scripttel igen kellemes meglepetés lett. Amúgy most megpróbáltam az Arch-ot updatelni (kb 2 hónapja nem updateltem, mert semennyire nem használom már kb fél éve, csak időnként bebootoltam és updateltem), és úgy elhasaltlt az update (300+ db frissítéssel), mint a fene...Nyilván újra rendbe tudnám hozni, na de kérem, egy Linux-al ilyen szívások legyenek, és nem először, nem másodszor. Azért ezt szánalmasnak érzem.

Ja, azt én se értem, hogy a Debian ugyanazokkal a futó programokkal hogyan foglal kevesebbet, mint Archon. Rejtély a mai napig. A 2-3-mal ezelőtti verziókból viszont már volt problémám, mikor pl. anno új verziós Kodi kellett, meg egy-két git-es tárolóból fordításnál is hibát dobhat, ha a függőségek közül valami túl régi. Emiatt van csak az, hogy ha nem muszáj váltani, az Archnál vagy valami más rollingnál maradok.

2 hónap nem frissítésre Archnál sok, de nem vészesen, nem lett volna szabad elhasalnia az update-nek. Egyébként meg tökéletes rendszer/disztró nincs, valami gond minden rendszeren lesz valamivel, vagy a kiadási ciklus vagy a verziók vagy függőségek, vagy valami bug, más miatt.

Arch sem hibátlan valóban, nekem nem a bugosságával van a bajom, hanem hogy kezdenek néhány csomagnál verziókkal elmaradni, pl. fél évig gond volt a glibc-vel, most meg a Bash-sal vannak elmaradva (szerk.: ez ma megoldódott, végre léptek 5.2-re), Thunderbirdből is sokára jött ki a 100-as verzió. Plusz mikor gond van, akkor meg nem kommunikálják le a News szekcióban, meg mikor a ffmpeg5 után eltört a videólejátszás, nem tették közzé, hogy a 4.4-es legacy csomagot kell telepíteni mellé, meg ment a terelés az Arch moderátortól a fórumban, hogy neki működik, meg ő a helikopter, közben csak elfelejtett frissíteni, és még régi, 4.x-es verziót használt. A legutóbbi Grub-problémába nem szaladtam bele, mert systemd-bootot használok, de sok ember megszívta Archon, hogy nem bootolt a Grub, erre csak 3 nap után tették ki a hírt, és abban is ment a terelés, hogy így nem érint sok embert, user error, stb.. Ez a hozzáállás nem tetszik az Archnál. Technikai szinten amúgy nem sok gondom volt vele az évek folyamán.

The world runs on Excel spreadsheets. (Dylan Beattie)

Amúgy ha neked a ranger megfelelő lenne, akkor a ranger is tud dual panelos megoldást a miller mellett. Én úgy használtam pár hétig, hogy beállítottam egy gombra, hogy kapcsolgassam a miller, és rendes dual panelos megoldást (pont mint a vifm). Ha kell ennek a megoldása, akkor le tudom neked ide írni. Megvan még a ranger configja is.