Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
problem with 8-bit characters
- X-seq: zsh-workers 14023
- From: paul@xxxxxxxxxxx (Paul Falstad)
- To: zsh-workers@xxxxxxxxxx
- Subject: problem with 8-bit characters
- Date: Thu, 19 Apr 2001 01:02:50 -0700
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- Reply-to: Paul Falstad <paul@xxxxxxxxxxx>
Hi,
I would like to mention a bug that's been there since the beginning
(and has come back to haunt me). If you have a filename which
includes one of the character tokens (like 0x84) then zsh will
of course have lots of problems dealing with that file.
example:
zsh% ls Albumbl?tter' Op. 124.wav'
ls: Albumbl
tter Op. 124.wavv: No such file or directory
^^^^
bash$ ls -l Albumbl?tter' Op. 124.wav'
-rwxrwxr-x 1 pf users 11277884 Apr 19 00:30 Albumbl?tter Op. 124.wav
bash$ echo Albumbl?tter' Op. 124.wav' | od -c
0000000 A l b u m b l 204 t t e r O p .
0000020 1 2 4 . w a v \n
0000031
This particular file is on an smbfs filesystem on linux. The file is
called "Albumblätter Op. 124.wav" on the PC side but is showing up
with a \204 (0x84) instead of an "ä" on the linux side because of a bug in
smbfs. Fortunately there appears to be a fix for the smbfs problem
so I'm going to try that out. However zsh isn't handling this very well.
I expected that characters like 0x84 would never show up anywhere but
apparently that isn't the case. This is probably a real low priority
bug and it seems very hard to fix, but I just wanted to point out that
it is a real problem in some cases in case anyone comes up with any
clever ideas for how to fix this.
Thanks much.
--
Paul Falstad, paul@xxxxxxxxxxx, 805-966-4935, http://www.falstad.com/
work: paul.falstad@xxxxxxxxxxxx, 805-957-1790, http://www.openwave.com/
Messages sorted by:
Reverse Date,
Date,
Thread,
Author