2006/1/27, Isak Savo <[EMAIL PROTECTED]>:
> 2006/1/27, Axel Liljencrantz <[EMAIL PROTECTED]>:
> > 2006/1/26, Isak Savo <[EMAIL PROTECTED]>:
> > > Something like this:
> > > $ ls<TAB>
> > > ls (List contents of directory)
> > > lsfoo (<<No description found>>)
> > > lspci (List all PCI devices)
> > > ...
> > >
> > > Perhaps the "No description found" part could be error colored or
> > > something. It could also be completely omitted, leaving just an empty
> > > parenthesis.
> >
> > In this particular case, that can be done. I was thinking about the
> > general case. For example, on my machine the 'locale -a' command seems
> > to outputs locale names in the native charset of the locale, which
> > will sometimes result in invalid strings. What should a command like:
> >
> > for i in (locales -a)
> > ...
> > end
> >
> > do?
> >
> > Should it skip the the broken strings. Try to guess what they are?
> > Skip the broken characters? Maybe the whole command should fail?
>
> Why would you want to skip them? Imagine the following
> for i in (locales -a)
> process_string($i);
> end
>
> process_string() might handle, or even depend on, $i being in weird
> charsets. I'm not familiar with the fish internals, but the logical
> thing would be to not care unless the string is being printed to the
> user.
Welll, the problem here is that fish internally uses wide character
strings, i.e. a string where each character is 4 bytes long. An
invalidly encoded character string has no wide representation, so it's
impossible to perform the conversion. Other shells don't have this
problem since they all use narrow strings.
It's much easier to write string handling code that can assume each
character is the same size, but there is a price to pay.
>
> Isak
>
> PS. I have no idea how other shells handle this. I'm basically arguing
> theoretical points here :-)
>
--
Axel
--
Axel
N�HY隊X���'���u���[�������
ަ�k��!�� �W�~�鮆�zk��C� [EMAIL PROTECTED],���� a{�
��,�H��4�m�����Z�� jY�w��ǥrg
