WTF is it with CFers that they think they have to mess about determining what the path separator is on every platform? In a pathetic attempt to be cross-platform, I see all sorts of convoluted code that tries to strip characters out of paths or check the O/S version in an attempt to establish whether \ or / is the right thing to use.
Word up CFers: / always works. We're using Java now and / works on Windows. Yes, really. / works on Windows, Mac and Unix. Instant cross-platform compatibility.
Making a path work on all platforms is a matter of simply doing:
Please stop trying to be cross-platform and do the right thing instead.
What triggered this rant? The latest varScoper code doesn't work on Mac OS because of this nonsense. Change line 29 of varScoper.cfm to just:
This was placed in because there was a new "directoryexcludelist" option within the new properties file. The thought was that a developer on windows would more or less write their directory path with c:\ and not c:/ so the code was to be smart enough to look for this.
It may just be best to keep a standard (use /) and note that as a comment within the properties file.
path = replace(path,"\","/","all);
Works on every platform. Really.
"The thought" was a Windows thought. A bad one.
Well Windows is Windows and that's all I am going to say about that :-)
I have to admit that I do find the slash programmatically :( Something like:
Server: Left( REReplace( GetCurrentTemplatePath(), "^[^\\/]*", "", "all" ), 1 )
Web: "/"
I only do it once, though, and then I use two functions to encapsulate it's use:
CleanServerPath() CleanWebPath()
I know you say it works in all systems, but I swear that even in MX, I have run into problems where it was causing problems not having the proper slashes.
Maybe I am totally crazy though :)
It would be my view that everything be relative to the application. This way if the code is moved between OS's or platforms, we know where everyting will be.
If it has to be jard coded, Coldfusion is smart enough to know what OS it is running on. Why, because Java does all that work for us...
I think it was a nice thought, maybe in the days before Java one would need to do this:-)
But ... it has, to the best of my knowledge, pretty much *always* worked, even in pre-Java days. I've been using "/" in code since at least as far back as v4.
In the case you are referring to I know you're correct. However, I'm doing a lot of work with cfdirectory created paths, which report the directory information in the OS format. What's wrong with using createObject("java", "java.io.File").separator to figure out the OS's fileseparator and using that dynamically?
createObject("java", "java.lang.System").getProperty("file.separator")
either then?
@Terrence, expandPath() and getBaseTemplatePath() etc also return paths containing the native OS separator but I just run that replace() on them and all's well.
@David, no, that seems to be the worst of all worlds to me - using Java to get a value that Java doesn't actually care about :)
Fusebox 4 used to mess about getting the native OS delimiter and then was full of nasty concatenation code to construct file paths. Fusebox 5 uses / throughout and the file handing code is much cleaner.
It's really just one of my pet peeves with CFML code. I have several pet peeves with CFML code. I may blog about some of the others over the next week or two since it seems to get a response! :)
hehehe, classic.
For example, if at c:\, cd /temp works, but once you are at c:\temp, cd /temp fails, as it doesn't recognise the leading / as a root directory.
Go figure.
I don't know if this suggests possible problems for MX?
Some more rants like this one would be welcome. I've always written code to handle delimiters and never heard a peep from anyone that it was unnecessary.
Excuse the sound of ripping code . . .
Yes more rants like this good. I think too often people want to be diplomatic about things, but if people consider you to be a reasonable authority then bringing up issues in a direct way is good.
Also makes for fun reading :-D
