vi mozgasnyi kisbetu - nagybetu valtas ~

A ~ hullamjel segitsegevel tudom a mutato alatti jelet atvaltani kisbetusrol nagybetusre vagy forditva.

Ahanyszor megnyomom, annyi betut valt at.

Hogyan tudok mozgasnyi mennyisegu betut atvaltani egy paranccsal, pl ket szonyit vagy ket sornyit?

Hozzászólások

nem tudom

"Normális ember már nem kommentel sehol." (c) Poli

Ahányszor meg akarod nyomni, akkora számot írj elé. Pl. 11~ az pontosan 11 karakternyit fog átváltani más betűsre, olyan, mintha 11-szer nyomtad volna a ~-t. Elegánsabb megoldás vanilla POSIX vi-ban (és nvi-ban) sajnos nincs, a vim és klónjai tudnak olyat, hogy gU2w vagy v2wU, ezzel pl. 2 szavanként is lehet kis/nagybetűre váltani, de ez a tudás még vi-ban nincs meg. Esetleg elvis, ami egy vi-klón, az még támogatja ezt a gU2w megoldást. Ha nagyon elkeseredett vagy, és vanilla vi-ban kell mindenképp megoldani, akkor esetleg :s/bla/BLA/ helyettesítéssel. Ha pedig scriptben kell, akkor sed-del lehet még megoldani.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Jelen esetben semmit nem vesztettél vele, hiszen a vi nem támogatja őket, csak a vim és klónjai. A g az módosítja más parancsok és mozgások hatóköreit, a v meg visual mode-ba váltana.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Én is most estem neki a vi-nak, hogy majd átállok vim-ről a minimalizmus jegyében, de hát nem megy. Nagyon alap dolgok hiányoznak belőle, pont az ilyesmik, parancsok hatókörének megadása, ZQ, ex-módban (: utáni parancsok) a tab-os kiegészítés nem működik, nincs visual mode, nincs blokkszerkesztés, nincs rendes törlés, hosszú sorok törése, amik átnyúlnának egy képernyőn, problémás, nincs kódszínezés, stb. nem megoldott, ahogy vim-en. Nagyon fejfájós, nagyon fapad a vim/neovim után, hogy nem lehet annyira konfigolni meg annyival kevesebb a feature. Pedig pont a fapadság miatt akartam átállni, mert pont azért lehet hasznos, hogy kevéssel tanul meg az ember megcsinálni sok mindent. Pl. a vi tanított meg, hogy nem kell a kurzortól a fájl végéig törléshez visual mode, pl. vGd vagy VGd, hanem elég a dG vagy 0dG, vagy pl. a zárójeles rész törlésére a f(dt) és ugyanott vagyunk, bár azért a cip megoldás könnyebb vim-ben. Vim-ben sem használok plugineket, hanem mindent a beépített eszközökkel oldok meg.

Még az ilyen kódszínezésről is le tudnék szokni, pl. Torvalds is egy monokróm (kicsit HUP jellegű, sárgán fekete monokróm színtémás) terminálban használ mikro-Emacs-et, vagyis egy saját maga karban tartott uemacs klónt, ami kb. a vi minimalitásával bír, és mekkora projektet visz vele több évtizede.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

 Kicsit túl sok mindent kívánsz a vi-tól.

Amúgy milyen a rendes törlés, amit az nvi nem tud? Vagy épp hosszú sorok törése amit nem tud? (de, tudja, de nem tudom mire gondolsz).

Visual mód is van benne, - bár ti ketten (a vim-mel) nem ugyanazt értitek alatta, mint a vi. (Normál vi-módban megnyomod a Q gombot, átvált ex-módba. Ott pedig begépeled a vi parancsot és visszavált - no mibe is? visual módba. Persze ha arra gondolsz, hogy általában inverzbe váltva mutatja a kijelölt szöveget - v vagy g parancs a vimben - no olyan visual módja valóban nincs.)

A 0dG parancs redundáns, sőt ha "a kurzortól a fájl végéig" akarsz törölni, akkor még hibás is, mert előbb elviszi a kurzort a sor elejére, majd attól a ponttól töröl. Az más kérdés, hogy mind ez, mind a dG azt a teljes sort kitörli, amiben akárhol van a kurzor, szóval igazából az a kérdés, hogy pontosan hogyan érted a az "innentől"-t.

