Hi Andy,
I may be alone in this, but I'm a more traditional Unix user.
I think I'm in that set too; regular ed and dc user. :-)
If there is something that doesn't work the way I want, I use a
filter...
$ ls ~/bin | wc -l
295
For this particular problem, would iconv(1) work to convert texts from
one encoding to the other?
Yep, it's the same code, packaged differently, and with a bit more
overhead.
Maybe iconv support could be integrated as a command to run for
support rather than a library linkage?
I think most of us would prefer the library, and code to use it is
already written. :-) Plus, with the world that matters, e.g. not Java,
moving evermore to UTF-8, a lot of the time it isn't needed.
As a Unix fan, would it help you consider switching from C to UTF-8 if
you knew its history, if you don't already. Ken Thompson and Rob Pike
cooked it up in a cafe close to Murray Hill to fix the problems with the
original UTF.
https://plus.google.com/u/0/+RobPikeTheHuman/posts/Rz1udTvtiMg
Plan 9 used it throughout. I've found switching to it is better for
most things. For those where it's not, I've
$ cat ~/bin/C
#! /bin/sh
# LC_ALL has precedence over LANG according to POSIX[1], but we may as
# well stamp out any traces by setting LANG too.
# 1. The Open Group Base Specifications, Ch. 8 Environment Variables.
LC_ALL=C LANG=C exec "$@"
$
so I can `C grep ...' when needed.
Cheers, Ralph.
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers