scp nem hajlandó letölteni szóközös könyvárban levő szóközös fájlt.
izézőjel sem jó, \ sem felel meg neki.
Hogyan kell akkor megadni az scp-nek a szóközös remote fájl helyet?
Off: Én vagyok az egyetlen aki szerint nagyon nem kellene szóköz, spéci karakter stb. a fájl névbe, akár rendszer szinten kellene tiltani? Én ha nagyon elválasztás kell akkor a szokásos oo class nevezék módot használom, szóköz helyett nagybetű. Ha más által hagyott szemét miatt van a probléma akkor bocsi.
Ezzel a gondolkodással van a baj.... 2015-ben már alap kéne, hogy legyen, hogy nincsenek ilyen szopások a fájlnevekkel, de miattatok a lusta programozók sosem veszik az energiát, hogy átírják a bugos szar programjaikat.
Ja meg ilyen 卐, meg ☭, esetleg ☮ kell a fájl nevekbe? Mert ezek mind unicode karakterek. Szerintem inkább ne, a szóközzel meg terminálban csak szívás van szóval az végképp kerülendő dolog.
Gondolom tudod, h ez a foto mekkora csusztatas. Nem arrol van ugyanis szo, h a grafkus feluleten meg lehet-e jeleniteni egy kriksz-krakszokat tartalmazo fajlnevet, hanem hogy egy eredendoen karakteres feluleten hasznalt alkalmazasnal mekkora problemat okoznak ezek a kriksz-krakszok. Es igen, tudom, hogy az a gond, hogy meg mindig meg kell kulonboztetni karakteres es grafikus feluletet.
Szerintem az együttműködési készséggel van a gond. Nem csak "bizonyos unicode-os" rendszeren működik, nem csak grafikus, hanem karakteres felületen is.
De ha pl. scp-vel másolok, akkor a távoli rendszer képességeire is figyelemmel kell lennem, amit vagy ismerek, vagy nem.
Gondolom az nem okoz gondot, hogy az amerikai kollégákkal angolul menjen a kommunikáció, a magyarokkal magyarul, vagy angolul. Amikor meg mindenféle náció előfordul, akkor keressünk valami közös nyelvi minimumot (vagy annak maximumát). Példa az önkorlátozásra, ami átvihető a kommunikáció egyéb területeire is. Mindenki olyan fileneveket akarjon használni, amit az adott ökoszisztéma képes kezelni.
Pl. a Windows is POSIX, persze csak bizonyos feltételekkel. Ahol "P", a portable.
Van olyan eset is, hogy unikódos szöveg kilóg pl. az adatbázis mezőméretből, vagy a filerendszer filenév-hosszból (opsz, a FAT elég korlátos lehet bizonyos unikódos oprendszeren is).
Szóval, a csak mert megtehetem, szerintem még nem elég ok.
Egyébként alább látszik, megtehetném - de fel sem merül (megvallom a jelet egérművelettel másoltam a terminálba).
"ne használjunk Unicode karaktereket" Amit nem lehet begépelni egy ansi US billentyűzeten azt ne használjuk fájlnévben. Szerintem ez egy normális elvárás mert ha véletlen olyanhoz kerül akinek nincs ilyen betűje az anyázni fog.
Szerintem meg az egy teljesen normális elvárás, hogy használhassam már a nyelvemben található betűket.
Sajnos pont a világ egyik legszűkebb betűkészletű nyelve lett az info alapja, ezért azt gondoljuk, hogy normális, hogy csak az megy, de igazából nem, ez sosem volt normális, mindig is szar volt, csak már beleégett az emberek agyába, hogy ez így jó.
Disclamer: én sem használok ilyet filenévben, sőt, a spaceeket is cserélem, mert már megszoktam, de ettől még nem lesz hülye, aki szeretné a gyerekéről készült képet Ödönke.jpg-nek nevezni, nem odonke.jpg-nek
Ennyi erővel elvárhatnánk azt is, hogy dir/ls helyett könyvtár/lista paracsok működjenek. Vannak szabályok, ha tetszik, ha nem. Kb, amikor valami elcseszett backupból tolta vissza a júzer a dolgait w7 alá és egy könyvtárat sem tudott megnyitni. (Már nem emlékszem, azt hiszem ! jelek kerültek bele -de lehet valami más karakter volt- és a win nem volt hajlandó sem megnyitni, sem átnevezni. Live lnux alól kellett egy scripttel helyre rakni.)
üdv: pomm
Na de miért kéne magunkat hülye szabályok közé szorítani?
joco-macbookair2:~ joco$ alias könyvtár=ls
joco-macbookair2:~ joco$ könyvtár
Applications Documents Library Music Public
Desktop Downloads Movies Pictures
Nem kell elcseszett szoftvereket használni. Sambára, Azure-ra, mindenhova tolom az ékezetes és szóközös fájlneveket, mert ez így szép és jó. Nekem. Elvárom, hogy működjenek, és működnek is. Akinek jobban bejön az egyszeru_fajlnev.txt, hajrá, azt sem tiltja senki. Meg lehet próbálni megtiltani orosz, japán, stb. kollégáknak a saját betűik használatát, de attól nem fejlődik a világ sehova.
Annyival egészíteném ki, hogy az sem baj, ha egy OS nem támogatja a Unicode-ot, de akkor felejtsük el az "elvileg működik", "nagyjából kompatibilis" és hasonló történeteket. Vagy igen, vagy nem. Pont.
Biztos előjön a barlangból pár régi motoros BOFH, aki még PDP-11-et vagy hasonlót használ, hogy rámmorduljanak, de őket leszámítva szerintem ma már nincs olyan, hogy egy OS vagy library ne támogatna Unicode-ot. Sok-sok év alatt végre eljutott a programozók agyáig. Mondjuk kicsit elkanyarodtunk, mert eredetileg nem ékezetes betűkről, hanem egyszerű szóközökről van szó. Aki shellbe van ragadva, annak sorry, ez egyszerűen egy ilyen világ, tessék escape-elni. Nagy ritkán van úgy, hogy pl. egy regex miatt muszáj bash+grep kombót ragadnom, hát minden alkalommal jól lefáraszt az a sok \. Általában vannak kényelmesebb eszközök. SCP-re biztosan.
Szoval ha en talalkozom egy szoftverrel, aminek a legutolso (amugy elvben aktivan tamogatott, fejlesztett) verzioja szarul kezel ekezetes betuket, akkor ki a hulye? En, te, vagy a fejleszto? Es ha nincs helyette jobb, ezert ezt kell hasznalnom akkor megjavitod nekem? Ha raadasul nem is egyetlen ilyen szzoftverrol beszelek, hanem tobbrol, akkor mi van?
(Ami meg a bash+grep es sok \ -t illeti, meg kell tanulni hasznalni, lehet nem kell annyi \ .)
A fejlesztő a hülye, te meg sajnos így jártál. Ha nem kezeli az ékezetet, ne használj ékezetet. Persze menjen a bugreport, aztán vagy jobb lesz, vagy nem. Én is hányok egyes workaround-októl, de ha muszáj... :(
No nézzük, mi a helyzet azzal, ha egy OS támogatja a Unicode-ot, de teljesen. Legalábbis itt fentebb az szerepelt, hogy olyan nincs, hogy csak félig. Most megpróbáltam egy többé-kevésbé (nem én felelek érte, ezért nem tudom) up-to-date magyar nyelvű W7Prof-on létrehozni egy halom (pontosan 4 db) fájlt, amiknek nevében van szóköz, kis- és nagybetű és leginkább egy kupac ekezetes karakter is. A fájlok neve szépen sorban:
öt szép szűzlány őrült írót nyúz.txt
ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP.TXT
jött árvíz tűzvész rút gümőkór.TXT
JÖTT ÁRVÍZ TŰZVÉSZ RÚT GÜMŐKÓR.txt
no első probléma, hogy a 4-t már nem tudom létrehozni, mert nyafog az OS, hogy van már ilyen nevű fájl. Szerintem ugyan nem ugyanaz a két név, de ha jól tudom, itt alapból a kis- és a nagybetű ugyanaz. Azaz a 4. fájl neve ... KÓR-2.txt lett a békesség kedvéért. Ezek után Exploder-ben szépen kijelöltem mind a négyet, majd a jobb gomb, Küldés / Tömörített mappa menüponttal csináltam egy zip fájlt belőle. (Csak hogy ne lehessen belekötni abba, hogy winzip, winrar, egyéb nem MS-termék játszott szerepet.) Az így létrejött zip-fájlt átviszem Linux alá, és belenézek - szigorúan parancssorból, mert csak. Három különböző eszközzel is belenézek: "unzip -Zv'" (InfoZip v6.00), "7z l -slt" (p7zip v9.20) valamint "hexdump -C" (util-linux-2.19.1). És mit ad isten azt látom benne, hogy az összes rohadt ékezetes karakter elveszett, és helyettük baromságok látszanak. Kivétel nélkül az összes ékezetes karakter 1-byte-os lett. Valaki elmagyarázná, hogy ez milyen kódolású Unicode? És mit csinál majd ezzel a szarral egy angol vagy épp egy orosz nyelvű Win?
Második lépésként megcsináltam tök ugyanezt Winzip-pel is, pont ugyanaz az eredmény.
(És hab a tortán: korábban egy másik - ha jól emlékszem angol nylvű - Wines gépen is csináltam ilyet, és az eredmény az volt, hogy bizonyos fájlneveknél "fat", más fájlneveknél pedig "ntfs" jelzést mutatott az unzip -Z , és amelyik fat volt, azt nem tudta értelmesen kicsomagolni, amelyik ntfs-tipusú volt, azt meg igen, igaz ott nem is 1-byte-os ékezetes karakterek látszottak a hexdump kimenetében.) Ezek után ugyanezt eljátszom az ellenkező irányban, infozip-pel becsomagolom ezeket a szép kis UTF-8-as fájlnévvel rendelkező fájlokat, átküldöm a Win-re, és nem tud vele mit kezdeni. A 7z pl. lehetőséget biztosít arra, hogy zip kimenet esetén ( -tzip opció ) beállítsam, hogy a fájlneveket UTF-8-ban tárolja le (-mcu=on paraméter) - az más kérdés, hogy UTF16-módot kapcsol be.Eredmény: ugyanúgy nem tud vele mit kezdeni a Windows (illetve hát tudni tud, csak az ékezetes karakterek heélyett lesz valami szar).
Összefoglalom: Elvben mind a két rendszer Unicode-ot használ, ráadásul vagy 10-15 éve ez ZIP fájlban is kéne hogy rendesen menjen, osztán máris előállt egy inkompatibilitási hiba az ékezetes fájlnevekkel.
Van olyan tömörítőprogram (elég sok), ami belegányolja a szabványos .zip-be a Unicode-ot, de mint tudjuk, a .csv-t is lehet explode-dal olvasni. _Általában_ működik is. :)
Hol is? A changelogra gondolsz, miszerint "Added option for Unicode filename storage"?
Görgess le a szóban forgó részhez, ott azért elég sok "may be", "may use", "should", stb. megfogalmazást találhatsz, majd mindezt a jól hangzó "The choice of which storage method to use when writing a ZIP file is left to the implementation." (értsd: csináljatok, amit akartok) mondat zárja.
Vagyis ha mondjuk egy windows-os 7-zippel csinálsz egy unicode-os .zip-et, azt egyáltalán nem biztos, hogy a linuxos unzip parancs mondjuk fájlnév-helyesen fogja tudni kibontani.
Belenéznék abba a ZIP-be, ebben a pillanatban nincs előttem Win7. Ha a Win7 bugos, akkor az elég szomorú, mert úgyse javítják ki, de azért megpróbálnám jelenteni valahol. Illetve azt is megnézném, ha Linuxon csinálsz ilyen ZIP-et, ahhoz mit szól a Win7.
Levél ment. Ez utóbbi kérdésre pedig az a válasz, amit le is írtam. Pont ugyanúgy kriksz-kraksz látszik Win alatt is, akár InfoZip-pel, akár p7zip-pel csináltam a fájlt Linux alatt. :-(
Úgy látom, Windows-1250-nel vannak kódolva a fájlnevek. Ez a szar a 8-bites kódlapokkal, kb. lehetetlen őket megkülönböztetni metadata nélkül. Hülye a ZIP, de hülye a Windows is, hogy hagyja. Látom más írta, hogy a Windows 10 hibát ír ki ilyen esetben, az legalább korrekt.
A fejlődés égisze alatt úgy döntöttek a fejlesztő kollégákok, hogy arra bátorítják a gyártósort, kezdjék el használni mindazon karaktereket a szabad beviteli mezőkben (van bőven), amelyek nekik szimpatikusak.
Megkérdezhettem volna, hogy mi a francnak, mikor 10 fogorvos közül 9 nem tud különbséget tenni a hosszú és rövid magánhangzók között, de tudok én diszkrét lenni, ha bízom a tanulságos kimenetelben.
Eljött a konkretizálás pillanata: milyen hosszúak legyenek az egyes mezők, hogy biztosan beférjen mindaz, amit beírni akarhatnak, és a mezők összhossza ne haladja meg az adatbázislap méretét.
Tervezési segédlet gyanánt csatoltam az utf-8 specifikációját.
Itt lehetett volna statisztikázni, hogy az eddig feltöltött szövegmaxok az átlagos árvíztűrőtükörfúrógépterheltség mellett mit jelentenének az eredetileg is faltól-falig kihasznált lapokban, de erre így már nem volt elszánás, amit meg is értek: ha szocreál felfogás is, a funkciótlan szépség tényleg nem ér annyit.
Volt szerencsém ezer éve nem foglalkozni lapméretekkel (értsd, a tárhely igazodott az üzleti igényekhez, nem fordítva). Speciális helyzet speciális megoldást kíván, pl. varbinary(456)-ban tárolsz pont annyi bájtot, ami belefér, és a perzisztencia rétegben csinálod az UTF-8 konverziót. Sok framework alapból meg tudja neked mondani, hogy adott string UTF-8-ba kódolva hány bájt. Persze az user meg fog lepődni, ha egy ő betűtől 2-t ugrik a hátralevő bájt számláló. Vagy lehet használni ISO-8859-2-t, vagy akár egyedi kódlapot is, ha már annyira rá akarunk menni a bájtokra.
No, ezt az aliasos hülyeséget egy időben kipróbáltuk mi is... :)
És akkor mi van? Elvárhatod, de ha nem megy szívatod magad. Csinálhatok egy ilyen nevű fájlt (Meg\**⁄lepi.?!?), ami tartalmazza a meglepi buli helyét. Szerinted hányan jönnek el azok közül, akik win alatt nyitnák meg? Miért nem lehet?
Hidd el, ha lenne rá valós igény, akkor meglenne az is (nekem vannak is emlékeim ilyenekről egyébként). Megvan pl. hogy a lokalizált excel függvénynevei lokalizáltan vannak? most az más kérdés, hogy van valami, amit darabtelinek hívnak, meg hogy hosszan szívás volt a lokalizáltan készült izék másban való megnyitása, de ezek csak implementációs részletkérdések, volt rá igény, hogy szuahéli barátunk is értse mit csinál. Azt kell észrevenni, hogy az informatika nem egy önmagáért létező valami, hanem a felhasználóik igényét kell megoldja, alapvetően nem az ő dolga diktálni a szabályokat- Az meg egy igen valós igény, hogy az adatokat a saját nyelvemen tudjam kezelni, azzal a géppel, aminek ez a fő funkciója. Értem én, hogy ez technikailag egy csomó zűrt okoz, de azért azt látni kell, hogy azt a zűrt a szakma magának csinálta, mikor az elején hozott egy rossz döntést, aztán sokáig tologatta maga előtt, aztán már durván nyaknál volt a szar, mire hozták a szivattyút. Egyébként mára egy-két még mindig büdös pocsolyát leszámítva kb sikerült is megoldani imho.
Tegyük hozzá hogy manapság már semmi technikai akadálya nincs a főgáz.hu-nak(*). Legalábbis több mint tíz éve lehet regelni, és manapság azért már csak támogatják a böngészők, nem?
*) Ja, és meg is van, igaz átdob a fogaz.hu-ra, ehe.
Nincs semmi bajom azzal, hogy 2015 van. Egyszerűen túl öreg vagyok és még él az emlékeimben, hogy anno 90-es években mennyit szoptam az "istenverte" karakter kódolásokkal. Mondjuk egy 3.12-es novell szerveren amikor ~70 gépről okádták rá fel az adatokat, és minimum a 20 százalékára nem tudtam "ráhatással lenni" a kliens gépeknek... Gizike feltöltötte, Józsika megnyitotta és mentette, majd Gizike nyomtatta volna(!) ha nem lett volna elcseszve az egész egy nyomorult kliens oldali karakter kódolás miatt... e-mail tárgy mezőben pl a mai napig nem használok ékezetet, holott ide is azzal írok... egyszerűen be kell látni, hogy nem csak a Te képességeiden/lehetőségeiden múlnak néha a dolgok és jobb a békesség.
Fejlesztő vagyok és felhasználó. Fejlesztőként törekszem arra, hogy az általam készített alkalmazások teljesen Unicode-kompatibilisek legyenek, felhasználóként pedig elvárom ezt az általam használt rendszerektől.
Tudomásom szerint a jelenleg támogatott Windows, OSX, Linux, BSD változatok mindegyike alkalmas arra, hogy megbírkozzon a Unicode-dal. Vagy legalábbis alkalmassá tehető rá.
Régen én is kiszedtem a szőközöket és az ékezeteket a fájlnevekből, de egy ideje nem érdekel már. Felhasználóként hadd ne az én gondom legyen már ez, macera és információvesztés is (lásd a fenti „fokabel” példát). Írtam eleget VT-100 kompatibilis soros terminálon, nem okoz gondot a repülő ékezetes ékezetes szöveg írása és olvasása, de haladjunk már túl ezen és fogadjuk el, hogy történelem.
XXI. század van, vagy mi a szösz.
----- „Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.” rand() a lelke mindennek! :) Szerinted…
Azért már a win95-ben is működött a Program Files mappa, még a cmd-ben is lehetett vele operálni, sőt tovább megyek a Dos 6.22 is tudta kezelni a spece-t. Elvárható lennne 20-30 év múlva, hogy egy linuxos program is megbírkózzon egy kibaszott space-el, vagy bármilyen unicodos fájlnévvel. Szerintem.
Szerintem az, hogy a kedves felhasznalo nem tudja, hogy hogyan kell azt a szart begepelni, az nem a szoftver hibaja. Korabban mar leirtam a megoldast, masok meg is magyaraztak a mukodest, innentol kezdve nincs semmilyen szoftverhiba a szokoz kezeleseben.
Jelzem ahogy a szoftvertol elvarhato, hogy megbirkozzon vele, a felhasznalotol is elvarhato, hogy tudja mit csinal.
A helyi gépen természetesen a shell értelmezi a speciális karaktereket (szóköz mentén darabol, stb.)
Ami kevésbé triviális, de tudni kell, az az hogy ezt az scp a távoli gépen is megteszi. Csak így válik ugyanis lehetségessé például a * wildcard használata távoli fájlnevekre kiegészítéssel, vagy akár több kézzel felsorolt fájl egy menetben, egyszeri autentikációval átmásolása (scp remote:"egyik másik" .). Ezért van szükség szóközt tartalmazó fájlnév esetén kétszeri escape-elésre, hogy kétszeri kibontás után ottmaradjon a literális, fájlnév részét képző szóköz. Remélem érthető :)
Hozzászólások
scp "user@host:/path/to/remote\ file" /local/path
scp user@host:/path/to/remote\\\ file /local/path
scp 'user@host:/path/to/remote\ file' /local/path
scp 'host:"/tmp/a a/b b"' /tmp/
Off: Én vagyok az egyetlen aki szerint nagyon nem kellene szóköz, spéci karakter stb. a fájl névbe, akár rendszer szinten kellene tiltani? Én ha nagyon elválasztás kell akkor a szokásos oo class nevezék módot használom, szóköz helyett nagybetű. Ha más által hagyott szemét miatt van a probléma akkor bocsi.
Nem rajtam múlik elhiheted. Ha lenne írási jogom módosítanám a fájlnevet és könyvtárnevet.
Ezzel a gondolkodással van a baj.... 2015-ben már alap kéne, hogy legyen, hogy nincsenek ilyen szopások a fájlnevekkel, de miattatok a lusta programozók sosem veszik az energiát, hogy átírják a bugos szar programjaikat.
Ja meg ilyen 卐, meg ☭, esetleg ☮ kell a fájl nevekbe? Mert ezek mind unicode karakterek. Szerintem inkább ne, a szóközzel meg terminálban csak szívás van szóval az végképp kerülendő dolog.
Azt kéne eldönteni, hogy az adott oprendszerben van-e Unicode támogatás.
Ha nincs, akkor oké, ne használjunk Unicode karaktereket. ha viszont van, akkor nincs kifogás, hogy az "á" különb, mint a "☮".
Bizonyos Unicode támogatással rendelkező rendszereken egyébként fel sem merül a kérdés
Gondolom tudod, h ez a foto mekkora csusztatas. Nem arrol van ugyanis szo, h a grafkus feluleten meg lehet-e jeleniteni egy kriksz-krakszokat tartalmazo fajlnevet, hanem hogy egy eredendoen karakteres feluleten hasznalt alkalmazasnal mekkora problemat okoznak ezek a kriksz-krakszok. Es igen, tudom, hogy az a gond, hogy meg mindig meg kell kulonboztetni karakteres es grafikus feluletet.
Szerintem az együttműködési készséggel van a gond. Nem csak "bizonyos unicode-os" rendszeren működik, nem csak grafikus, hanem karakteres felületen is.
De ha pl. scp-vel másolok, akkor a távoli rendszer képességeire is figyelemmel kell lennem, amit vagy ismerek, vagy nem.
Gondolom az nem okoz gondot, hogy az amerikai kollégákkal angolul menjen a kommunikáció, a magyarokkal magyarul, vagy angolul. Amikor meg mindenféle náció előfordul, akkor keressünk valami közös nyelvi minimumot (vagy annak maximumát). Példa az önkorlátozásra, ami átvihető a kommunikáció egyéb területeire is. Mindenki olyan fileneveket akarjon használni, amit az adott ökoszisztéma képes kezelni.
Pl. a Windows is POSIX, persze csak bizonyos feltételekkel. Ahol "P", a portable.
Van olyan eset is, hogy unikódos szöveg kilóg pl. az adatbázis mezőméretből, vagy a filerendszer filenév-hosszból (opsz, a FAT elég korlátos lehet bizonyos unikódos oprendszeren is).
Szóval, a csak mert megtehetem, szerintem még nem elég ok.
Egyébként alább látszik, megtehetném - de fel sem merül (megvallom a jelet egérművelettel másoltam a terminálba).
--
Zahy, veled egyetértek
Igazad van a képet illetően, de cmd-ben és PS-ben is működik, mindenféle escape-elés nélkül.
"ne használjunk Unicode karaktereket" Amit nem lehet begépelni egy ansi US billentyűzeten azt ne használjuk fájlnévben. Szerintem ez egy normális elvárás mert ha véletlen olyanhoz kerül akinek nincs ilyen betűje az anyázni fog.
Szerintem meg az egy teljesen normális elvárás, hogy használhassam már a nyelvemben található betűket.
Sajnos pont a világ egyik legszűkebb betűkészletű nyelve lett az info alapja, ezért azt gondoljuk, hogy normális, hogy csak az megy, de igazából nem, ez sosem volt normális, mindig is szar volt, csak már beleégett az emberek agyába, hogy ez így jó.
Disclamer: én sem használok ilyet filenévben, sőt, a spaceeket is cserélem, mert már megszoktam, de ettől még nem lesz hülye, aki szeretné a gyerekéről készült képet Ödönke.jpg-nek nevezni, nem odonke.jpg-nek
Ennyi erővel elvárhatnánk azt is, hogy dir/ls helyett könyvtár/lista paracsok működjenek. Vannak szabályok, ha tetszik, ha nem. Kb, amikor valami elcseszett backupból tolta vissza a júzer a dolgait w7 alá és egy könyvtárat sem tudott megnyitni. (Már nem emlékszem, azt hiszem ! jelek kerültek bele -de lehet valami más karakter volt- és a win nem volt hajlandó sem megnyitni, sem átnevezni. Live lnux alól kellett egy scripttel helyre rakni.)
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt
Na de miért kéne magunkat hülye szabályok közé szorítani?
Nem kell elcseszett szoftvereket használni. Sambára, Azure-ra, mindenhova tolom az ékezetes és szóközös fájlneveket, mert ez így szép és jó. Nekem. Elvárom, hogy működjenek, és működnek is. Akinek jobban bejön az egyszeru_fajlnev.txt, hajrá, azt sem tiltja senki. Meg lehet próbálni megtiltani orosz, japán, stb. kollégáknak a saját betűik használatát, de attól nem fejlődik a világ sehova.
--
+1
Annyival egészíteném ki, hogy az sem baj, ha egy OS nem támogatja a Unicode-ot, de akkor felejtsük el az "elvileg működik", "nagyjából kompatibilis" és hasonló történeteket. Vagy igen, vagy nem. Pont.
Biztos előjön a barlangból pár régi motoros BOFH, aki még PDP-11-et vagy hasonlót használ, hogy rámmorduljanak, de őket leszámítva szerintem ma már nincs olyan, hogy egy OS vagy library ne támogatna Unicode-ot. Sok-sok év alatt végre eljutott a programozók agyáig. Mondjuk kicsit elkanyarodtunk, mert eredetileg nem ékezetes betűkről, hanem egyszerű szóközökről van szó. Aki shellbe van ragadva, annak sorry, ez egyszerűen egy ilyen világ, tessék escape-elni. Nagy ritkán van úgy, hogy pl. egy regex miatt muszáj bash+grep kombót ragadnom, hát minden alkalommal jól lefáraszt az a sok \. Általában vannak kényelmesebb eszközök. SCP-re biztosan.
--
Szoval ha en talalkozom egy szoftverrel, aminek a legutolso (amugy elvben aktivan tamogatott, fejlesztett) verzioja szarul kezel ekezetes betuket, akkor ki a hulye? En, te, vagy a fejleszto? Es ha nincs helyette jobb, ezert ezt kell hasznalnom akkor megjavitod nekem? Ha raadasul nem is egyetlen ilyen szzoftverrol beszelek, hanem tobbrol, akkor mi van?
(Ami meg a bash+grep es sok \ -t illeti, meg kell tanulni hasznalni, lehet nem kell annyi \ .)
A fejlesztő a hülye, te meg sajnos így jártál. Ha nem kezeli az ékezetet, ne használj ékezetet. Persze menjen a bugreport, aztán vagy jobb lesz, vagy nem. Én is hányok egyes workaround-októl, de ha muszáj... :(
--
No nézzük, mi a helyzet azzal, ha egy OS támogatja a Unicode-ot, de teljesen. Legalábbis itt fentebb az szerepelt, hogy olyan nincs, hogy csak félig. Most megpróbáltam egy többé-kevésbé (nem én felelek érte, ezért nem tudom) up-to-date magyar nyelvű W7Prof-on létrehozni egy halom (pontosan 4 db) fájlt, amiknek nevében van szóköz, kis- és nagybetű és leginkább egy kupac ekezetes karakter is. A fájlok neve szépen sorban:
öt szép szűzlány őrült írót nyúz.txt
ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP.TXT
jött árvíz tűzvész rút gümőkór.TXT
JÖTT ÁRVÍZ TŰZVÉSZ RÚT GÜMŐKÓR.txt
no első probléma, hogy a 4-t már nem tudom létrehozni, mert nyafog az OS, hogy van már ilyen nevű fájl. Szerintem ugyan nem ugyanaz a két név, de ha jól tudom, itt alapból a kis- és a nagybetű ugyanaz. Azaz a 4. fájl neve ... KÓR-2.txt lett a békesség kedvéért. Ezek után Exploder-ben szépen kijelöltem mind a négyet, majd a jobb gomb, Küldés / Tömörített mappa menüponttal csináltam egy zip fájlt belőle. (Csak hogy ne lehessen belekötni abba, hogy winzip, winrar, egyéb nem MS-termék játszott szerepet.) Az így létrejött zip-fájlt átviszem Linux alá, és belenézek - szigorúan parancssorból, mert csak. Három különböző eszközzel is belenézek: "unzip -Zv'" (InfoZip v6.00), "7z l -slt" (p7zip v9.20) valamint "hexdump -C" (util-linux-2.19.1). És mit ad isten azt látom benne, hogy az összes rohadt ékezetes karakter elveszett, és helyettük baromságok látszanak. Kivétel nélkül az összes ékezetes karakter 1-byte-os lett. Valaki elmagyarázná, hogy ez milyen kódolású Unicode? És mit csinál majd ezzel a szarral egy angol vagy épp egy orosz nyelvű Win?
Második lépésként megcsináltam tök ugyanezt Winzip-pel is, pont ugyanaz az eredmény.
(És hab a tortán: korábban egy másik - ha jól emlékszem angol nylvű - Wines gépen is csináltam ilyet, és az eredmény az volt, hogy bizonyos fájlneveknél "fat", más fájlneveknél pedig "ntfs" jelzést mutatott az unzip -Z , és amelyik fat volt, azt nem tudta értelmesen kicsomagolni, amelyik ntfs-tipusú volt, azt meg igen, igaz ott nem is 1-byte-os ékezetes karakterek látszottak a hexdump kimenetében.) Ezek után ugyanezt eljátszom az ellenkező irányban, infozip-pel becsomagolom ezeket a szép kis UTF-8-as fájlnévvel rendelkező fájlokat, átküldöm a Win-re, és nem tud vele mit kezdeni. A 7z pl. lehetőséget biztosít arra, hogy zip kimenet esetén ( -tzip opció ) beállítsam, hogy a fájlneveket UTF-8-ban tárolja le (-mcu=on paraméter) - az más kérdés, hogy UTF16-módot kapcsol be.Eredmény: ugyanúgy nem tud vele mit kezdeni a Windows (illetve hát tudni tud, csak az ékezetes karakterek heélyett lesz valami szar).
Összefoglalom: Elvben mind a két rendszer Unicode-ot használ, ráadásul vagy 10-15 éve ez ZIP fájlban is kéne hogy rendesen menjen, osztán máris előállt egy inkompatibilitási hiba az ékezetes fájlnevekkel.
Mm-hm, hát ne olyan tömörítési szabványt használj, ami hivatalosan nem támogatja a Unicode-ot.
https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
Van olyan tömörítőprogram (elég sok), ami belegányolja a szabványos .zip-be a Unicode-ot, de mint tudjuk, a .csv-t is lehet explode-dal olvasni. _Általában_ működik is. :)
Amit linkeltél, abban egyértelműen szerepel, hogy 2006 óta ott van a szabványban az UTF-8-as fájlnév. Szóval mit akartál mondani?
Hol is? A changelogra gondolsz, miszerint "Added option for Unicode filename storage"?
Görgess le a szóban forgó részhez, ott azért elég sok "may be", "may use", "should", stb. megfogalmazást találhatsz, majd mindezt a jól hangzó "The choice of which storage method to use when writing a ZIP file is left to the implementation." (értsd: csináljatok, amit akartok) mondat zárja.
Vagyis ha mondjuk egy windows-os 7-zippel csinálsz egy unicode-os .zip-et, azt egyáltalán nem biztos, hogy a linuxos unzip parancs mondjuk fájlnév-helyesen fogja tudni kibontani.
Belenéznék abba a ZIP-be, ebben a pillanatban nincs előttem Win7. Ha a Win7 bugos, akkor az elég szomorú, mert úgyse javítják ki, de azért megpróbálnám jelenteni valahol. Illetve azt is megnézném, ha Linuxon csinálsz ilyen ZIP-et, ahhoz mit szól a Win7.
--
Már nincs 10-esnél régebbi gépem, de a 10-es pl. (nagyon helyesen) kiírja, hogy bicsi-bocsi, ezt a karaktert ne akard .zip-ben fájlnévként használni.
Levél ment. Ez utóbbi kérdésre pedig az a válasz, amit le is írtam. Pont ugyanúgy kriksz-kraksz látszik Win alatt is, akár InfoZip-pel, akár p7zip-pel csináltam a fájlt Linux alatt. :-(
Úgy látom, Windows-1250-nel vannak kódolva a fájlnevek. Ez a szar a 8-bites kódlapokkal, kb. lehetetlen őket megkülönböztetni metadata nélkül. Hülye a ZIP, de hülye a Windows is, hogy hagyja. Látom más írta, hogy a Windows 10 hibát ír ki ilyen esetben, az legalább korrekt.
--
A fejlődés égisze alatt úgy döntöttek a fejlesztő kollégákok, hogy arra bátorítják a gyártósort, kezdjék el használni mindazon karaktereket a szabad beviteli mezőkben (van bőven), amelyek nekik szimpatikusak.
Megkérdezhettem volna, hogy mi a francnak, mikor 10 fogorvos közül 9 nem tud különbséget tenni a hosszú és rövid magánhangzók között, de tudok én diszkrét lenni, ha bízom a tanulságos kimenetelben.
Eljött a konkretizálás pillanata: milyen hosszúak legyenek az egyes mezők, hogy biztosan beférjen mindaz, amit beírni akarhatnak, és a mezők összhossza ne haladja meg az adatbázislap méretét.
Tervezési segédlet gyanánt csatoltam az utf-8 specifikációját.
Itt lehetett volna statisztikázni, hogy az eddig feltöltött szövegmaxok az átlagos árvíztűrőtükörfúrógépterheltség mellett mit jelentenének az eredetileg is faltól-falig kihasznált lapokban, de erre így már nem volt elszánás, amit meg is értek: ha szocreál felfogás is, a funkciótlan szépség tényleg nem ér annyit.
Volt szerencsém ezer éve nem foglalkozni lapméretekkel (értsd, a tárhely igazodott az üzleti igényekhez, nem fordítva). Speciális helyzet speciális megoldást kíván, pl. varbinary(456)-ban tárolsz pont annyi bájtot, ami belefér, és a perzisztencia rétegben csinálod az UTF-8 konverziót. Sok framework alapból meg tudja neked mondani, hogy adott string UTF-8-ba kódolva hány bájt. Persze az user meg fog lepődni, ha egy ő betűtől 2-t ugrik a hátralevő bájt számláló. Vagy lehet használni ISO-8859-2-t, vagy akár egyedi kódlapot is, ha már annyira rá akarunk menni a bájtokra.
--
+1
Egyetértek. Szar világ, ha fájlnevekben, dokumentumokban vagy máshol csak ASCII karaktereket lehet használni. Nem a hatvanas években élünk.
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
No, ezt az aliasos hülyeséget egy időben kipróbáltuk mi is... :)
És akkor mi van? Elvárhatod, de ha nem megy szívatod magad. Csinálhatok egy ilyen nevű fájlt (Meg\**⁄lepi.?!?), ami tartalmazza a meglepi buli helyét. Szerinted hányan jönnek el azok közül, akik win alatt nyitnák meg? Miért nem lehet?
A 852-es kídlap telepötúsa sikeresen befejezádétt
Hidd el, ha lenne rá valós igény, akkor meglenne az is (nekem vannak is emlékeim ilyenekről egyébként). Megvan pl. hogy a lokalizált excel függvénynevei lokalizáltan vannak? most az más kérdés, hogy van valami, amit darabtelinek hívnak, meg hogy hosszan szívás volt a lokalizáltan készült izék másban való megnyitása, de ezek csak implementációs részletkérdések, volt rá igény, hogy szuahéli barátunk is értse mit csinál. Azt kell észrevenni, hogy az informatika nem egy önmagáért létező valami, hanem a felhasználóik igényét kell megoldja, alapvetően nem az ő dolga diktálni a szabályokat- Az meg egy igen valós igény, hogy az adatokat a saját nyelvemen tudjam kezelni, azzal a géppel, aminek ez a fő funkciója. Értem én, hogy ez technikailag egy csomó zűrt okoz, de azért azt látni kell, hogy azt a zűrt a szakma magának csinálta, mikor az elején hozott egy rossz döntést, aztán sokáig tologatta maga előtt, aztán már durván nyaknál volt a szar, mire hozták a szivattyút. Egyébként mára egy-két még mindig büdös pocsolyát leszámítva kb sikerült is megoldani imho.
Related: https://modelviewculture.com/pieces/i-can-text-you-a-pile-of-poo-but-i-…
Kicsit hosszú lére van eresztve, de jó :)
Éljen a „fokabel” izé, főkábel… vagy fókabél…?
Szerintem sehol se használjunk más karaktert, csak 1-et és a 0-át. Azt már csak tudja kezelni minden.
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
fogaz.hu . Fájhat.
Tegyük hozzá hogy manapság már semmi technikai akadálya nincs a főgáz.hu-nak(*). Legalábbis több mint tíz éve lehet regelni, és manapság azért már csak támogatják a böngészők, nem?
*) Ja, és meg is van, igaz átdob a fogaz.hu-ra, ehe.
Na a domainek ahol pont hülyeség volt az unicode támogatás
főleg mert:
http://en.wikipedia.org/wiki/IDN_homograph_attack#Homographs_in_interna…
Hali!
Bocs, de nem leszek pozitív a hozzászólásommal, de aki fájl-könyvtár névben szóközt használ, az sikeres ember nem lehet!
Üdv:
Feri
Mm-hm, üdv 2015-ben! :)
Hali!
Nincs semmi bajom azzal, hogy 2015 van. Egyszerűen túl öreg vagyok és még él az emlékeimben, hogy anno 90-es években mennyit szoptam az "istenverte" karakter kódolásokkal. Mondjuk egy 3.12-es novell szerveren amikor ~70 gépről okádták rá fel az adatokat, és minimum a 20 százalékára nem tudtam "ráhatással lenni" a kliens gépeknek... Gizike feltöltötte, Józsika megnyitotta és mentette, majd Gizike nyomtatta volna(!) ha nem lett volna elcseszve az egész egy nyomorult kliens oldali karakter kódolás miatt... e-mail tárgy mezőben pl a mai napig nem használok ékezetet, holott ide is azzal írok... egyszerűen be kell látni, hogy nem csak a Te képességeiden/lehetőségeiden múlnak néha a dolgok és jobb a békesség.
Üdv:
Feri
Nagyjából.
Illetve pont nem azért szeret bele az ember akármelyik shellbe, hogy annak az iszképelési lehetőségeit aknázza ki nyakra-főre a fájlnevek miatt.
Szerencsére már nem a 90-es években élünk. Ha te nem akarsz használni, akkor ne használj. De azért nem hülye az, aki használ.
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
De hogy nem is egy valóban vegyes OS környezetben rendszergazda, az is biztos.
Nem kell keverni a munkát a magánélettel. :)
Fejlesztő vagyok és felhasználó. Fejlesztőként törekszem arra, hogy az általam készített alkalmazások teljesen Unicode-kompatibilisek legyenek, felhasználóként pedig elvárom ezt az általam használt rendszerektől.
Tudomásom szerint a jelenleg támogatott Windows, OSX, Linux, BSD változatok mindegyike alkalmas arra, hogy megbírkozzon a Unicode-dal. Vagy legalábbis alkalmassá tehető rá.
Régen én is kiszedtem a szőközöket és az ékezeteket a fájlnevekből, de egy ideje nem érdekel már. Felhasználóként hadd ne az én gondom legyen már ez, macera és információvesztés is (lásd a fenti „fokabel” példát). Írtam eleget VT-100 kompatibilis soros terminálon, nem okoz gondot a repülő ékezetes ékezetes szöveg írása és olvasása, de haladjunk már túl ezen és fogadjuk el, hogy történelem.
XXI. század van, vagy mi a szösz.
-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…
+1
Azért már a win95-ben is működött a Program Files mappa, még a cmd-ben is lehetett vele operálni, sőt tovább megyek a Dos 6.22 is tudta kezelni a spece-t. Elvárható lennne 20-30 év múlva, hogy egy linuxos program is megbírkózzon egy kibaszott space-el, vagy bármilyen unicodos fájlnévvel. Szerintem.
En imadtam a kevesebb gepelest tamogato fejlesztesuket. Olyan jo volt, hogy gondoltak a lustakra is.
cd progra~1
Szerintem az, hogy a kedves felhasznalo nem tudja, hogy hogyan kell azt a szart begepelni, az nem a szoftver hibaja. Korabban mar leirtam a megoldast, masok meg is magyaraztak a mukodest, innentol kezdve nincs semmilyen szoftverhiba a szokoz kezeleseben.
Jelzem ahogy a szoftvertol elvarhato, hogy megbirkozzon vele, a felhasznalotol is elvarhato, hogy tudja mit csinal.
A helyedben lelkigyakorlatot végeznék, készülvén a junikódos fájlnevekre. ;)
(Monjuk beidézhetted volna, hogy miket próbáltál, és mi volt a hibajelenség...
ezek közül egyik sem jó:
scp 'user@computer:/p a t h / f i l e' .
scp 'user@computer:/p\ a\ t\ h\ /\ f\ i\ l\ e"' .
scp '"user@computer:/p a t h / f i l e"' .
scp "'user@computer:/p a t h / f i l e'" .
?
+1.
Amúgy azért az aposztrófok (nem idézőjelek) között backslash-sel takart szóköznek jóérzésű rendszer esetén működnie kéne.
működik is
Egy másik módszer: a szóköz helyére %20 -at írj.
A helyi gépen természetesen a shell értelmezi a speciális karaktereket (szóköz mentén darabol, stb.)
Ami kevésbé triviális, de tudni kell, az az hogy ezt az scp a távoli gépen is megteszi. Csak így válik ugyanis lehetségessé például a * wildcard használata távoli fájlnevekre kiegészítéssel, vagy akár több kézzel felsorolt fájl egy menetben, egyszeri autentikációval átmásolása (scp remote:"egyik másik" .). Ezért van szükség szóközt tartalmazó fájlnév esetén kétszeri escape-elésre, hogy kétszeri kibontás után ottmaradjon a literális, fájlnév részét képző szóköz. Remélem érthető :)
Köszönet. Végre valaki elmondta az okot is a zajban!
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
touch "Jött árvíz, tűzvész, rút gümőkór"