Visual mode-on természetesen azt értem, amit a vim, hogy inverzben mutatja a kijelölt szöveget, amire műveletet lehet végrehajtani. Tudom, hogy sokat várok, egy pár KB-os tool, majdnem 50 évvel ezelőttről. Csak kár érte, mert kevés hiányozna. Ugyanígy jártam a dash-sel, azt is majdnem be tudtam volna fogni interaktív shellnek, de a tab-os kiegészítést és a prompt-színezést nem tudja, ami érdekes, mert nem lenne túl nagy extra kódméret, ha ezt is támogatná. Hiszen vi mód máris van benne, meg a promptnál is ki lehet trükközni, hogy parancskimeneteket tegyen bele, innen már csak két hajszál hiányozna, hogy a bloatabb Basht, zsh-t, stb. dobni lehessen érte.

A 0dG valóban nem a legjobb példa, a 0-át csak variációnak szántam, de itt valóban nincs értelme, a dG egész sort töröl, nem kell az elsőnek az elejére elmenni hozzá.

Rendes törlés: ha vanilla vi-ban megnyomod a backspace-t, akkor nem töröl semmit látszólag, hanem csak visszafelé megy a kurzor, meghagyva a szöveget. Persze ha ki/belépsz normal mode-ból, akkor mégis csak eltűnik a szöveg. nvi-t nem tudom, hogy ilyen-e, lehet le kéne fordítani Archra. Egyszer eljátszottam vele régebben, onnan emlékeztem, hogy a ~-nek nem lehet megadni hatókört, de ezek szerint csak nem nyálaztam át rendesen a dokumentációját.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Szerintem nem olvastál eleget utána a dolgoknak.

Bill Joy leírta, hogy a törlés azért így működik a vi-ban (megnéztem, az nvi-ban is, ami nem csoda ha egyszer bug-to-bug compatible), mert amikor fejlesztette, akkor teljesen természetes dolog volt a 300 baudos (vagy még lassabb) kapcsolaton lógó soros terminál. Ezen sebesség mellett a kélpernyőfrissítés minden Backspace hatására - ha a te általad elvárt működést szeretnénk -, baromi lassú lenne - ettől nyilván meghülyülne a felhasználó.. Azon lehet vitatkozni, hogy később, amikor már elterjedtek a 9600 meg 19200 (pláne 38200!) baudos soros vonalakon lógó terminálok, akkor miért nem épített bele egy opciót ennek kikapcsolására. De ha azt is tudod, hogy tán 20 vagy 30 évvel a vi megalkotása után egy riportban gyakorlatilag elhatárolódott a vi-tól, akkor lehet sejteni, hogy valószínűleg ezért maradt el ez az apróság. Senkinek nem kellett semmit újra tanulni, minden ugyanúgy működik, ahogy dokumentált. Amúgy sokak pont azt rühellik a Linuxnál, hogy 2-3-5 évente mindent teljesen újraírnak - lehetőleg a korábbi verzióhoz képest inkompatibilis módon (lásd ugye service izé start és systemctl start izé - vagy fordítva?; vagy "kidobni" az ifconfigot, mert nem megoldható vele ez-meg-az, közben a BSD-k azon funkciók 99%-át pont beleépítik a hagyományos ifconfig-ba; stb.) És a fejlesztők egója sokszor fontosabb, mint a világ maradék 99%-a.

(Ezt a részt meg már nem törlöm ki, de mivel figyelmetlen voltam, ezért nem releváns, azt hittem más a bajod a törléssel.)

=== nem válasz, csak agymenés ===

vi ~/.exrc

map ^H X

és innentől töröl neked a Backspace. A ^H az egy fizikai Control-H. Ha mégsem, akkor a Backspace nem azt a kódot küldi, amit (Control-V megnyomása után) ^H-ként bevittem, szóval oda azt gépeld, hogy Ctrl-V utána Backspace (ez "szabványos" esetben lehet még ^? is, de használtam én olyan Wyze terminált, amin egy 4 karakter hosszú ESC-szekvenciát küldött a Backspace gomb). Amúgy vi-nál dokumentált, hogy a ^H az a h gombbal egyenértékű parancsmódban. Ha azt akarod, hogy beszúró módban is törlés legyen, az kicsit nehezebb, mert a vi - ahogy írtad is, beszúró módban nem töröl, de megoldható. Fenti mellé vedd fel a

map! ^H <ESC>xa

