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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.