Fejlettebb symlink támogatás a Windows 10-ben

Microsoft, Windows

Ugyan az NTFS fájlrendszerben a Windows Vista óta van symlink támogatás, symlink-ek létrehozása eddig nem volt egyszerű. Ez most változik... Részletek itt.

( mrceeka v | 2016. 12. 05., h – 18:42 )

Forgatható kormány! Nyitható ajtók! :D

Üdv,
Marci

( Madman | 2016. 12. 06., k – 00:59 )

nem csak hardlink volt eddig? nagyon le vagyok maradva :)

Cuki (W7):
fsutil - hibaüzenet: "rendszergazda jogosultság kell a használatához"
mklink - szimlink esetén hibaüzenet: "nem rendelkezik megfelelő jogosultsággal"

De legalább hardlink esetén működik (mondjuk amit válaszként adott, attól a szőr feláll a hátamon: "Kódolt hivatkozás létrehozva ize.txt <=> ecet.txt") Vajon valami egyszerű módszer is van arra, hogy kiderítsem, hogy 2 fájl egymás hard linkjei (de legalább azt, hogy *van* neki 1-nél több neve)?

Á, hagyjuk - végül is a hír arról szól, hogy a W10-ben már fejlett a használata. Egy-két évtized, és működni fog. (Már eleve az milyen, hogy a kissé korábban létező ln parancshoz képest pont fordított a paraméterezése fenti parancsoknak.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

"Cuki (W7)" - Ez a tervezett viselkedése. A bejelentés pont arról szól, hogy Developer Mode-ba kapcsolt új Insider Windows 10-eken ezentúl nem kell elevated command prompt a symbolic link létrehozáshoz. Az Általad tesztelt környezetben kell, onnan próbáld.

"egyszerű módszer is van arra, hogy kiderítsem, hogy 2 fájl egymás hard linkjei?"
fsutil hardlink list <filename>
vagy findlinks.

Üdv,
Marci

( Zahy v | 2016. 12. 06., k – 07:03 )

Mivel a történelem ismétli önmagát, hamarosan fantasztikusabbnál fantasztikusabb történetektől fog az informatikai világ fetrengeni a röhögéstől, mert nyilván az MS (illetve hát majd valamelyik App fejlesztője) is elköveti azt a hibát, amit mindenféle pletykák szerint valamelyik korai SunOS-ben elkövettek, miszerint az "rm symlink" parancs lazán kitörölte a symlink által hivatkozott fájlt.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Szerintem az elég cáfolat, hogy jó pár éve nem fenti módon működik. 


touch a
ln -s a b
rm b

fenti sorozat után tudtommal minden mai rendszerben "b" törlődik és nem "a", de valamelyik korai SunOS-ben ez "a"-t törölte.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( Oregon | 2016. 12. 06., k – 11:22 )

Ilyen laza több évtizedes késést én nem twittelnék ki, hanem csendben megcsinálnám.

( apostroph3 | 2016. 12. 06., k – 12:57 )

fogynak a biztonsági rések?
hát 1000 a munka, ezek meg itt játszadoznak?

( bucko | 2016. 12. 06., k – 13:02 )

Minő újdonság!
A wiki szerint meg Windows2000 óta létezik. Bár ezt nem tudom, de WindowsXP SP2 alatt használom.
No, ezért nem kell Windows10! :D

Boccs! Nem az olvasási képességemmel/hajlandóságommal van probléma, hanem a felfogóképességemmel. :(
Már értem: A vagy 15 éve létező funkciót most már a prosztó júzer is használhassa. Ráadásul third party zoftwer nélkül! Belátom, hogy ez tényleg fejlettebb támogatás.

Ami meg "új": However, the functionality enabling cross-host symbolic links requires that the remote system also support them, which effectively limits their support to Windows Vista and later Windows operating systems.

> Belátom, hogy ez tényleg fejlettebb támogatás.

Amúgy igen, csak későn jött.

> which effectively limits their support to Windows Vista and later Windows operating systems.

Vagyis? Az a baj, hogy egy új feature nem kerül bele azokba a verziókba, amik már security patch-eket sem kapnak? :)

AZ én olvasatomban inkább azt jelenti, hogy csak a Vistától kezdve van cross-host link.
Vagyis egyáltalán nem baj, meg aztán nincs is másik vindózom, amit linkelhetnék. Meg minek.

Mindössze arra használom, hogy minden asm projekt a ../inc helyett a ./inc dirt lássa. Ezért kényelen vagyok fenntartani 1 db NTFS-t. :(

Okosodjál egy kicsit, olvasgassál és értsd meg a szöveget: https://en.wikipedia.org/wiki/NTFS_symbolic_link
A junction meg az, amikor áramkört tervezek és CTRL J hatására tudok tenni egy pöttyöt két drót kereszteződésére. :D
Magyarul kötés.
A symlink (a junikszos) meg egy alias, mindössze egy string.
Elmondom Asimovval is (kicsit szabadon): Ha az ember meg a robot tök egyforma, akkor nem mindegy, hogy robot vagyok-e?
A symlink esetén mindegy, hogy hogyan csinálják vagy minek nevezik. Csak a felhasználói élmény számít, miszerint egy ojjektumba be tudsz izélni egy másik ojjektumot, ami mutat egy harmadik ojjektumra és - az avatalan szemlélő számára olybá tűnhet - az előbbiről azt hiszed, hogy az utóbbi. Vagy fordítva.
De a vak is láthassa a symlink sokkal elegánsabb. ;)

Egyébként az NTFS Link-et használom.

Köszönöm a kioktatást, attól még az XP-ben gyárilag nincs elérhető symlink, a 2K-ban nem is volt, mert a junction csak könyvtárra megy.
Tehát a symlink felhasználói élmény 2K/XP-n elég rossz.

„Ha az ember meg a robot tök egyforma, akkor nem mindegy, hogy robot vagyok-e?”
Nem, mert a robotokat köti a három törvény.

Szivesen. Így már azt is tudod mi a szövegértés és a hozzáértés közti különbség. ;)