makrót is, ekkor beszúró módból előbb kilép parancs módba, (ekkor a kurzort balra lépteti), utána kitörli a kurzor alatti karaktert, majd visszalép beszúró módba.(A map parancs parancs-módban, a map! pedig beszúró módban teszi lehetővé a billentyűk átdefiniálását.)

Problem solved.

=== end of nem válasz ===

 

Ami pedig a dash-t illeti, kb 100% valószínűséggel tud promptot színezni is. Módosítsd  a PS1-et:

PS1='<ESC>[42mHajrá Fradika!<ESC>[0m '

Lesz neked rusnya zöld promptod.Az <ESC> helyére egy fizikai ESC kódot tegyél (tudod, ASCII 27). Az egyes színekhez tartozó számértékekhez google://"vt100 terminal color codes". Hogy a dash hogyan számolja a prompt hosszát, azt nem tudom, ksh-ban és bash-ban, ha ilyen a sztring hosszán nem növelő ESC-szekvenciákat rak az ember a promptba, akkor minden ilyen sztring elé javasolt egy \[ és mögé egy \] szöveg is, ettől tudja, hogy a közbezárt izé nem számít a hossz szempontjából.

A TAB-kiegészítésről nem tudok nyilatkozni, de a válasz kedvéért feltelepítettem (0.5.11.5-ös verzió, jelentsen ez bármit is), és majd játszok vele egy kicsit. Elvben a doksija szerint tud VI és Emacs módot is, de tény, nem szól róla ennél többet, és egy gyors googel se mutat érdemi infót. Attól még ...

 

Összefoglalom. Soha ne mondd, hogy soha. A hagyományos UNIX rendszerek nagy előnye az volt, hogy használható dokumentáció volt hozzájuk - épelméű esetben magán a rendszeren telepítve, csak el kell őket olvasni. Ezt mondjuk sok Linux terjesztés nem feltétlenül ugorja meg a mai napig sem, nem véletlenül terjednem a fórumok, howtok, stackexchange és társaik. Az is igaz, az emberek zöme nem tud és nem szeret olvasni (van néhány, akinél fordított a sorrennd) - minden működjön elsőre úgy ahogy NEKI jó (és nem gondolja végig, hogy az MÁSNAK nem biztos, hogy pont úgy jó).

(Kedvenc példám, hogy nagyon sok felhasználó már ott elvérzik, ha bekerül egy "set +o emacs" parancs a .bashrc-jébe.)

Azt tudom, hogy elhatárolódott a vi-tól, azt nagyon rosszul teszi, mert zseniális cucc. Csak bővíteni kéne, vagy eleve úgy megírni, hogy a user bővíthesse billkombókra, parancsokkal, stb.. Ahogy írod is, semmi ok nincs ma rá, hogy a vi backspace-re ne töröljön. Az ilyen nemtörődöm apróságok tudnak engem nagyon bosszantani, hogy lenne egy nagyon jó eszköz, de mivel azt a kevés extra munkát kispórolják belőle, hatványozottan csökken a használhatósága ahhoz képest, mint amekkora potenciál lenne benne.

dash-ben a színkód sehogy se működik. Kipróbáltam az általad írtakat, úgy se, de se a \033[42m, se a \e[42m nem működik, valószínű, hogy benyeli a színkódot, mint nem nyomtatható karaktert. Próbáltam \[ és \] közé is tenni, úgy se megy. Azt tudom, hogy parancsokat be tud venni, pl. PS1='$(pwd) ', de a színkódot hiába próbál belecsempészni az ember, azt kiszűri. Mintha a szerző arra gyúrt volna, hogy szándékosan használhatatlan legyen interaktívként. Kicsit a vi-nál is így érzem, pl. mikor map-pal próbálnál új billkombókat felvenni, pl. map ZQ akármi, akkor benyögi, hogy too dangerous to do that. Azért ezt ne döntse már el helyettem, mert felrúgom.

Ezt a set +o emacs-et nem értem, eleve annak kéne lennie az alapértelmezettnek. Szerintem a set +o vi az, amire sok felhasználónak ledobná az agya az ékszíjat.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ja, WSL-ben bash van, Bashban, zsh-ban, stb. nálam is működik a színezés, akár \033, akár \e, akár a zsh saját színezős módszerével. Itt most szigorúan a dash-ról van szó, az csak \033-mal ismeri fel, akkor színezi a promptot, úgy néz ki, de vi módot bekapcsolva, mégis benyeli a színkódot.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Elhiszem, hogy megy, de szerintem azért, mert pont nálatok a dash vi-módja nem csinál semmit. Gyanítom, hogy a vi-módot megvalósító libedit nincs belefordítva a binárisba. De még az is lehet, hogy Archon tolt el valamit a csomagfenntartó, és bugos dashben a vi-mód.

Természetesen próbáltam echo helyett printf-fel is, úgy se megy.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

dash-ben a színkód sehogy se működik.

Te valamit elrontottál.

$ cat ~/.dashprofile

case "$-" in
*i*)    # interactive dash
    echo "Interactive dash"
    ;;
*)    # non-interactive dash
    echo "Non-interactive dash"
    ;;
