GITFNS, PSUEDOHOSTS and OPENSTREAM are not all singing the same tune

[fghalasz]

Trying to a GITFNS gwc - getting a break in OPENSTREAM (see 2nd screenshot).

Same OPENSTREAM (with {WMEDLEY} pseudohost) typed into exec also fails (see 1st screenshot).

OPENSTREAM with {WMEDLEY} pseudohost replaced by it's TRUENAME - succeeds (see 1st screenshot). (Actually didn't use TRUENAME function in these screenshots - just typed true name in - but also succeeds if use TRUENAME function on {WMEDLEY}....)

Running on latest (as of 2022-09-29) maiko and medley masters. Running on Ubuntu 20.04 on top of WSL2 on Windows 11 2022H2.

[rmkaplan]

Is there a difference between WMEDLEY and GMEDLEY, given that you have them both on UNIX? I always have WMEDLEY on DSK. Does the dot at the end make a difference?

…

On Sep 29, 2022, at 6:33 PM, Frank Halasz ***@***.***> wrote: Trying to a GITFNS gwc - getting a break in OPENSTREAM (see 2nd screenshot). Same OPENSTREAM (with {WMEDLEY} pseudohost) typed into exec also fails (see 1st screenshot). OPENSTREAM with {WMEDLEY} pseudohost replaced by it's TRUENAME - succeeds (see 1st screenshot). (Actually didn't use TRUENAME function in these screenshots - just typed true name in - but also succeeds if use TRUENAME function on {WMEDLEY}....) Running on latest (as of 2022-09-29) maiko and medley masters. Running on Ubuntu 20.04 on top of WSL2 on Windows 11 2022H2. <https://user-images.githubusercontent.com/1251539/193170893-0e0f8fb0-269e-41e5-8322-2f7f7d136519.png> <https://user-images.githubusercontent.com/1251539/193170912-2d9f9108-93f6-4972-a3a8-25fbcb29984d.png> — Reply to this email directly, view it on GitHub <#959>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJ5JY3TGHU7H27GGT3WAY7PPANCNFSM6AAAAAAQZJOWIE>. You are receiving this because you are subscribed to this thread.

[fghalasz]

Dot at the end makes no difference.

No specific reason why I used UNIX instead of DSK for WMEDLEY. But GIT-MAKE-PROJECT always sets GMEDLEY to UNIX (see second screenshot below).

If I set WMEDLEY to DSK in GIT-MAKE-PROJECT, then gwc still fails but this time it fails with:
 

 
 
And OPENSTREAM on GMEDLEY fails, while OPENSTREAM on WMEDLEY (set to DSK) succeeds.
 

 
 
So the issue appears related to {UNIX}?

[rmkaplan]

What if you make SOURCES lower case ? Maybe the Unix device on the Mac is less case sensitive than elsewhere?

…

On Sep 29, 2022, at 10:36 PM, Frank Halasz ***@***.***> wrote: Dot at the end makes no difference. No specific reason why I used UNIX instead of DSK for WMEDLEY. But GIT-MAKE-PROJECT always sets GMEDLEY to UNIX (see second screenshot below). If I set WMEDLEY to DSK in GIT-MAKE-PROJECT, then gwc still fails but this time it fails with: <https://user-images.githubusercontent.com/1251539/193196814-57c40024-939d-4a88-93f0-12916bdc068f.png> And OPENSTREAM on GMEDLEY fails, while OPENSTREAM on WMEDLEY (set to DSK) succeeds. <https://user-images.githubusercontent.com/1251539/193197152-0f6747f0-650e-453f-8c11-c9d1109fad6c.png> So the issue appears related to {UNIX}? — Reply to this email directly, view it on GitHub <#959 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJI3FKLRRWUZIVGJRFDWAZ37LANCNFSM6AAAAAAQZJOWIE>. You are receiving this because you commented.

[masinter]

Case sensitivity depends on the file system; in Windows with WSL, the WSL Ubuntu is case sensitive; SunOS is case insensitive. And {DSK} treats foo and foo. as equivalent but Unix doesn't.

Is there a SUBR that will translate a DSK filename to the exact shell command variable? It would be better than the ad-hoc code we have for MEDLEYDIR and other environment variables. We also need to support Unicode file names at some point, and that will require some Maiko changes.

[nbriggs]

SunOS is case-sensitive, Linux file systems are generally case-sensitive. WSL can be adjusted, as can macOS.

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

Not sure what you mean by "translate a DSK filename to the exact shell command variable"

[fghalasz]

Yes, case of sources makes a difference. But the ending dot makes no difference.

 
 
Seems like for GITFNS dealing with git directories of Lisp code, we want a HOST with the case-insensitivity of DSK but all the other properties of UNIX.

[rmkaplan]

OK, there may not be a general fix, but I think our convention is that Lisp directories are in lower-case. And I think I put in a flag in GITFNS (not PSEUDOHOSTS) to control what gets lowercased when you are going to the git repo directory. But I think I assumed that that wasn’t need for the working (usually DSK) directory. I can change that.

…

On Sep 30, 2022, at 11:00 AM, Frank Halasz ***@***.***> wrote: Yes, case of sources makes a difference. But the ending dot makes no difference. <https://user-images.githubusercontent.com/1251539/193329148-d0170b8d-b2c8-4539-a3af-e57ebd96cc87.png> Seems like for GITFNS dealing with git directories of Lisp code, we want a HOST with the case-insensitivity of DSK but all the other properties of UNIX. — Reply to this email directly, view it on GitHub <#959 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJIZF2F35ZT5EVPXXSLWA4TE5ANCNFSM6AAAAAAQZJOWIE>. You are receiving this because you commented.

[fghalasz]

@rmkaplan I think the case is not handled correctly on the git repo side of GITFNS either.

If I switch WMEDLEY over to {dsk}, then instead I get a break trying to find {GMEDLEY}/SOURCES/10MBDECLS during gwc.

See the first screen shot in my comments about 6 back. It shows the break with GMEDLEY - although not much context I admit.

[fghalasz]

If you set the global variable *UPPER-CASE-FILE-NAMES* to NIL, then gwc works fine on Linux.

(See my closing note on Issue#964)

Since it appears quite a bit of code in Medley references *UPPER-CASE-FILE-NAMES*, setting it to NIL globally is a bit risky. We should probably just wrap the DIRECTORY call(s) inside GITFNS in a (LET ((*UPPER-CASE-FILE-NAMES* NIL)) --)