Ääkköset konsolissa (Unicode)

[kilotavu]

Onko mahdollista Tigerissä saada ääkköset toimimaan unicodena?

Tällä hetkellä ääkköset toimivat esim. nano-editorissa, mutta komentorivillä eivät. Ei siis ole mahdollista luoda hakemistoa "Työtiedostot", ääkköset eivät edes näy tiedostojen ja hakemistojen nimissä.

Esim: "AppleWorks ka??ytta??ja??n tiedot"

"Latin-1" ei käy, koska joka paikassa on käytössä unicode (mm. ssh yhteyksissä) ja ohjelmoin C:lla unicode ohjelmat.

[jpn]

Oletko koittanut .inputrc -loitsuja:

set meta-flag on
set convert-meta off
set output-meta on
?

Itse käytän tosin ISO Latin 1 encodingia, mutta nopeasti testattuna myös UTF-8 näyttäisi noilla asetuksilla toimivan....

[kilotavu]

Laitoin näin:

set meta-flag on
set convert-meta off
set input-meta on
set output-meta on


Näillä asetuksilla pystyn kirjoittamaan ääkköset komentoriville, mutta hakemistojen nimissä äö merkkien kohdalla on edelleen kysymysmerkit.

Finderissä jopa komentoriviltä luotu "mkdir Ääliö" hakemisto näkyy oikein.
Mutta "ls" komennolla näkyy: A??a??lio??

[jpn]

Näillä asetuksilla pystyn kirjoittamaan ääkköset komentoriville, mutta hakemistojen nimissä äö merkkien kohdalla on edelleen kysymysmerkit.

Finderissä jopa komentoriviltä luotu "mkdir Ääliö" hakemisto näkyy oikein.
Mutta "ls" komennolla näkyy: A??a??lio??

Muutoin sama tilanne paitsi että Pantterissa eivät näytä skandit menevän läpi komentojen argumentteina:

110:~/Documents/Sources/test$ echo hello > ääliö.txt
-bash: ääliö.txt: Invalid argument
110:~/Documents/Sources/test$ echo hello > aalio.txt
110:~/Documents/Sources/test$ mkdir 'ääliö'
mkdir: ääliö: Invalid argument
110:~/Documents/Sources/test$ mkdir aalio

Kun sitten tekaisee vaikka smultronilla ääkkösiä sisältävän tiedoston, näkyvät ne ihan oikein esim catilla. Samoin ne toimivat ok esim grep:ssä. Mikäli tiedoston nimi puolestaan sisältää skandeja on homma taas pielessä:

110:~/Documents/Sources/test$ cat aalio.txt
Olet ääliö pönttö, Åke!
110:~/Documents/Sources/test$ cat ääliö.txt
cat: ääliö.txt: No such file or directory
110:~/Documents/Sources/test$ ls -la
total 24
drwxr-xr-x 6 jpn jpn 204 11 Aug 20:29 .
drwxr-xr-x 3 jpn jpn 102 11 Aug 19:36 ..
drwxr-xr-x 2 jpn jpn 68 11 Aug 20:20 aalio
-rw-r--r-- 1 jpn jpn 24 11 Aug 20:29 aalio.txt
-rw-r--r-- 1 jpn jpn 24 11 Aug 20:29 a??a??lio??.txt
110:~/Documents/Sources/test$ grep 'ä' *.txt
aalio.txt:Olet ääliö pönttö, Åke!
aÌaÌlioÌ.txt:Olet ääliö pönttö, Åke!
110:~/Documents/Sources/test$

Tiikerin ja Pantterin välillä näyttäisi siis olevan erona että Pantterissa skandit eivät mene läpi edes komentojen argumentteina... Hassua ettei aikaisemmin ole tullut huomattua moista....

[nobu178]

Ainakin mulla ääkköset näkyy oikein, kun panen päätteen ikkunan asetuksen Näytössä utf-8-koodauksen päälle. ls-komennon kanssa pitää käyttää w-optiota, jotta ääkköset näkyvät oikein. Jos käytät ls-komentoa putkessa more-komennon edellä, mainittu tapa ei auta, koska more pilaa kaiken.

[jpn]