esac
PS1='<ESC>[42mFradika<ESC>[0m '

$ env ENV=~/.dashprofile dash

Interactive dash

Fradika

És noha itt nem látszik, de zöld a prompt szövege, nem nyel le semmit. Valamint természetesen kiírja az interaktv shell szöveget.

Mindazonáltal te valami  mást is elrontasz. A manual nálam nem említ .dashprofile-t, csak .profile-t, és azt mondja, hogy interaktív shell esetén veszi az ENV változóban szereplő fájlt, és végrehajtja az abban szereplő parancsokat. Azaz egyértelműen le van írva, hogy nem-interaktív módban nincs semmiféle inicializáló fájl. A .profile pedig - mint loginkor lefutó parancsfájl - értelemszerűen szintén csak interaktív módban működik.

== vi ==

elindítottam egy nvi-t, és ezt gépeltem be

:map ZQ :q!<Ctrl-V><Enter><Enter>

majd parancsmódban begépeltem a ZQ szöveget és kilépett, mint a pinty. Nem lehet, hogy nem vi, hanem vim volt az aki ezt a hülyeséget mondta neked?

Kösz, ez amit küldtél működik, jól érzékeli az interaktivitást, de a színkódot ez is benyeli. Így viszont működik:
PS1='$(echo "\033[42m") $(pwd) $(echo "\033[0m")'

Sajnos csak addig, amíg set -o vi paranccsal be nem lövöm a vi-módot, onnantól benyeli a színkódot. A te <ESC>-es megoldásod sehogy nem veszi be, kikapcsolt vi-móddal se. Mégis hasznos lesz ez, mert így már tudom, hogy a vi-módban kell a hibát keresni. A tab-os kiegészítést továbbra sem támogatja sajnos sehogy se, annak a hiánya nálam abszolút dealbreaker.

A rendszeremen (Arch) nem nvi van, hanem sima, eredeti vi, az azt írja a :map ZQ :q! megoldásra, hogy Too dangerous to map that és ennyiben hagyja. Vissza fogom tenni az nvi-t, de az csak jövő héten lesz, mert Linuxon nehéz forgatni, valami olyan lib függősége van, ami Linuxon nem létezik, hanem valami BSD clib-es megoldást használ, ezért szüttyögni kell vele, hogy leforduljon. Bent van Arch-on az AUR-ban az nvi, az is kódból forgatja, és hibával el is száll, nem fordul le.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

$ exec dash

$ PS1='<Ctrl-V><ESC>[42mdash$<Ctrl-V><ESC>[0m '

dash$ set -o vi

dash$

És  az utolsó 2 sorban máris zöld a prompt. Nem nyeli le, nincs benne ilyen hiba. De hogy mi a bánatért nem megy a vi mód, azt még nem értem rá kigyökölni. De ha elindul, lesz neked TAB-completion - igaz, mint írtam ESC-completion az, amit a vi-mód támogat (már azokon, ahol egyáltalán működik).

Ami az Arch-os vi-t illeti, megtennéd, hogy bemásolod, hogy mi a francot ír ki akkor, amikor a :ver parancsot begépeled? Felraktam egy 2bsd-vi.050325-ös verziójú valamit, de nálam csak Bus errorokat tud mondani.

Megnéztem, ez lesz nálad: https://ex-vi.sourceforge.net - és valóban benne van a a forrásában ez a vicc a Too dangerous-sal:

               /*
                 * We don't let the user rob himself of ":", and making
                 * multi char words is a bad idea so we don't allow it.
                 * Note that if user sets mapinput and maps all of return,
                 * linefeed, and escape, he can screw himself. This is
                 * so weird I don't bother to check for it.
                 */
                if (isalpha(src[0]&0377) && src[1] || any(src[0],":"))
                        error(catgets(catd, 1, 64,
                                                "Too dangerous to map that"));
        }

