file-glob always returns an empty list

[pyjamaslug]

Hi, I just set out to write a tinyscheme script that retrieves the list of files from a folder using file-glob and although it looks trivial I can't get it to work. 

the line in question is:

(let* (filepaths (cadr (file-glob (string-append input-path "*.png") 0))))

which always returns empty whether I place it in a script or type a version into the console. Gimp just tells me that parameter 1 to cdr needs to be a pair.
Yes, I have verified that the folder pointed to by input-path exists and that there is at least one png file in it.Permissions are ok (I can load the file explicitly)
I have tried unix style and windows style path separator: nothing works.

I can hardly believe something this fundamental is actually broken - is there something about my setup that is wrong? I have a standard 3.04 installation using the windows installer any insights are appreciated.

[Ofnuts]

Is there a slash or backslash at the end of input-path?

[pyjamaslug]

I have done some more investigation with the console. I set up two folders with png files to find; one is the user home folder C:/Users/<my_user> and the other is a test folder in the root of the C: drive C:/test
This is what I got
First looking at the home folder, I simply out in the file search pattern.
> (cdr (file-glob "*.png" 1))
()
> (car (file-glob "*.png" 1))
("image_1920x1080_2025-08-06_11-05-48-22_0000.png" "ticket 2306.png" "ticket 5907.png" "ticket 5908.png" "ticket 5909.png" "ticket 5913.png" "ticket 5927.png")
> (cdar (file-glob "*.png" 1))

("ticket 2306.png" "ticket 5907.png" "ticket 5908.png" "ticket 5909.png" "ticket 5913.png" "ticket 5927.png")


So here it returns a list of files but its not what I expected. The list seems to be all in the head and there is nothing in the tail. The docs say the head contains the list length and tha tail contains the files (I was also expecting full paths not just filenames)

Looking at the test folder, I always get an empty list so it looks like the problem is with the path

> (cdr (file-glob "C:/test/*.png" 1))
()
> (car (file-glob "C:/test/*.png" 1))

()



Next I set up a test folder under the home dir and used a relative path

> (car (file-glob "/test/*.png" 1))
("/test/image_1920x1080_2025-08-06_11-05-48-22_0000.png" "/test/ticket 2306.png" "/test/ticket 5907.png" "/test/ticket 5908.png" "/test/ticket 5909.png" "/test/ticket 5913.png" "/test/ticket 5927.png")

bingo! it's using relative paths based on the user home dir and is ignoring absolute paths. Is this an environment thing or a bug?

[pyjamaslug]

one last piece of info: if I add another level to the relative path (like /test/images/) then once again it fails to find them

[pyjamaslug]

OK, in the spirit of answering my own questions:

Looks like there is only one problem and its all to do with windows vs unix path names. (I confused the issue above by having two folder trees with the same names so disregard the comment about relative paths - it isn't doing that)

in addition to not liking backslashes, file-glob doesn't like C: and it doesn't like spaces in folder names whereas regular file load and save are both comfortable with them. WIndows loves spaces - especially if you give your full name as a user and it creates your home directory with a space in it!
All of this means you can't just grab USERPROFILE and go from there. Also, it's going to be hard to grab files from a data drive.
Moving all my files to a unix-friendly location has solved the problem for now.
I still seem to remember reading that the file count is meant to be in the head, so I don't know what's going on there.

[Ofnuts]

(08-10-2025, 07:40 PM)pyjamaslug Wrote: OK, in the spirit of answering my own questions:

Looks like there is only one problem and its all to do with windows vs unix path names. (I confused the issue above by having two folder trees with the same names so disregard the comment about relative paths - it isn't doing that)

in addition to not liking backslashes, file-glob doesn't like C: and it doesn't like spaces in folder names whereas regular file load and save are both comfortable with them. WIndows loves spaces - especially if you give your full name as a user and it creates your home directory with a space in it!
All of this means you can't just grab USERPROFILE and go from there. Also, it's going to be hard to grab files from a data drive.
Moving all my files to a unix-friendly location has solved the problem for now.
I still seem to remember reading that the file count is meant to be in the head, so I don't know what's going on there.

To be accurate: Unix path names accept all characters, including spaces, which have been allowed in Unix filesystems since the beginning, well before windows existed. The only restriction is "/" (which is a separator) and the null byte, used internally at the end-of-string delimiter(*). This doesn't mean that care shouldn't be exercised when handling spaces because some code layers (notably the command line argument parsing for instance) may interpret "bare" spaces as token separators.

(*) Windows still forbids all control characters (characters with ASCII code < 32) as well as <>:"/\?*

[pyjamaslug]

any idea what is happening with the return values? From google's chat example they show this as a return list:

(3 ("~/Images/image1.jpg" "~/Images/image2.jpg" "~/Images/photo.jpg"))

Here, 3 is the number of matched files, and ("~/Images/image1.jpg" "~/Images/image2.jpg" "~/Images/photo.jpg") is the list of matched file paths.

but that is not what I am getting; the files are in the head (accessible using car) and the tail is empty.