Tcl Source Code

There is also an anomaly with the curly brace glob mechanism:


  % set results [glob -dir c:/SDX {SDX?.BAT} {SDX*.bat} {SDX[1].bat} {SDX\1.bat} {SDX{1,2}.BAT} SDX1.BAT] 
    c:/SDX/sdx1.bat c:/SDX/sdx1.bat c:/SDX/sdx1.bat c:/SDX/sdx1.bat c:/SDX/SDX1.BAT c:/SDX/SDX1.BAT

As already said in chat, it works exactly as expected.

The FS on windows is case-insensitive...
The uniqueness is if $path is equal $path and only $path...
Using case-insensitive comparison operations (e. g. [string equal -nocase]) this equality has been proven.

The "anomaly with the curly brace glob mechanism" from your comment is also not the anomaly, if one consider that the uniqueness is given only in a case-insensitive way (-nocase). The values are different, because windows API for glob cannot handle curly braces directly, so it happens on tcl-side, and since the file exists, the return value is different. The picture would change again, if you would try it with a wildcard like {SDX{1,2}.*}, because then it'd try curly braces against the listing from iterating API calls.

Just note that because uniqueness is guaranteed (in case-insensetive manner) and iterating API calls are time-expensive and costly, glob would avoid iterations unless necessary.

The normalization has also nothing to do with the case-sensitivity...
It is about resolving of ".." segments, relative or volume-relative paths, links, wrapping backslash to slash, etc... nothing else.

Regarding WSL, it also works as expected, because the case-sensitivity of mount is different to case-sensitivity of origin file system.
Therefore the exact glob for {SDX1.bat} find the file, but for {[S]DX1.bat} or some wildcard the glob must iterate over directory listing returned from FS, and in case-sensitive mount point the file simply doesn't exist, because it is "sdx1.bat". The issue of "anomaly" is therefore

Please also consider https://learn.microsoft.com/en-us/windows/wsl/case-sensitivity

I'll close this as incorrect, sorry.

Tell me is this behaviour reasonable? (strong opionion: it's not)


  C:/Users/sleek/AppData/Local/Apps/Tcl90b3/bin
  % set files [glob -dir C:/SDX SDX1.bat SDX1.bat]
  C:/SDX/SDX1.bat C:/SDX/SDX1.bat
  % lassign $files f1 f2

  % file normalize $f1
  C:/SDX/SDX1.bat
  % file normalize $f2
  C:/SDX/SDX1.bat

  % file normalize [string range $f1 0 end]
  C:/SDX/sdx1.bat

  % file normalize $f1
  C:/SDX/sdx1.bat
  % file normalize $f2
  C:/SDX/SDX1.bat

This is a situation that script programmers can't be reasonably expected to reason about to produce reliable code.

I wasn't telling you where the bug is exactly - and I'm willing to accept guidance that for reasons of practicality some things have to be the way they are - but at the very least (even without the 'string range' changing the result) this is an issue of serious underdocumentation of *highly surprising* effects and should at least be left open for others on the team to consider if documentation can be improved around this.

Yes, the behavior is reasonable, if you'd forget the case-sensitivity thing (you trying persistently to consider case sensitivity there, where it does no matter).

Regarding normalization from string and "correct" value, I guess one could indeed try to optimize it somehow (e. g. return translated path object instead of normalized path object from glob on windows, so that [file normalize] would be more "consistent" as for case-sensitivity)...

What would be definitely worse to make such kind of implicit "normalization" for EVERY hit in the result of glob by default, because this can cause large performance degradation (by large directory listing), or issues like [02d5d65d70].