Akkor innentől lehet a (nem túl aktív) fejlesztőnek feature request-tet küldeni, hogy mondjuk a ZZ-n kívül még pár vim-ból fakadó szart építsen bele :-)

Nem kell beleépítenie semmit, már csak azért se, mert ha vim-et akarnék belőle csinálni, akkor használok vim-et helyette. Ne építsenek bele semmit, csak ne gördítsenek az ember elé akadályt, hogy saját maga bővítse konfiggal, meg ne szopassák ilyen 300 buados terminálok korszakából visszarekedt korlátokkal, hogy a backspace nem töröl rendesen, mert spórolnak a képernyőfrissítéssel. Itt igazából csak erről van szó, nem többről.

Ez egyébként mai napig gond, hogy a fejlesztők letiltanak egy csomó dolgot, hogy megvédjék önmagától a usert, és ez felesleges. Ha olyan veszélyes lenne több billentyűs map-ot csinálni, akkor vim-en, neovim-en, Emacs evil módban, Vifm-ben, lf, ranger, Zathurában, stb. sem használná őket senki, közben meg nem így van. Ebben még a vi is meghazuttolja magát, mert pl. a ZZ alapból, gyárilag bedrótozva működik, az nem veszélyes? Most egy ZQ, ZA, g<akármi> az miben lenne veszélyesebb?

Egyébként kösz a válaszokat, egy csomó hasznos dolgot írtatok, így már a forráskódból is ki tudom szedni ezt a too dangerous hülyeséget, meg most már tudom, hogy bugos az Arch dash buildje, azért nyeli be a színeket a vi-mód, a terminálemulátor biztosan nem hibás, mert próbáltam st, xterm, Alacritty-vel is. Azt viszont még mindig nem értem, hogy dash vi-módban a kiegészítésnek hogyan kéne működnie, ha nem tab-bal? Mert nem kizárt, hogy tényleg lenne rá workaround, csak épp nem tudom, hogy mi lenne az. Természetesen a vim-es ^X^N nem működik eredeti vi-ban és dash vi-módban.

Amit még nem tettem világossá. A dasht azért akarnám befogni interaktív shellnek is, mert a nem interaktív /bin/sh máris arra van symlinkelve és egy csomó script a háttérben már eleve azzal futna úgy is, ha meg az interaktív shellem is dash lenne, akkor tudná használni a többi dash process által betöltögetett shared libeket, és nem töltögetné be extraként a saját megoldásait, mint a bash, zsh, stb..

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Egyetértek

Az más férdés, hogy man dash szerint set -o vi és set -o emacs is van benne - amúgy nálam egyik se működik FreeBSD-n (és egyéb hibája is van ennek a két, egymást elvben kölcsönösen kizáró módnak). Ebből a POSIX a vi-módot írja elő (bár engedélyez - nem nevesítve - egyéb szövegszerkesztő módo(ka)t is) - azaz ezt még tudnia is KELL. Ráadásul a ksh88 (ami alapján a POSIX-shellt megalkották) már eleve ismeri a TAB-completiont, igaz nem a bash által jóval később bevezetett módon <TAB>-bal, hanem <ESC>-pel elérhető módon. (ESC-*, ESC-ESC, ESC-=). Igaz, az AT&T-féle, original Korn-shell (ksh88) eredetileg parancsokra nem, csak fájlnévkiegészítésre tudta (ugye a UNIX-filozófia,: nem vaktában gépelgetünk, hanem TUDJUK, mit csinálunk - legalább a parancs nevét ismerjük.) És ez a bizonyos ksh88-ban bevezetett ESC-kiegészítés explicit módon szerepel a POSIX szabványban; le van írva a vi editing mode "fejezetben", a vi Line Editing Command Mode részben . Szóval ha a dash POSIX-megfelelő (POSIX-compliant) akar lenni, akkor _ezt_ tudnia kell. Ha pedig ad egy key-rebind parancsot, vagy épp egy opciót (mint pl. a pdksh, ahol eldöntheted, hogy ESC-vel vagy TAB-bal akarod kezdeni ezt a kiegészítést), attól bloat még nem lesz, viszont az emberek 99%-a tök nyugodtan tudná haszsnálni a sokkal nagyobb bash helyett.