Ez a "gyárilag" pedig a filozófiák harca! Van aki ragaszkodik a windows szűziességéhez. Ha nem sikerül az idegen partíciót törölni, akkor kidobja a diszket. :) Viszont igen sokan third party programokat használnak. Az említett NTFS link lehetőséget használó programok csak elérhetővé teszik a rendszeben már meglévő funkciókat.

És igen! Az XP-ben a symlink szegényes, mint ahogy a unix sem tartalmazott közel 10 évig symlinket.

De látom mit nem értettél meg. Ha a robot==ember, akkor pl. egyik sem öl. Mindegy miért. A junction másképp működik mint a symlink, de ugyanazt meg lehet vele csinálni. (Természetesen nem akármit és ráadásul XP alatt. Ez igaz.)

( dj | 2016. 12. 06., k – 15:58 )

Biztosan bennem van a hiba, de ez valahogy soha nem is hiányzott windows alatt.

( segabor | 2016. 12. 07., sze – 12:12 )

Még pár év és lesz forward slash is!

--
Kinek nem inge, ne vegye gatyára

A Powershell-re gondoltam. Attól ksh-s, hogy ksh-ban írtam. Futtatni pedig ennek megfelelően szoktam:


$ cat .sig
#!/bin/ksh
#
# See my GPG key at http://www.Zahemszky.HU
#
Z='21N16I25C25E30, 40M30E33E25T15U!';
IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ ';
set -- $Z;for i;{ [[ $i = ? ]]&&print $i&&break;
[[ $i = ??? ]]&&j=$i&&i=${i%?};
typeset -i40 i=8#$i;print -n ${i#???};
[[ "$j" = ??? ]]&&print -n "${j#??} "&&j=;typeset +i i;};
IFS=' 0123456789 ';set -- $Z;for i;{ [[ $i = , ]]&&i=2;
[[ $i = ?? ]]||typeset -l i;j="$j $i";typeset +l i;};print "$j"
$ ksh .sig
hello, world!
   n  i  c  e  2   m  e  e  t  U!
