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

 ( trey | 2016. december 5., hétfő - 18:21 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

Üdv,
Marci

ez tőled +100 :D lol :) még jó hogy nem ittam kv-t olvasás közben :)

+1

Marci, ezt most nagyon köszönöm, _tényleg_ feldobta a kedvem.

:-D :-D

--
Én nem a Microsoftnál dolgozom.

Nincs aláírásom :-)

"Forgatható kormány! Nyitható ajtók!" *

*csak, ha le van tekerve az ablak. (developer mode)

:)

És hogyhogy nem pereltétek még be a Unixot/Linuxot/BSD-t?

+sok

Ez a hozzászólásod mindent visz, különösképp, mert Te írtad! :DD


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

:D
--
"Sose a gép a hülye."

+1

Engem ez lenyűgöz! :)

+1
:D

+1

felnevettem. köszönöm.

Ez engem is odab*szott

---
--- A gond akkor van, ha látszólag minden működik. ---
---

MS<3Linux
code>LOAD "http://digx.hu",8,1

((most majdnem írtam valamit, de, nem tudok kacsacsõröket rakni mert a drupal ahelyett hogy átkonvertálná õket, inkább nem jeleníti meg (??). ))

Aztán a HTML entity-kről tetszett-e már hallani? &lt; &gt; és társai.

<nem /> :D
--
http://naszta.hu

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

Mintha hardlink pont egyáltalán nem lett volna. FIXME

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

XP: fsutil hardlink create
Vista-tól: mklink /h

Üdv,
Marci

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

Cool, épp ideje, hogy ez a section outdated legyen. :)

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 ez nem hiba, by design, és ezért van unlink. De cáfoljatok meg, nem vagyok nagy sün guru.

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?

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

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

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

A headline-on kívül ezek szerint nem sikerült elolvasni a cikket. :)

"Starting with Windows 10 Insiders build 14972, symlinks can be created without needing to elevate the console as administrator."

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? :)

http://offmedia.hu/assets/images/abel2-2016-11-08-11-04-07.jpg :)

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

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. :(

XP alatt gyárilag nincs userspace symlink. 2K alatt egyáltalán nincs symlink, csak junction van. Pontos szövegértés!
Tehát, ha valamit használsz XP alatt, akkor az vélhetően ez: http://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html#symboliclinksforwindowsxp
Igaz, ez sem újdonság.

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.

> Nem, mert a robotokat köti a három törvény.

Míg ugye az ember nyugodtan gyilkolászhat. Mégiscsak inkább legyen robot.

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

Ez már filozófiai kérdés. És Asimov elég komolyan elemezte is a problémakört. Főleg az első törvényt. A második pedig jobb, ha emberre nem értelmezhető, mert az a rabszolgaság. A 3. ebből kifolyólag eleve értelmezhetetlen emberre.

nem ez lenne az első dolog ami értelmezhetetlen emberre, mégis azt teszik :)

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.)

Ha köti a három törvény, akkor mégsem tök egyforma.

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

nekem sem :)

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

--
Kinek nem inge, ne vegye gatyára

Windows Subsystem for Linux segítségével már van is. Érdemes a PowerShell-re is egy pillantást vetni e téren...

Üdv,
Marci

Képes már lefuttatni a ksh-s .sig-emet?

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

Nem tudom dekódolni: Mi a rejtett alany? A usermode Ubuntu a WSL-en?
Továbbá kérlek, segíts megfejteni, mi az a ksh-s .sig, mitől "ksh-s" és hogyan futtatod most? (A ksh-t tudom, hogy mi :D )
Ki tudnád fejteni, mi lenne az elvárt viselkedés?

Üdv,
Marci

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?

"Képes már lefuttatni a ksh-s .sig-emet?"

Nem.

Üdv,
Marci

Még pontosabban: igen :D

PS C:\test> dir


    Directory: C:\test


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        12/7/2016   7:02 PM            431 .sig