Az újabb shellek általában tudnak vi/emacs-ot, általában lehetőség van az ESC-kiegészítést átállítani (vagy szigorúan csak TAB-ra - pl. a pdksh; vagy kb. bármire, mert van valami key binding definiáló parancs, esetleg agyrém trükkök speciális nevű aliasokkal. Hello, ksh88.)

Mondjuk személy szerint sose értettem, hogy pont Linux alatt miért olyan húha a dash, amikor van pdksh, MirBSD-féle mksh, sőt ugye adott a natív, sokkal több mindent tudó ksh93 is - igaz, méretben nagyobbak. OK, visszavonom.

Valamiért úgy rémlett, hogy a function is benne volt a POSIX-szabványban. Ha viszont mindig is csak ksh-hagyomány volt, akkor vajon a bash-ban miért erőltetik annyira a function x formát, a szabványosabb (és hagyományosabb) x() formával szemben? (Pláne a function x() a durva.)

Én is erre használom, tesztelem vele, hogy egy szkript az valóban POSIX kompatibilis-e és nem maradt-e benne véletlenül valami olyan bashizmus, ami a portolhatóságát akadályozza. Bár sokszor ez sem elég, mert a szkript hiába POSIX, ha pl. linuxos parancsokat hívogat, pl. lsblk, free, watch, amiből pl. BSD-ken indítva szopás lesz. Akkor használom még a dasht, ha követelmény, hogy a szkript minél gyorsabban, minél kisebb memóriahasználattal fusson.

Sokszor azonban ez a kis erőforrásokkal futás is csalóka. Mert pl. POSIX kompatibilisebb, de nincs benne pl. olyan kényelmű funkció, mint a Bash read parancsában a -t timout kapcsoló, meg az -n 1 kapcsoló, így mindenféle subshellben kell dd-vel meg kill-lel trükközni, ami annyira vissza is bonyolítja a szkriptet, meg felnöveli az erőforrások használatát, hogy összességében nem érte meg a minimalizmus.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ha egyszer egy eszköz azt mondja, hogy tartja magát a POSIX-szabványhoz, akkor igazából bármit teszel bele, amit a szabvány nem ír elő (pl. a bash-beli read -n meg -t opciója), akkor csak rontod a helyzetet. Pont most délután olvastam, hogy valaki beírt a dash fejlesztői levlistára, hogy miért nincs tömbváltozó a dash-ban. Erre egy faszi k hosszan válaszolt neki, hogy miért (meg mellesleg azt is írta, hogy mert nincs benne a POSIX-szabványban). Erre a faszi írta (és be is linkelte), hogy megírta az opengroup levlistájára is - és ott kialakult egy szép hosszú párbeszéd, ahol szintén baromi részletesen leírták neki, hogy miért nincs a szabványban. Eleve hogyan kellene?

ksh88:

set -A array element1 element2 ...

és

a[3]=2

ksh93:

szintén, de bevezeti az asszociatív tömböt is, hogy nehezebb legyen a dolog

bash

array=(element1 element2 ...)

és a[3]=2

Fentieknél lehet lyukas a tömb.

A zsh úgy csinálja mint a bash, de ha jól olvasom, nem lesz lyukas a tömb, a hiányzó indexű elemek létrejönnek. (És még talán 1-től indexeli az elemeket, nem 0-tól.)

 

Még egy yash-t is emlegetnek, ami meg még másként. És ezek többé-kevésé mind POSIX-kompatibilisek, de bármit is találnak ki, egy csomó script innentől másként fog futni. Szóval nem egyszerű az élet a hordozható scrpt írásával. (És mint mondtam, a fejlesztők egója sokat tud rontani a helyzeten.)

Ezt nem tudtam, hogy a POSIX megköveteli a vi módot. Érdekes, hogy a többi módot nem. pdsk, mksh-val, ksh93-mal minddel az a baj, hogy méretben nagyobbak igen, és nem nyerek velük a Bash helyett. Ennek a dash-nak pont az a lényege, hogy keveset tud, de a leggyorsabb létező megoldás. Csak hát ezek a hátulütői, hogy interkatív shellként 1-2 rosszul/nem implementált feature-ön elvérzik.

