DIRECTORY collects atoms, can't return files in deep subdirectories

[rmkaplan]

The \PNAMELIMIT is 255, so any enumeration in a deep subdirectory is likely to cause an error.

Either DIRECTORY should always return strings (incompatible with any code that is testing for EQ), or at least return strings for filenames that are too long.

[rmkaplan]

Decision today was for DIRECTORY always to return filenames as strings

[masinter]

i thought we should consider moving all uses to use common lisp CL:DIRECTORY which returns a list of PATHNAME.

[nbriggs]

That would start down the path of having to make everything in Interlisp accept pathname objects and/or manipulate the results with CL: functions. That's a bigger can of worms under higher pressure...

[rmkaplan]

For example, what about INFILEP, FINDFILE…?

If the print-name of a path looked like a current filename string, at least some existing string-matching code might work.

It might be a good aspirational end-state, but a lot of work to get there.

On Mar 28, 2022, at 7:26 PM, Nick Briggs @.***> wrote:

That would start down the path of having to make everything in Interlisp accept pathname objects and/or manipulate the results with CL: functions. That's a bigger can of worms under higher pressure...

— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/754#issuecomment-1081333809, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJKX3KRAVNAWD3AN46DVCJS5PANCNFSM5R3SB3AQ. You are receiving this because you modified the open/close state.

[rmkaplan]

Re-opened this, to add a separate observation/issue wrt the return value of DIRECTORY

Currently, DIR * COLLECT DATE prints all the files and dates, but then returns the list of (string) filenames. There doesn't seem to be a way for a caller to just collect a structure of (filename . properties), with or without printing.

Should COLLECT with a request for attributes also return values for the requested properties? If not, then the caller has to use a more internal (but still generic) interface (\GENERATEFILES, \GENERATENEXTFILE, \GENERATEFILEINFO)

[masinter]

I can't tell if this is a bug or a feature request. If a feature request, I'd want to know what Common Lisp does.

[rmkaplan]

Looking this over, I think this wraps up a few separate issues.

1. if you have a long directory string and you are collecting values, you might run over the atom pname limit of 256, and you get an error. So maybe the returned filenames should generally be strings. (That would be safer, I think, then CL paths, because at least normal interlisp character operations work on both atoms and strings--except for EQ tests.)

2. The default behavior is PRINT, and it does that default even if what you have specified is COLLECT. So in the collection case the list of files is printed and at the end of that it returns the list of things that it just showed you. I think if COLLECT is specified it show no longer also default to PRINT. If you want both printing and collection, you should specify both: PRINT COLLECT.

3. If you specify COLLECT and also some additional attributes that you want beyond just the name, it (mistakenly, see #2) does the PRINT with the attributes, but then the return value is just the list of names, ignoring the fact that you had called for the attributes. Instead, COLLECT with attributes should return a list for each file containing the name and the requested attributes.

[rmkaplan]

(Note: I typed in hash-2 to refer to an earlier point, git mapped that into a totally unrelated issue. Forget that

[masinter]

is it possible to not "fix" this problem if we adopt pseudohosts which will shorten path names?

[nbriggs]

I think pseudohosts would reduce the frequency of trouble, but it still seems as though strings would be better than atoms for the list of returned file names.

[masinter]

it looks to me like (DRECTORY) returns strings, and everyone is happy. So I'll close this.