Ainakin mulla ääkköset näkyy oikein, kun panen päätteen ikkunan asetuksen Näytössä utf-8-koodauksen päälle. ls-komennon kanssa pitää käyttää w-optiota, jotta ääkköset näkyvät oikein. Jos käytät ls-komentoa putkessa more-komennon edellä, mainittu tapa ei auta, koska more pilaa kaiken.

Samaa mieltä taidamme siis olla kaikki ainakin siitä että OS X:n Unicode-supportissa on jotain mätää CLI-softien osalta.... Asian tiimoilta löytyy thread Applen keskusteluryhmistä, jossa annetaan ymmärtää ettei asian korjaaminenkaan olisi ihan triviaalia:
discussions.info.apple.com/webx?128@701.AV53aj3RR08.4@.68b78405

Ohessa lainaus asian tiimoilta:
"These multibyte characters can be represented in more than one way in Unicode. OS X uses canonical ordering, which obviously Linux doesn't. But OS X understands the other ordering, so for example 'ls' will work to display a file or folder name. But it cannot then use that name to look up the file, since it turns the displayed characters back to the canonical ordering, and the bytes do not match.

The Finder and GUI use the old Mac OS concept of a File ID, which has no corresponding feature in Unix, and so has no trouble moving these files and folders about. But for any operation involving a directory lookup, which requires a file name, the match fails.

It isn't clear that you can do anything about it, except avoiding multibyte characters.
"

[nobu178]

Samaa mieltä taidamme siis olla kaikki ainakin siitä että OS X:n Unicode-supportissa on jotain mätää CLI-softien osalta.... Asian tiimoilta löytyy thread Applen keskusteluryhmistä, jossa annetaan ymmärtää ettei asian korjaaminenkaan olisi ihan triviaalia

CLI-ohjelmien unicode-tuen parantaminen on tosiaan toivottavaa. En tiedä kuitenkaan (en ole muita käyttiksiä paljon käyttänytkään), onko muissa käyttiksissä asiat paremmin.

[jpn]

CLI-ohjelmien unicode-tuen parantaminen on tosiaan toivottavaa. En tiedä kuitenkaan (en ole muita käyttiksiä paljon käyttänytkään), onko muissa käyttiksissä asiat paremmin.

...merkistöongelmien selvittely ei koskaan ole mitään kovin hauskaa homma, koska ne voivat hajota niin kovin monessa eri paikassa. Selvittely ottaa usein paljon aikaa.

Hassuinta tämän threadin kannalta on se, että tuttu demosi FreeBSD:tä jossa homma toimi kuin junanvessa. Hassuksi asian tekee se, että OSX:llä on kuitenkin frisbeen kanssa yhteinen tausta, joten olisi luullut että tälläiset perusasiat juontavat juurensa tuolta yhteisistä historian aamuhämäristä kun käyttiksen runkoa on pystytetty...

[nobu178]

...merkistöongelmien selvittely ei koskaan ole mitään kovin hauskaa homma, koska ne voivat hajota niin kovin monessa eri paikassa. Selvittely ottaa usein paljon aikaa.

Tästä varmaan ollaan kaikki samaa mieltä.

Hassuinta tämän threadin kannalta on se, että tuttu demosi FreeBSD:tä jossa homma toimi kuin junanvessa. Hassuksi asian tekee se, että OSX:llä on kuitenkin frisbeen kanssa yhteinen tausta, joten olisi luullut että tälläiset perusasiat juontavat juurensa tuolta yhteisistä historian aamuhämäristä kun käyttiksen runkoa on pystytetty...

Kiinnostavaa. Tunnustan, etten tiedä FreeBSD:stä juuri mitään. Tarkoitatko, että FreeBSD:ssä unicode toimii ongelmitta, vai sitä, että siinä ääkköset toimii ongelmitta? Jos vastaus on edellinen, Applella taitaa riittää hommia merkistöongelmien kanssa.

[jpek]

En tiedä kuitenkaan (en ole muita käyttiksiä paljon käyttänytkään), onko muissa käyttiksissä asiat paremmin.

Skandimerkistöt on toimineet siististi Latin1:llä kaikissa unixeissa sitten 80-luvun ja Windowsissa kans, mukaanlukien toiminta american 7bit asciin kanssa.

Mutta tietysti eri asia, jos tarvii kiinalaisia merkkejä.

