On Mon, Aug 24, 2026 at 04:22:53PM +0200, Martin Husemann wrote:
> On Mon, Aug 24, 2026 at 02:05:39PM +0000, Taylor R Campbell wrote:
> > - the input data that we have no control over.
>
> The question is: how should the tool behave in this situation and what
> consequences does it have?
>
> - extract filenames as octects verbatim, leading to unrepresantable
> filenames that "ls" will not properly show and that are hard to
> rename with the shell.
>
> - extract (like before the change) the result of the iconv() call, i.e.
> in this case "???.py", which gives high possibilities of unexpected
> name clashes in the output if multiple files are affected.
>
> - fail to extract (like after the change and like all other tools I know
> in the same situation), which makes things complicated for pkgsrc
> but most obvious for the local user.
>
4) Use a FAT like method (if requested): extract the files with an
ASCII like representation and give two files: one "path.origin" with the
verbatim paths, one per line, and the other: "path.xfm", with
corresponding line indices, the transformed version (not one file
because there will be the problem to find a separator guaranteed
not to appear trailing the original path and that the text tools
could master---this excludes the nul character).
--
Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
