PACKFILENAME.STRING does not quote funky characters

[rmkaplan]

A corner case:

UNPACKFILENAME.STRING and PACKFILENAME.STRING are not proper inverses.

(UNPACKFILENAME.STRING (PACKFILENAME.STRING 'NAME "abc.x")) returns (NAME "abc" EXTENSION "x")

But the caller put the .x string in the NAME field, that fact got lost.

As it is now, the caller of PACKFILENAME.STRING has to know that "." needs to be quoted as "abc'.x" to get the expected round trip.

The better behavior would be for PACKFILENAME.STRING to inspect its arguments and insert quotes as needed.

(Also, what about "\" as a quoting character?)

[masinter]

Introducing quoting into filename unpacking and packing brings in it's own raft of problems, especially in code that uses CONCAT and other string operations.

abc.x as file NAME happens if you unpack 'abc.x.y`

[rmkaplan]

There aren’t any quotes (‘) in these examples, that has to do with the round-tripping of packing and unpacking. But in terms of (unquoted) behavior, the current behavior is that A.B.C.D.1 says that 1 is the version, even though preceded by . and not ; or !. If * replaces 1, it also comes out as a version. But it’s an extension if E replaces 1. But if 1 is followed by a dot, then 1 becomes the extension and the version is “" So is the rule that the last dot is treated as a version-marker if followed by either a number or star ? Is this prescriptive, or an accident of the current implementation?

…

On Apr 25, 2022, at 4:23 PM, Larry Masinter ***@***.***> wrote: Introducing quoting into filename unpacking and packing brings in it's own raft of problems, especially in code that uses CONCAT and other string operations. abc.x as file NAME happens if you unpack 'abc.x.y` <https://user-images.githubusercontent.com/1116587/165189732-9e971b16-11ac-4e64-af3f-2d612895953b.png> — Reply to this email directly, view it on GitHub <#759 (comment)>, or unsubscribe </~https://github.com/notifications/unsubscribe-auth/AQSTUJNVBY3A2X3XZPYMARDVG4SNRANCNFSM5UGZ3HWQ>. You are receiving this because you authored the thread.

[masinter]

/~https://github.com/Interlisp/history/tree/master/1980s/1983-sumex-lisp
looks like the dot delimiter between name and version --- not sure where that came from -- PDP-10?

[rmkaplan]

If you are just point to this list of files, it looks like the version is in the tilde format, and the .1 is an extension. But maybe in the original, the .n’s were all version numbers: I see opcoes..2 = null extension, version 2 ?

…

On Apr 27, 2022, at 12:27 PM, Larry Masinter ***@***.***> wrote: /~https://github.com/Interlisp/history/tree/master/1980s/1983-sumex-lisp </~https://github.com/Interlisp/history/tree/master/1980s/1983-sumex-lisp> looks like the dot delimiter between name and version --- not sure where that came from -- PDP-10? — Reply to this email directly, view it on GitHub <#759 (comment)>, or unsubscribe </~https://github.com/notifications/unsubscribe-auth/AQSTUJMGXVWPOLG6P6GIVPTVHGIKJANCNFSM5UGZ3HWQ>. You are receiving this because you authored the thread.

[masinter]

the subject is about packfilename.string, but there's a bigger issue about files and filenames that I'd like to have some discussions about... using Common Lisp pathnames, and make the internal format of a pathname parsed into parts (without the {}<>>>>. containing punctuation. And handling unicode UTF-8 filenames. And directories returning pathnames? Turn this into a Discussion.

[nbriggs]

Changing from strings to pathnames as the interface for all FDEV methods that currently deal in file names is a fairly complicated task, which ripples through a lot of code. I suspect, for example, that it would mean updating a bunch of the XNS (and PUP/LEAF) filing code. Changes to the filename handling for {dsk} and {unix} devices also need to be coordinated with changes in the maiko code, which has to parse, and generate file names for the enumerators.