$

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

És vissza is jutottunk a "Hogyan szerzed meg bash-al a default gateway IP-címét legegyszerűbben?" című kérdéshez... :)

szerk.: Tisztábban fogalmazva: míg Unix/Linux környezetben mindenkinek természetes, hogy külső programot hív meg és annak a kimenetét hasznosítja, ha a PowerShell-lel teszi ezt valaki, azon meg -- úgy érzem -- gúnyolódtál.

Üdv,
Marci

> több év Linux tapasztalat után

Próbálj meg UNIX rendszereket (lehetőleg többfélét) használni, ráadásul olyanokat, amikre nem telepítgetünk mindenféle szirt-meg-szart - elég hamar kiderül, hogy mire jó. (Pl. ilyen az, amikor valaki supportot nyújt, akkor nem kezd el a customer gépére azért bash-t telepíteni, mert ő azt szereti.) Terminálnak valóban nem való (arra ott a konzol alrendszer, meg az xterm), de interaktív shellnek - vagy mint a .sig-em mutatja, egyszerűbb feladatok megoldására is alkalmas. Ráadásul mivel a ksh sok évvel korábban már elterjedt volt, mint hogy a bash a Linuxszal elterjedt volna, így egy bizonyos életkor felett lehet, hogy megbocsátható, ha valaki nem változtatja meg a szokásait. (Én már nem nagyon fogok rászokni a vim-re sem a klasszikus vi helyett, mert az nvi is kielégíti az ilyetén igényeimet.)

Mondjuk ha több évi Linux tapasztalat után nem ismered a

a) chsh parancsot
b) a ~/.profile -t és az ebbe beírható "exec bash" mechanizmust

akkor még van mit tanulni ;-) Amúgy meg man ksh, és kiderül, hogy elég kevés olyan funkciója van a bashnak, amit a ksh nem tud. Legfeljebb alapból nincs bekapcsolva (pl. .history mechanizmus, parancssorszerkesztés), vagy nem ugyanazzal a billentyűkombinációval éred el (fájlnévkiegészítés pl. TAB-TAB helyett ESC-ESC).

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

> Több év tapasztalat != több év tanulás és olvasás.

Hát nem ám. Nálam a több év tapasztalat odáig fajult, hogy beláttam, hogy Lenin elvtársnak igaza van: ami nem megy, azt nem szabad erőltetni.

Amikor a terminálban írom a szöveget, a ksh meg a tab lenyomásától kiakad, elvesztem az érdeklődésemet. Lenyomom a DEL billentyűt, berak egy ~ jelet, meg tök vicces, csak nem díjazom.

Már rég óta nem érdekel, hogy mi miért nem megy, milyen export-ot kell beírni, hogy menjen, milyen peccset kellene letölteni a netről, vagy melyik eldugott konfig fájl mely 23 paraméterét kell ráolvasással beállítani, egyszóval kiégtem. Nem érdekel többé a filozófia, nem akarok tanulni, nem akarok okosodni, beírom, hogy "bash" és örülök. A hosszú évek során fogyasztóvá degradálódtam.

Így is elég sokat vuduzok a konfig fájlok között, hogy működjenek a cuccok Linux alatt, nincs szükségem ksh-s varázslásra is mellé, amikor a bash ezotéria nélkül is megy.

Hááát...
A ksh soha nem akad ki a tab lenyomásától, hiszen az csak egy "betű".
Sőt, a ksh soha nem ír ~ jelet.
Inkább mondhatni halvány segédfogalmad sincs a terminál mibenlétéről. Legyen az a terminál valódi (pl. soros porton feldugott), konzol (olyan, ami a gépre dugott klaviatúra+képernyő), vagy virtuáls (pl. putty telnet/ssh üzemmódban) - mindegyik tulajdonságairól informálni kell a rendszert! Ezt a TERM környezeti változó segítségével lehet megtenni, amely a terminfo adatbázisban hivatkozik egy terminál típusra.