Applen ongelma taitaa olla siinä, ettei konsolikäyttöliittymää ikäänkuin lasketa ollenkaan käyttöliittymäksi. Kyllä minusta perusvaatimus olisi, että kun ostaa koneen kaupasta, avaa terminaalin ja kirjoittaa komennon "ls", tiedostonimet on luettavissa.

Sitäpaitsi ISO-pikku-kirjainkysymys on hoidettu aika hillittömästi: tiedostonimet on kirjoitettaessa case sensitiivisiä, luettaessa ei. Siis näyttää siltä, että casella olisi väliä, mutta "Koe" ja "koe" onkin sama tiedosto.

[Jamac]

jpek, [ quote] ... [ /quote] tageja täytyy olla parillinen määrä (siis yhtä monta kumpaakin), muuten saitin leiska leviää. Korjasin sulta tuon yhden sulkevan tagin puuttumisen.

[nobu178]

Hei jpek! Taas ollaan ääkkösten kimpussa! Näemmä me rakastetaan ääkkösongelmia!

Skandimerkistöt on toimineet siististi Latin1:llä kaikissa unixeissa sitten 80-luvun ja Windowsissa kans, mukaanlukien toiminta american 7bit asciin kanssa.

Mutta tietysti eri asia, jos tarvii kiinalaisia merkkejä.

Juuri tota tarkoitin. Vaikka en ole paljon muita käyttiksiä käyttänyt, olen sen verran huomannut, että työpaikkani Sunin Unix-palvelimessa ääkköset toimivat ongelmitta. Siinä ei kuitenkaan unicode toimi(nut ainakaan aiemmin. En ole kokeillut pitkään). Tiikerissä unicode toimii aika hyvin, kun panee utf8-koodauksen päälle. Kiinalaiset, japanilaiset yms. merkit näkyvät ääkkösten rinnalla ihan oikein. Se on aikamoinen näky! Pitää vaan käyttää sopivia komentojen optioita ja tehdä asetuksiin muutoksia. En väitä, että kaikki ongelmat ratkeavat sillä tavalla, mutta ainakin siedettävällä tavalla unicode toimii. Olen nähnyt aiemmin yhtä toimivan (tai toimimattoman) unicoderatkaisun vain BeOSista.

Kyllä minusta perusvaatimus olisi, että kun ostaa koneen kaupasta, avaa terminaalin ja kirjoittaa komennon "ls", tiedostonimet on luettavissa.

Niin olisi. Toivotaan vaan, että ongelmat on hoidettu Leopardissa. Käyttämällä Finderissä (tai pikemmin tiedostojen ja hakemistojen nimissä) unicodea minusta Apple teki hyvin kauaskantoisen ratkaisun, vaikkakaan se ei nyt ehkä parhaalla mahdollisella tavalla toimi.

Sitäpaitsi ISO-pikku-kirjainkysymys on hoidettu aika hillittömästi: tiedostonimet on kirjoitettaessa case sensitiivisiä, luettaessa ei. Siis näyttää siltä, että casella olisi väliä, mutta "Koe" ja "koe" onkin sama tiedosto.

Tämä on varmaan häiritsevää, jos on tottunut muihin *nixeihin. Luulen, että niin on tehty tarkoituksella, kun vanhemmassa käyttiksessä (esim. OS 9:ssä) eroja ei tehty isojen ja pienten kirjainten välillä.

Lisään pikkasen. Sanon etukäteen, etten ole itse kokeillut seuraavaa käynnistyslevyllä. Levytyökalulla voi valita alustusmuodoksi formaatin "(Kirjaava |) suojattu". Muistaakseni tällä formaatilla levyn alustamalla voi erottaa isot ja pienet kirjaimet toisistaan kansioiden ja tiedostojen nimissä. Pantterissa tämän tekemiseksi piti ensin "muuntaa" käyttis serveriksi. Tiikerissä "suojattu" -formaatin voi valita ilman temppuja. Voit kokeilla tätä formaattia, jos kirjainten kokojen erottamattomuus vaivaa.

Lisäys2. Ainakaan Pismossa kirjaava-suojattu-formaatti ei kelvannut käynnistystaltion formaatiksi. Ulkoisen kovon formaattiksi se kelpasi ja käyttis tunnisti isot ja pienet kirjaimet erikseen.