ékezetes karakterek

Szkriptek: Python, Perl, Bash, ...

Sziasztok!

Gondolom amatőr a kérdés, de még sosem találkoztam a problémával, mert ilyet sosem kellett csinálnom.
Ki kellene adjak egy egyszerű 'cd /x/y/FOTÓ' parancsot bash scriptből, de sehogy sem akarja megenni. A locale UTF-8, a fájlrendszerben jól is látszanak a karakterek, de bash folyamatosan azt dobja h. a könyvtár nem létezik, nyilvánvalóan nem értelmezi a nagy, hosszú Ó-t. Az átnevezés sajnos nem megoldás, valahogyan ezt a könyvtárat kellene használnom.
Kérdés tehát, hogy hogyan is írjuk az Ó-t 'bashul'? :)

Köszi,
Zoli

  • 2373 megtekintés

Nem azt kell felírni! A helyes szöveg: "Nem használok ékezetes karaktert és szóközt a file nevekben, amíg be nem állítom a rendszert rendesen, és meg nem tanulom a szóköz parancssori bevitelét."

-----
Dropbox tárhely igénylése: https://www.getdropbox.com/referrals/NTI2MzM2MjA5

Köszi, akkor ezt lécci küldd el a főnökömnek.
Szerinted ha csak rajtam múlna, akkor nem lenne ékezet mentes a k. könyvtár? A problémát szeretném megoldani, nem trollkodást és megmondást hallgatni. Én sem szoktam megmondani senkinek h. hogy kéne GPFS-t tervezni/managelni, mikor itt bénáznak a drbd+ocfs párossal pl.
Ha nem tudsz normálisan hozzászólni, akkor tudok javasolni másik portált, ott lehet ezt csinálni.
Más: tudom hogyan kell beállítani a rendszert, azt is h. hogyan kell beírni a space-t parancssorban, ezért volt a kérdés a hosszú nagy 'ó'. Nagyon örülök neki, hogy Te nem találkozol ilyen problémával, de sajnos én ilyen felhasználókkal vagyok körülvéve.

Üdv,
Zoli

a./ Sulc hozzászólására reagáltam
b./ Vagyis azt finomítottam, amit ő írt. Ő ugyanis teljesen elveti az ékezetes betűk és a szóköz használatát a fájlnevekben. (Ráadásul a kettő közzé "vagy"-ot rakott, és így azt jelenti, hogy vagy az egyiket, vagy a másikat ne használd. Ezt javítottam "és"-re.) Én ehhez képest megengedő magatartást képviselek, azaz ha rendesen be van állítva a rendszer, akkor lehet ezeket is használni.
c./ Helyes beállítás mellett nyugodtan használhatunk ékezetes betűket is a fájlnevekben. Csak a teszt kedvéért készítettem a Nautilusban egy FOTÓ nevű könyvtárat. Nyitottam egy Gnome terminált: az ls parancs helyesen listázta a FOTÓ könyvtárat is. Átléptem a konzolra, bejelentkeztem, és az ls parancs itt is helyesen listázta a FOTÓ könyvtárat. Na, valahol itt kezdődik a helyes beállítás. (Az érdem nem az enyém, a telepítés után is így működött a rendszer.)
d./ GPFS-t nem terveztem, menedzseltem, a drbd+ocfs párost sem ismerem, ezért aztán nem is írtam róluk :-)

-----
Dropbox tárhely igénylése: https://www.getdropbox.com/referrals/NTI2MzM2MjA5

Ezt én értem is. Csak a gond az h. mondjuk az itthoni gépemen ez működik is, amint már lentebb is leírtam ezek kb. 10x migrált adatok, még van ami lehet ISO kódolású, van ami UTF8, kissé kavalkádos a rendszer ebből a szempontból.
Ha szakmailag közelíteném meg, akkor azt mondanám h. leáll, minden konvertál UTF-8-ra, stb.
Gondolom azt Te is érted, hogy ezt nem minden esetben lehet megtenni. Ilyenkor jön a workaround, barkácsolás, mert "meg kell oldani", ezért fordultam hozzátok, hátha van valakinek frappáns ötlete. Ebben az esetben pl. a symlink ideiglenes megoldásnak teljesen jó volt. Amikor a cégnél sambázni kezdtünk és linux szerverezni, akkor volt a nagy UTF-8 átállás mindenhol, ezért lehetnek ilyen jellegű problémák sajnos, de sem időm, sem energiám nicns most ezzel foglalkozni. Majd egy szép nyugis napon (2-3 év múlva talán lesz is ilyen :))
Egyébként a felhasználók táblájára valóban fel lehetne írni h. no ékezet, no szóköz, támogatom.