Sajnos akár olvasol akár nem, ezek a rendszerek így működnek. A billentyű megnyomásának hatására beérkező karakter szekvencia utazás közben kb. 8 konverzión esik/eshet át. A kiírt karakter a képernyőig kb. 6 konverzión.

Tehát mégegyszer: Ezeknek a konverzióknak 99%-ig semmi közük nincsen az alkalmazott shellhez.
Azaz annyiban mégis van, ha valamelyik init script vizsgálja a shell típusát és más-más shellhez eltérő terminálemulációt állít be. Ez meg a diszró készítőinek a sara!

Nézd meg pl. a putty Terminal->Keyboard menüjét! Ott a ~ és nem a shellben.

Lassan 2017-et írunk. Szerintem "export TERM" nélkül is tudni kellene, hogy törölsz, vagy kukaccal játszol.

2000 óra nem gyártanak számítógépet DEL gomb nélkül. El kellene jutni az informatikának odáig, hogy "export TERM" nélkül is felismerje, hogy melyik kurva billentyűt nyomtam meg és ne kezdjen nekem a kukacával játszani, amikor törölni akarok.

Borzasztó nehéz feladat. Gondolom bash alatt is beletellett vagy 20 évbe, hogy felismerje, de ott legalább már megírták és megy. Szimplán copy-paste-elni kellene azokat az irgalmatlanul bonyolult részeket.

:)

Ugyan nem vagyok jártas a témában, de szerintem ez nem igazán a shell dolga. A shell és a terminál két külön dolog. A terminál a fizikai kapcsolatot tartja a felhasználóval, ha lenyomsz egy billentyűt, azt küldi a shell felé, illetve, ha a shell küld egy karaktert, azt megjeleníti a terminál. Viszont terminál típusonként más szekvencia állítódik elő egy adott gomb megnyomásakor, ezért kellenek mindenféle konverziók, s ezért kell ismerni a terminál típusát. Szigorúan szerintem, de erről NevemTeve tudna értekezni, mert úgy emlékszem, foglalkozott behatóbban ilyesmivel.

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

Nem tudod a kettőt szétválasztani és értelemszerűen a kényelem dönt. Végig bash-t használsz, mert az kényelmes és azt ismered és végül #!/bin/bash-sal kezded a szkripjeidet is. Miért ksh-ban csináld, amikor reggeltől estig bash-elsz.

Nyomod a TAB-ot az kiegészít, működik a fel/le gomb,.. A ksh-t meg használják az 1970 unixokon, ha jólesik. Ott aztán kedvükre lehet export TERM-ezni. Csak én ne találkozzak vele.

Én teljesen elvi megközelítésből írtam azt, amit. A lényeg, hogy terminál != shell. Ettől még egyfelől ott a választás szabadsága, meg az is, hogy egy adott terminálhoz tartozó környezeti változókból érdemes dolgozni, ha jót akarunk magunknak.

Én is szeretem a bash-t, de hiába, ha a router-emen a busybox-os ash van, ami például nem tud tömböt kezelni, továbbá a busybox-os awk például nem ismeri a switch () case szerkezetet. Igaz, nem is fontos ez, mert az awk-nak viszont jó az asszociatív tömb kezelése, így azzal kiváltható a switch () case.

Csak azt akartam mondani, sokszor választhatsz eszközt, de amikor egy teljes Linuxnak kell elférnie 4 MiB-ban, valamint van 32 MiB RAM-od, hirtelen az ember arcára fagy a mosoly. ;)

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

A busybox az másik állat, mini rendszerekre való. Mondjuk a 8 Giga RAM-os 4 processzoros 2.4 GHz-es gépemen nem feltétlen használnék busybox-ot.

Személyesen érintve vagyok, mert a munkahelyemen alapértelmezett a ksh, ezért utálom ennyire. Belépsz egy 16 processzoros 4 GHz-es, 50 GB RAM-os gépre, azt nyomod a ksh-t ezerrel. Talán javasolni fogom, hogy cseréljék busybox-re, mert fantasztikus élmény. :)