Eleve Bash-t is azért használok, mert a zsh nagyobb, bloatoabb, és nem használom ki a többlettudását. A Fish-sel is ugyanez a baj.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Igen, azt tudom, hogy nem interkatív és szigorúan POSIX minimalista shell, de 1) van interaktív módja, 2) tud vi módot, amit a POSIX kifejezetten nem ír elő, így még apróságként tudhatná a tab-os kiegészítést, és a színkódok be nem nyelését, máris hatványozódna a használhatósága, a kód meg még mindig nem lenne bloat, a legsoványabb shell lenne továbbra is. Ezeket az extrákat be sem kéne töltenie, ha nem interaktív módban fut.

Egyébként ez meg a másik, hogy a konfigolása is elég szar a dash-nak, a ~/.dashprofile fájlban pl. nem tudtam bedrótozni, hogy ne hajtódjon végre az interaktív konfig, ha nem interaktív módban fut. A $_ megadja a kapcsolókat, ami között ott van az i, de hiába vizsgálom POSIX-os módszerekkel, regexp-pel, nem érzékeli. Nagyon pain in the ass, pedig rettenet kevés hiányozna hozzá, hogy használható legyen.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

De, délután utánanéztem, a POSIX egyértelműen előírja a vi-módot. Az egyéb (gy.k.: emacs, de nincs nevesítve) módról írja azt, hogy éppen lehet, de nem kötelező.

Amit az interaktív módról és a .dashprofile-ról írtál, azt fent ( https://hup.hu/comment/2803127#comment-2803127 ) megcáfoltam. Mondjuk most látom is miért, neked nem $_ hanem $- kell. A $_ az a legutolsó végrehajtott parancs utolsó szava, ami egy shell indulásakor deklaráltan tök üres. (Mondjuk script X. parancsában még sose akartam használni.)

Szerkesztve: 2022. 07. 02., szo – 17:15

És hogy kapj valami infót is:

nviban kapcsolt be a tildeop nevű beállítást (:set tildeop), és innentől a tidle ( azaz a ~ - a kisnagybetűfordító) parancs nem önmagában értelmeződik, hanem úgy, mint a d, c, y, <, > parancsok, azaz ~$ átvált a sor végéig, ~0 átvált a sor elejéig, ~~ a teljes sort megfordítja, stb - azaz pont használhatók vele a megszokott mozgatóparancsok - azaz amit kérdeztél.

Igaz, ez ellentétes a hagyományos vi-jal, ha vissza akarod kapcsolni, akkor értelemszerűen :se notildeop.

A vim-ről nem nyilatkozom, mert nincs szükségem a bloatságára, tudom használni a vi-t is. (De azért megkerestem: pont ugyanígy működik:)

Ezt jó tudni, megmondom őszintén, hogy az nvi-t nem annyira ismerem. A vi-t én is majdnem tudnám használni kizárólagos fő editornak, nagyon kevés hiányozna hozzá, ez a kár érte.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Na, most egy szomorú baleset miatt elővettem a régi ThinkPad X220-am, és OpenBSD-n vagyok. Eltört az Ideapadom képernyőpántja, mivel becsúszott a polc oszlopai közé, és amiatt azok nyomást tettek rá, és szétrepesztették. Ilyen, ha nem történik, azt mondanám, hogy ilyen nincs :( Megrendeltem hozzá az új fedelet és pántokat, a képernyőnek szerencsére semmi baja. Pár napig ezt a régi gépet fogom használni.

Na, mindegy, van jó oldala, OpenBSD-n ugyebár nvi van. Működik mindaz, amit mondasz, a ZQ és a backspace map-elése, utóbbi tényleges törléssé, bár ^V Backspace kombóra ^? karaktert írt. Működik ez a :set tildeop beállítás is, részletesen vezérelhető a ~ hatóköre. Az ékezetes karakterek helyén hülyeséget írt, \xblabla karaktereket, de kiderült, hogy a deafult nvi nagyon régi verzió, de ha felteszi az ember a nvi csomagot, akkor az már 2.2-es. A törlés továbbra sem tökéletes, mert a backspace csak addig töröl, amíg el nem éri az insert módba lépési pozíciót, de azt túlmenően nem töröl semmit. Plusz ha grafikus felület alatt futtatom, akkor nem tud beilleszteni az nvi az X vágólapról.

Lehet felteszem majd a dash-t, bár nem sok értelme van, mert ezen a rendszeren ksh van, ami hasonlóan minimalista. Egy próbát azért megérne.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)