[M3devel] [M3commit] CVS Update: cm3

[Olaf Wagner]

Quoting Jay <jayk123 at hotmail.com>:
> I'd like to make "progress" on what I have -- mainly slash   
> independence, no colon hack on Unix.
> And then see about making much more progress.

OK.

> M3Path compromises a few bits of functionality, some of which could   
> go in libm3, but not all.
>
> It has "path cleanup", of a sort that was strongly suggested here to  
>  be wrong.
> That is, "cleanup" of a/./b to a/b, a/../b to b.
> Incorrect in the face of links.
> But still general purpose if people want it.
> The code that does this work I think can stand a rewrite. It is   
> currently limited to 31 slashes and after that it just silently   
> ignores stuff. If you reverse the path first, do the work, reverse   
> again, you can support unlimited lengths with small fixed memory   
> (smaller than it currently uses to support limit lengths).
>
> It has "path conversion" between "host" and "target".
> This is specially just changing slashes around.
> It does not deal with "drive letters".

I see. This could be abstracted, too, though.

> It deals with "file types".
> This is an area that probably does not belong in libm3.
> "types" are, you know, .m3, .i3, reasonably simple, but also   
> libfoo.a vs. foo.lib.
> There is code to pick apart paths to "in that way", which I find..a   
> little unusual.

OK. This is rather compiler specific.

> I did already change the Win32 Pathname implementation to   
> always/usually treat forward and backward slashes as the same. That   
> goes pretty far.
>
> I believe the Pathname abstraction is that a path is essentially an   
> array of strings, you can add/remove from either end, add to one or   
> the other or both ends, and join two.

Yes, but it could be extended. There is also some support for
different kinds of `roots'.

> An issue I'm avoiding..because I don't want to pollute the code with  
>  calls out ot Cygwin, is "correct" conversion between Win32 and   
> Cygwin paths. Generally the conversion is c:\foo <=> /cygdrive/foo.
>
> I haven't seen how "network paths" are handled.
>
> Path handling is a surprisingly large rats nest of subtle behaviors   
> and I'm not sure I really want to open it.

I'll second that.

> Really, there are a few Win32 behaviors that i haven't gotten into..
>
> Even if you ignore Win32 -- what about case sensitivity? Even on Mac  
>  and presumably Unix (to a Mac or Windows server), you can encounter  
>  case insensitive file systems. The current Modula-3 code is not   
> prepared for that.

Case sensitivity of file names should be handled centrally, too.
It could be a property of a filename. But then that property needs to
be set by someone - runtime, environment, user, application...
As this is a big issue for portability of code, I'd say we should
come up with some sound concept here, but of course that can be
independent of your current work.

> One of my favorite sob stories here, I've probably told it here, is   
> that I have a low end NAS (it won't boot lately..). It runs Linux,   
> of course (I said it is low end). I downloaded it source, extracted   
> it, xcopied, xcopyied it again incrementally. That fails. Because   
> some of the file names start with a dot and on Unix, that means they  
>  are hidden and cannot be unhidden..

`Hidden' on Unix usually only means that files are not shown with
a simple `ls'. There's nothing special in the system to treat dot-files
different from others as far as I know.

> So this whole "hidden" thing is not portable, just as colons in   
> paths are not portable, but they work just fine if you stay on one   
> system...

> Let me get M3Path to where I want it, and repair the Unix colon   
> behavior, and see about rewriting the "cleanup" code... as long as   
> folks are happy with how it ends up, I'm not sure I want to puruse   
> it much more. There are much bigger fish...

OK, I can understand that you just want to finishd your current work.

> Oh, I already have code on my system so that when we read ROOT,   
> CM3_INSTALL, CM3_ROOT from the command line and/or environment,   
> those paths get "fixed up" -- slashes reversed. That should help a   
> lot here, without much pollution..

It should help, but it also needs to be tested on different platforms.

> One thing I'm not sure about is the treatment of backward slashes   
> equivalent to forward slashes on Posix.
> Maybe better just to do that fixup upon a few certain inputs. And   
> have Win32 use either, but Posix only forward.
> It's "harmless" but loose.

Yes, I'd be rather conservative there, too.

> There this general problem of "user input" vs. "internal, strongly   
> typed, analyzed, rule-following" data.
> As well as then presenting the internal data back to the user in the  
>  form he expected.
>
> It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foo
> but when an error message is reported, in case I am going to   
> copy/paste the paths in it to file.open, it should be back with   
> backward slashes. This is not simple. You could maintain two   
> parallel representations as you muck with the path. Not great. You   
> could "characterize" the form of the user in put (which slash   
> directory), keep that around, it's just one bit, and use it to guide  
>  the later presentation...

One internal, abstract representation of the data, and two or more
views on it (getPosixPath, getWindowsPath, ...) come to mind here.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194