Sokadszor hivatkozol arra, hogy valami alapértelmezett. Igazából pár kérdésem van, pl: hogy ha valami nem a (neked kényelmes) alapértelmezést használja, akkor te azt kidobod a kukába? Mert ha így lenne, végképp nem értem, korábban miért írtál konfig fájlokról és azok piszkálásáról. Valamint hogy mit csinálsz, amikor valaki átállítja az általad ismert alapértelmezést. Harakirit követsz el, vagy végre elkezdesz olvasni?

Miért kell utálni a ksh-t? Cseréld le, és kész. Persze akár meg is tanulhatnád, és az is kiderülne, hogy használható - igaz, félek te a bash-t sem *ismered* , hanem legfeljebb használod egy-két funkcióját.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Nem tudod leváltani az alapértelmezést (nincs jogod), az meg nem megy, hogy a legelső parancs bash legyen.
Amikor egy host-on nincs memória, beledögölhetsz egy induló bash-ba. Próbáltam, de több bajom volt vele, mintha kézzel írnám be, hogy bash.

Ha nincs indulási parancs, akkor elképzelhető, hogy nem vágnak ki automatikusan hostok ha betelt rajtuk a merevlemez. Márpedig valahogy kell takarítani is. Ráadásul sok szkript csak ksh alatt működik, mert ez az alapértelmezett.

Olyan ez, mint az internet explorer volt, utálod is, rühelled is, de kikerülni nem tudod. Beírod, hogy bash és ha ksh script kell, beírod, hogy ksh...

Van olyan 4-5000 soros scriptem, ami AIX+ksh/linux+bash alatt is fut. Úgy gondolom, nem értem miről beszélsz. ;) (Jajjj, dehogyisnem!)

Se memória, se diszk. Erről egy régi buszmegállóban kiragasztott hirdetés jutott eszembe:
X összegért bármilyen lakásmegoldást keresek.
Egy kritikus meg alá írta: Ó te szegín, minek élsz?!

> Ráadásul sok szkript csak ksh alatt működik, mert ez az alapértelmezett.

Ezt majd fejtsd ki bővebben, mert itt valami nem kerek. Szerintem kevés olyan ember van mint én, aki direkt azzal vesztegeti az idejét, hogy tudatosan bash-inkompatibilisre írjon meg egy scriptet. A fordítottja (bash alá írni ksh-inkompat kódot) könnyű, elég declare-t írni typeset helyett - az első bashizm, a másodikat mind a kettő ismeri; illetve elég $[ kifejezés ] formát írni $(( kifejezés )) helyett; ezek azért jó példák, mert a bash dokumentációk kifejezetten sugallják, hogy ezeket a formákat használd - és ne a kompatibiliset. Ha valamit ksh-ra optimalizálnak, az kb annyit jelent, hogy print-et ír echo helyett, illetve mint a korábban bemásolt .sig-em, használ olyan typeset funkciót, amit a bash nem ismer - ez meg kb a 10-estől eltérő számrendszer használata - ez viszont elég csekély számű kódban lehet szükséges. Szóval erősen érdekelne, hogy ki volt olyan ügyes (és mit használt), hogy csak ksh alatt működőre írta meg a kódot.

Szerk: ja, egy csak ksh alatt működő kódot érdemes elkezdeni (bash-ra) hordozhatóra átírni, ezzel segítve a majd egyszer száz év múlva esetleg előforduló migrációt.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Nekik sikerült. :)

Nem kell a dolgon meglepődni, a java is futhat kizárólag Windows 2000 alatt. Megfelelően megírt kóddal elérheted, hogy más rendszeren még csak véletlenül se induljon el.

Tudom, hogy a bash és a ksh hasonlít egymásra. Nem kell magyarázni, de néhány elszállt főokos megoldotta az inkompatibilitást.

