Re: encapsulating directory operations

On 2025-05-21, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2025-05-20, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

"Paul Edwards" <mutazilah@gmail.com> writes:

[...]

As far as I know, there was never any LOGICAL barrier
to including basic directory manipulation in C90.

>
None that I can think of.

>
There was a significant barrier. The ANSI group which standardized
C was mainly looking at surveying and codifying existing practice.

>
Agreed.  I consider that a practical barrier, not a "LOGICAL" one.
>
The ANSI C committee *could* have added directory operations to the C
standard library.  (I'm not suggesting that they should have.)
>
[...]
>

Sure, it would be theoretically possible to treat directories as files,
and to make reading from a FILE* resulting from calling fopen() with a
directory name give you access to the directory entries.

>
I implemented something like this. It is fine; I don't regret it.
>
i1> (open-directory ".")
#<dir-stream b7b90820>
2> (get-line *1)
"htrailer.txr"
3> (get-line *1)
"y.output.bison"
4> (get-line *1)
"jmp.S"
5> (open-file "/etc/hosts")
#<file-stream /etc/hosts b7b7a8b0>
6> (get-line *5)
"127.0.0.1\tlocalhost"
7> (get-line *5)
"127.0.1.1\tsun-go"

>
It looks like it treats a directory as a file containing a
sequence of *lines*, each of which is a file name.

I don't want to descend much farther into this culvert, but appearances
are deceiving. The directory stream implementation takes liberty with
interpreting thet get-line operation as if it were "get textual record"
(where regular text streams define records as newline-terminated
lines, but other streams not necessarily so).

If a filename contains newline characters, they will be correctly
returned as constituents of the string.

1> (touch "foo\nbar")
t
2> (sh "ls foo*bar")
'foo'$'\n''bar'
0
3> (find-if (op fnmatch "foo*bar") (get-lines (open-directory ".")))
"foo\nbar"

get-line is a principal stream operation, which is not understood as
simply being a loop over get-char that reads until newline or EOF.
A directory stream doesn't even support get-char:

4> (get-char (open-directory "."))
** get-char: not supported by stream #<dir-stream b7b0dd80>
** during evaluation at expr-4:1 of form (get-char (open-directory "."))

So thereby we duck out of answering the question of what character to
return for record separator. If open-directory did provide get-char, I
would lean toward making it produce the null character after each
name.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca