Tcl Source Code: View Ticket

Ticket UUID:	e6ca0b1b678f89f0cd6228d9a84604f5a950637a
Title:	glob inconsistencies on macos
Type:	Bug	Created on:	2026-03-31 05:20:16
Submitter:	apnadkarni	Assigned to:	apnadkarni
Subsystem:	- New Builtin Commands	Severity:	Important
Priority:	5 Medium	Last modified:	2026-04-20 05:34:35
Status:	Closed	Closed by:	apnadkarni
Resolution:	Fixed	Closed on:	2026-04-20 05:34:35
Version:	9.0

Description:
(Copied from core mailing list) It seems to me then that Tcl on macos has at least one, and possibly up to three, bugs. Inconsistent case-sensitivity in matching. I expect `glob /tmp/MIXEDCASE glob /tmp/M` both to either include MiXeDcAsE in the return or not, depending on case sensitivity of the file system. But the results do not match. Likewise for `glob /tmp/mixedcase glob /tmp/m` I think this is a definite bug because it is inconsistent. Second possible bug is that Tcl does case-sensitive matching on macos when the expectation is case-insensitive. It's confusing for me because as per Google (and verified by Kevin), modern Macs have case-insensitive file systems by default. Mac users need to comment and take a call on this. (Not from the tests, but reading the code) file normalize possibly has the same bug it had on Windows where it did not actually normalize to a unique file system representation. For now, I’m disabling the tests I added on MacOS. -----Original Message----- From: Torsten Berg <be...@ty...> Sent: Monday, March 30, 2026 11:30 PM To: <apn...@ya...> <apn...@ya...> Cc: tcl...@li... Subject: Re: [TCLCORE] Question for Mac users Using Tcl 8.6.16 on a macOS using an internal SSD formatted as APFS, not case-sensitive: () 1 % glob /tmp/MIXEDCASE /tmp/MIXEDCASE () 1 % glob /tmp/mixedcase /tmp/mixedcase () 1 % glob /tmp/MiXeDcAsE /tmp/MiXeDcAsE () 1 % glob /tmp/m* no files matched glob pattern "/tmp/m" () 1 % glob /tmp/M /tmp/MiXeDcAsE % tclsh9.1 % info pa 9.1a1 % glob /tmp/MIXEDCASE /tmp/MIXEDCASE
User Comments:
apnadkarni added on 2026-04-01 08:20:38: It appears that the inconsistency between ``` glob /tmp/MIXEDCASE glob /tmp/M* ``` occurs because matching code is case-sensitive and existence check is case-insensitive (via lstat on MacOS). My opinion, as a non-macos user is that the matching code should be changed to be case-insensitive. Though this would be a backward incompatibility, it feels more like a bug fix. jan.nijtmans added on 2026-04-01 10:44:22: > My opinion, as a non-macos user is that the matching code should be changed to be case-insensitive. Though this would be a backward incompatibility, it feels more like a bug fix. +1 apnadkarni added on 2026-04-10 05:14:31: The apn-mac-case branch now contains proposed fixes for the following, related but independent, issues on MacOS. Inconsistent returns from `glob M` and `glob MixedCase` (original ticket) `file normalize` does not return the unique name for a file (does not resolve the leaf to its on-disk name) MacOS file paths should be case-insensitive There is likely to be a (not quantified) performance impact to `file normalize` on MacOS as it now has to resolve the last path component's real name (just as on Windows). Correctness prevails. Reviews, particularly from MacOS folks, would be appreciated. apnadkarni added on 2026-04-14 17:37:52: Fixed in [8577ad7896]. jmroot added on 2026-04-19 07:32:23: As a macOS user, I think the only way to make `glob` do what the caller wants all the time is to add an explicit `-nocase` option like `string match` has. Case-sensitive matching is what globs in the shell do (even on a case-insensitive FS): % touch f1 f2 f2 Fa Fb Fc % ls F Fa Fb Fc % ls f* f1 f2 f3 Not being able to match in that way without extra post-processing would be a definite step backwards. IMO, the behaviour when there is a file called `MixedCase` should be: glob M* -> MixedCase glob m* -> glob -nocase m* -> MixedCase glob MIXEDCASE -> glob -nocase MIXEDCASE -> MixedCase HFS+ and APFS come in two flavours, case-sensitive and case-insensitive but case-preserving. Having your main filesystem formatted as case-sensitive is much less common but certainly not unheard of. In both flavours, filenames on disk have a specific case, and I definitely agree that `file normalize` should return that. apnadkarni added on 2026-04-20 05:34:35: The `-nocase` need (or equivalent fix) is not unique to macos and is logged separately as [a5ba717243]. This branch did not address that. Besides fixing the inconsistency between globbing `m` versus `mixedcase`, it only brings macos into consistency with other Tcl platforms where glob matching is on a per-platform basis, and is based on "general user expectations". Issues related to differing case-sensitivity in file systems are known to be broken functionality. Case-sensitivity in shells on case-insensitive file systems is broken in the other direction so I'm not sure that is a good example to follow. glob was never defined to return the on-disk name. If you need that, you have to normalize. The rationale that has been expressed is very often there is no need to incur the cost of that normalization, e.g. `foreach f [glob .bak] {file delete $f}` or something like that. But I agree a more complete solution to the file system casing is required. Hence the aforementioned ticket.