Szertinem ez nálunk ilyen kompatibilitási nyavaja. Debian is elkezdte nyomni UTF-8 -at, gondolom ha pl. létrehozom én parancssorból a könyvtárat akkor az úgy jó is lesz, de ezek ezer éves migrált adatok + van még 1 samba is a dologban h. még advancedebb legyen :)
Az ideális megoldás a minden konvertálása lenne + smb.conf módosítás h. akkor mostantól minden UTF-8 legyen unix oldalon, csak ezt ilyen 7-800Gb-nál megcsinálni, pláne h. sosem lehet leállítani a gépet szinte... Marad a hexdump és barátai...
Igazából csak azért voltam kíváncsi mások véleményére mert hátha, azért jó szakemberben nincs hiány.

Próbáld, úgy hogy
ls FOT
Mit dob erre a bash? Elvileg ki kellene egészítenie, és akkor látható milyen escape szekvenciát alkalmaz.
Bocs:
A végéről lemeradt a TABULÁTOR billentyű szokásos jele - I love html :(

* Én egy indián vagyok. Minden indián hazudik.

Mit nem lehet beírni, más rendszereken? A FOT\303 -at? Szerintem a tabulátoros kiegészítés már a window -son is működik csak ott gondolom nem FOT\303 lesz. A bash -nak vagy a windows shell -nek beírni egy harmadik módon kellhet/lehet de ebből el lehet indulni.

* Én egy indián vagyok. Minden indián hazudik.

"szerintem" - lehet hogy ez a kulcsszó... esetleg mondjuk biztosra menni, na, milyen ötlet? :-) Hexeditor például... Aztán a shellbe kézzel bepötyögött FOTÓ szót, vagy a könyvtár listázását is át lehet küldeni hexdumpon és összehasonlítani.

szerk.: bocsi, a kettővel feljebbire válaszoltam

( tomaza | 2009. 11. 04., sze – 19:39 )

nem értem mit kell ezen ennyit problémázni (ugyan nem tudom hol a gond meg meg tudnám-e oldani, talán problem|hexdump-al kezdeném; pl gyanús hogy nem utf8 hanem utf16, azaz fix 2 byteos kódolás került be valahogy)
linux meg ilyen szkriptnyelvek, mannák alatt annyi lehetősége van az embernek, próbáljatok meg windows alatt a \r végű fájlokkal kezdeni valamit :D

( gd | 2009. 11. 05., cs – 01:21 )

A fájlrendszeren ezek a fájlok ISO-8859-2 kódolással vannak. (Ha ? látszik bennük, az csak ilyen irányú probléma tünete lehet.) Próbáld meg a szkriptet is erre konvertálni.

( tomi66 | 2009. 11. 12., cs – 12:44 )

Pedig ez a megoldás, mármint a konvertálás, a többi csak okos szarkavarás. Bizony mondom néked, konvertálj, mert az jó ! ...és ehhez le sem kell állítanod a gépet, ez eléggé gyengusz kifogás...

"ls | hexdump"
tipikusan az "FF FE xx 00 xx 00 ..." kimenetbeli 00-k szoktak szóközként megjelenni, azaz a fájlrendszeren kívülről került a fájlrendszerbe, mintha a főnök gagyi scp kliense rosszul kódolta volna a fájlneveket, azaz nem gyógyszeres, hanem sebészeti beavatkozás szükséges valakinek a csuklóját/alkarját/stb-t illetően, a lényeg hogy még fizetni tudjon :)

eredeti kérdésre:
ha máshogy nem, "ls >a"
aztán "cd $(cat a)" biztos működik, vagy a=$(ls)
de a bash escapelésnek is működni kell valahogy, azt úgy látszik senki nem vágja ebben a node-ban :)

a tomoritett fajlok nevet a jobb tomoritok kepesek konvertalni, a pendrive-ken altalaban vfat van, aminek meg lehet mondani, hogy milyen encodingal mountolodjon (ekkor a kernel automatan konvertalja a fajlneveket), kulso hdd-t meg altalaba nem szokas megosztani masokkal.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.