(Annyit azért hozzátennék, hogy közben volt időm egy kicsit gondolkodni, és találtam olyan funkciót, ami hasznos és másként kell megcsinálni. Ez pedig a tömbváltozók egyszerre történő feltöltése. Ksh alatt: 


set -A tömbnév érték0 érték1 érték2 ...

bashban ezzel szemben 


tömbnév=( érték0 érték1 érték2 ... )

a használandó forma. De igazából ha egyesével töltjük fel, vagy amikor lekérdezzük, mr ott ugyanúgy kell használni.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Nem érzem kihívásnak. Ha tudsz egy-két nyelvi elemet, amely működik a ksh-ban, de nem fog menni a bash-ben, akkor használni kell, s meg is vagyunk. A hobby jobb indok, de az értelmét nem látom. Arra szerintem nehezebb odafigyelni, hogy a kódot a lehető legtöbb shell futtatni tudja, s a hordozhatóságnak még értelmét is látom.

Én kényelemből kihasználom a bash lehetőségeit, ezért #!/bin/bash van az első sorban, nem pedig sh. A scriptjeim nem is hordozhatók, és erre nem vagyok különösebben büszke, de nem is bánom, mert ha mindig csak a hordozhatóság számít, akkor semmi értelme az egyes shell-ek különleges szolgáltatásainak. Én kihasználom ezeket. Aztán a router-emen ash-ban szívok néha, mert amit megszoktam bash-ben, ott esetleg nem használhatom. Sebaj, akkor írom másként.

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

Láttad a .sig-emet. Amikor kiderült, hogy a ksh tud tizestől eltérő számrendszerben dolgozni, akkor azt akartam kihasználni, pont leszartam, hogy a bash nem tud. Mivel ez volt a lényeges, utána az már csak szórakozás volt, hogy az echo-k helyett printet írjak (pedig ettől hosszabb lett), vagy hogy a ciklusokat a nem túl jól dokumentált módon írjam meg. A .sig-emtől eltekintve általában ügyelek a hordozhatóságra, időnként szórakozásképpen szoktam olyan ujjgyakorlatokat csinálni, hogy ugyanazt a funkciót a különböző shellekben hányféleképpen lehet megcsinálni, ezek közül melyik mennyire gyors/lassú - vagy épp melyik az, amit a különböző shellek mindegyike ismer. (És itt nem csak ksh/bash, hanem ash, FreeBSD-sh, és időnként busybox szokott beleszólni; régebben ellenőrizem ezeket HP-UX-féle sh-n, esetleg máson.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Abban az aláírásban gondolom az a poén, hogy nagyon nem látszik belőle, mi lesz a futás eredménye.

Más számrendszerben a bash is ismeri a konstansokat, bár szerintem nem is erre gondoltál:

       Constants with a leading 0 are interpreted as octal numbers.  A leading
       0x or  0X  denotes  hexadecimal.   Otherwise,  numbers  take  the  form
       [base#]n,  where the optional base is a decimal number between 2 and 64
       representing the arithmetic base, and n is a number in that  base.   If
       base#  is omitted, then base 10 is used.  When specifying n, the digits
       greater< than 9 are represented by the lowercase letters, the uppercase
       letters, @, and _, in that order.  If base is less than or equal to 36,
       lowercase and uppercase letters may be used interchangeably  to  repre‐
       sent numbers between 10 and 35.

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

Bocsi, hogy beleszólok!
Már a kérdés felvetése is feleslegesnek tűnik. Valójában a "számrendszer" is felesleges, hiszen számítógépen nincs is 3.5 alapú számrendszer stb.
Tehát az első véleményem: Az egész l'art pour l'art.
Komolyan mondom, úgy 25 év és több százezer sor script megírása alatt soha nem volt szükségem számrendszerekre. Különösen a konverzióra.
Másodjára a "ki mit tud" vetélkedő is felesleges. Az az ökölszabály, hogy egy rendszeren a default shellt érdemes használni. Ha dolgozni szeretnél, akkor ez a leghatékonyabb módja a gyors és biztos feladatmegoldásnak. Ha mégis a hordozhatóság-mánia kerekedik felül, akkor a rendelkezésre álló lehetőségek unionját érdemes felhasználni. Kevesebb okoskodás, kevesebb munka.
Harmadszor meg nincs olyan "alapművelet" - ami ha véletlenül hiányzik - ne lehetne néhány sor c programmal előállítani. (Tudod, ez a unix.)

A legfontosbb pedig az, hogy a unix nem csak oprerációs rendszer, hanem filozófia is. Ha ezt megérted, akkor mindjárt a lényegesebb dolgok irányába fordulhatsz!

Azzal egyetértek, hogy l'art pour l'art. De kb erről szólnak az olvashatatlan aláírások és a "Just another Perl hacker"-tipusú kódok. De azt már nem fogadom el, hogy az alapértelmezett eszközt akarjuk mindig használni. Amióta van she-bang, azóta nekem pl. sokkal kényelmesebb a #! /bin/ksh kezdetű kódírás. Ha hordozhatóság kell, akkor pedig nyilván a LNKO a megfelelő hozzáállás - pont ezért jó ha tudja az ember azokat, hogy mi az ami bashizm, vagy hogyan lehet tömbváltozókat általánosságban kezelni a különböző shellekben.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

> Nem tudod a kettőt szétválasztani és értelemszerűen a kényelem dönt.

De szét tudod. Amikor a rendszer pl. bebootol, baromi sok shell-script fut (igen, mlg a csodás systemd-s rendszerek alatt is), oszt ezek jelentős részének kurvára tök mindegy, hogy milyen terminál(emuláció) van - illetve hát nincs. Teszik a dolgukat. Amikor a grafikus felöleten rákattintasz a Mozilla ikonjára, akkor a háttérben elindul egy shell script amelyiknek nem nagyon számít, hogy milyen terminált használsz, csinál amit akar, majd a script végén elindul egy bináris, amelyiknek viszont nagyon is fontos - lévén ha nem alkalmas grafikus megjelenítésre a környezeted, nem tud dolgozni.

A másik, hogy arra próbálunk itt többen rávilágítani neked, hogy nem, nem igaz, hogy "értelemszerűen a kényelem dönt". Van amikor az, és baromi sok olyan helyzet van, amikor más dönt - pl. az egyik triviális: hogy elérhető-e az az eszköz, ami kényelmes. Amíg felhasználó vagy, addig gondolkozhatsz így, mihelyt arrébb lépsz, már nem biztos.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Ez ide illik. Nem csak NevemTeve hanem talán én is értek egy keveset hozzá. ;)
Amit feljebb írtam a 8 illetve 6 konverzió, azt nem az ujjamból szoptam. Terminált (szoftvert) használtunk már a 90-es évek eljén SCO-hoz. 95 körül meg készítettem (így egyes számban) egy 123 terminálos rendszert. Ebből 45 régi pc volt, amin az általam írt bios extension-ként futó Wyse60 terminál ment egy kis saját tervezésű soros bővítőkártyára applikálva. Természetesen a programot bios helyett dos alatt is lehetett futtatni. Készült hozzá két féle terminfo, az egyik a munkahelyekhez, amásik meg a Dataflex fejlesztőrendszerhez. Az utóbbi színes-szagos, hotkey gazdag ;) kivitelben. Így a pécés fejlesztőrendszerrel azonos módon működött terminálon is, AIX alatt.
(Eddig az essay. :))
No, szóval el vagy egy kicsit tévedve. A shell sose küld karaktert a terminálra, annál inkább a kernelen keresztül. Kifelé menet átmegy egy képernyő optimalizáló modulon. Bármilyen bonyolult szekvenciákat is használ a terminál - és ugye bármilyen terminál -, ez gondoskodik arról, hogy a lehető legkevesebb karakter menjen ki a vonalon. Persze a vonal nem feltétlenöl soros vonal, hanem lehet telnet, vagy bármi egyéb is. Befelé is több szűrő létezik az egyes szekvenciák kezelésére. Ha maradéktalanul meg akarod oldani ezek kezelését, akkor általában az összes lehetőségből kell itt-ott csipegetned.