○[NetBSD] \(←なぜか円記号に見える)

Citrus iconvのことかー >> 地雷実装

$ printf \\x5c | iconv -f shift_jis -t euc-jp
iconv: warning: invalid characters: 1
〓$
$ printf \\x5c | iconv -f euc-jp -t shift_jis
iconv: iconv(): Illegal byte sequence

Shift_JIS(JISX0208の附属書1)はJISX0201-Romanなのよね。

一方eucJP( UI-OSF 日本語環境実装規約の付属書C)はANS X3.4(ASCII)。

これらを忠実に実装してるCitrusのバヤイ
0x5cが代替文字に置換されるのは「仕様です」なのよね *1。

かたやLegacy Encoding Projectのpatch適用したGNU libiconvやperl iconvの場合

$ printf \\x5c | /usr/pkg/bin/iconv -f shift_jis -t euc-jp | od -x
0000000     005c
0000001
$ printf \\x5c | /usr/pkg/bin/iconv -f shift_jis -t utf-8 | od -x
0000000     005c
0000001

ちゅー変換するのよね、すなわちJISX0208は大間違いで
JISX0201-RomanでなくASCIIだ、ということだと思われ。
nkfやqkcなんかのlegacy converterと同じ動作をするようになってる訳やね。
＃まあJISX0208で規格化されたのは後からだしなぁ。

ちなみにTOG/JVCでは代替文字に置換されると困る人は(eucJP-MSと同様に)
明示的にeucJP-0201を指定しろ(そいやCitrusに実装なかったな)ということだった記憶がある。

そいとMS932だと問題が起きないのは、Unicode.orgの 変換表では
0x5CはREVERSE SOLIDUS、つまりISO646-USだから。
最新の変換表だと REVERSE SOLIDUS (YEN SIGN) 。
TOG/JVCによると

Windows 3.1/NT/95 では, この問題に対して 
　・　0x5C は UCS の 0x005C (REVERSE SOLIDUS: 逆斜線) に変換する. 
　・　にもかかわらず, 0x5C のグリフは「￥」とする. 
という解決を取っている.

解決というか開き直りｗｗｗｗだがそれが正しい。

あとこの問題については、ISO-2022-JPのバヤイ
ASCIIもJISX0201-Romanもどっちもイケるくちなので

$ printf \\x5c | iconv -f shift_jis -t iso-2022-jp
ESC(J\ESC(B

となるので変換可能だし無問題

...いやサニタ(略) で (略) な気もするけど、そんなヘボい(略) と思いたい。

○[NetBSD] pkg_view(1)

obacheさんより、そっかpkg_view(1)って同一パッケージの別バージョンを共存する仕組みでしたっけ。
あとは同一パッケージの同一バージョンを別ABIで共存できるようにすればいいわけだ。