PS C:\test> bash -c "ksh .sig"
hello, world!
   n  i  c  e  2  m  e  e  t  U!
PS C:\test>

Üdv,
Marci

Ezt is megérhettem :)

Üdv,
Marci

Nyugi! Meglesz az a prémes! :)

Elmagyaráznátok ezt?
Zahy azt kérdezte, poweshell alatt megy-e.
Ha jól látom, te a bash parancsot adtad ki.
Zahy örül.

Én azt hittem, a powershell és a bash az két külön dolog.

Valóban két külön dolog, és a fenti esetben mindkettő használva lett. Ezzel Zahy ksh-s .sig-je lefuttatható lett PS-ből és a kimenete is feldolgozható vele.
Ha jól értem, ez volt a feladat.

Üdv,
Marci

Értem, szóval ha poweshell alól bash használatával megy, akkor teljesítette a követelményt. OK, köszi

É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

nem gúnyolódtam.

Elnézést, félreértettelek.

Üdv,
Marci

Hát, több év Linux tapasztalat után sem jöttem rá, hogy mire való a ksh (terminálnak nem használható).

Munkahelyen nálunk alapértelmezett, egy feature-ét használom is rendszeresen: beírom, hogy bash, utána minden szép és jó lesz.

:)

> 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?

+1
Ezt tudomásul kell venni! Több év tapasztalat != több év tanulás és olvasás.
Nálad nem alapértelmezett a set -o vi?!

> 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?

Na, meg aztán minek vannak a konfig file-ok, a testreszabhatóság, ha nem használnánk őket. Ennyi erővel mindent be lehetne drótozni a programba, minek is konfigurálhatóság. Az lenne, amit tud, s úgy, ahogyan tudja. :)


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

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?

kevés olyan ember van mint én, aki direkt azzal vesztegeti az idejét, hogy tudatosan bash-inkompatibilisre írjon meg egy scriptet

Ebben mi a pláne?


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

hobby? kihívás?

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

A lényeg az utolsó mondat: "akkor írom másként" - ehhez viszont ismerni kell az egyéb lehetőségeket.

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

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

Ezt ismerem - és a ksh is ismeri. De hogy konvertálsz A-alapú számrendszerből B-alapúba bash alatt? Mert ksh-ban elég annyit mondani, hogy typeset -iB A#xyz és máris kész a konerzió.

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

Ha minden kötél szakad, függvényt írok rá, de értem, amit mondasz, hogy nincs kész, instant megoldás.


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 tudom, hogyan lehet, de én például ash-ban - mivel nincs tömb - ezt csináltam:

eval value=\$VALUE_$i

Ez az i-edik elemre hivatkozás, ahol lényegében a változó nevének vége az index.


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

Mindenki használjon, amit akar.

Ha a munkahelyen 3 klikkel át tudtam volna állítani a ksh-t bashre, nem utálnám ilyen vehemensen, zsigerből.

Nem az a nagy baj, hogy több shell is van egy rendszeren, hanem az, ha kizárólag egy van rendesen támogatva, választás nincs.

Na jó, de gondolom, van bash kéznél, így tudod azt használni. A busybox-ot példaként hoztam arra az esetre, amikor az ember sarokba szorul a fizikai korlátok miatt.


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

> 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?

Pont ezért egy oprendszer default shell lecserélése (még ha időszakosan is) nagy kockázatot jelent.
A "kényelmes" ebben a környezetben eléggé értelmezhetetlen fogalom.

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.

A shell sose küld karaktert a terminálra, annál inkább a kernelen keresztül.

Jó, ha meg lehetne kerülni a kernelt, megette a fene az egészet. Csak azt akartam mondani, hogy az ember és a shell között van a terminál.


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

Ok. De nem ezen volt a hangsúly, hanem amit leírtam. Azaz mi mindent tesz még a kernel ilyenkor. Persze a dumb terminál kivétel.