BitBucket isn’t displaying comment threads on issues for some reason,
so am posting Adam’s observation here (which I got via email) as I’d
be interested in others’ take on this. Especially Sean’s as I believe
this is a peeve of his.
But seems you have point, Adam: canonical paths shouldn’t vary.
Not sure I care for convertSeparatorsToForwardSlashes() though.
Replace() probably best as you say.
Cheers for the feedback.
Julian.------------------------
Adam Cameron commented on issue #298:
GetCanonicalPath() BIF should always return forward slashes
Not sure I agree there. Canonical paths are supposed to express the
canonical path to the file, which is an actual accepted concept. It’s
not just something to make a CFML dev’s life easier.
Also, see this code:
path = "c:/temp/test.txt";
f = createObject("java", "java.io.File").init(path);
canonicalPath = f.getCanonicalPath();
writeDump(var=[path,canonicalPath],format="text");
I have even tried to suggest to the function here that I’m good with
forward slashes. But the output is:
Array
1 string c:/temp/test.txt
2 string C:\temp\test.txt
There’s probably a case for JVM languages to follow Java’s behaviour?
What you want is a different function which is along the lines of
convertSeparatorsToForwardSlashes(). But just going replace(path, "",
“/”, “ALL”) probably already covers this. However it’s always good to
have specific functions for specific use-cases though, so there’s
perhaps a case for the specialised function in a perfect world.
On 17 April 2015 at 14:26, Julian Halliwell <@Julian_Halliwell> wrote:
have raised a ticket:
Log in with Atlassian account
On 17 April 2015 at 13:59, Chris Schmitz <@Chris_Schmitz> wrote:
Railo/Lucee on the other hand do have a built in function getCanonicalPath()
which does NOT replace the back slashes.
BitBucket isn’t displaying comment threads on issues for some reason,
so am posting Adam’s observation here (which I got via email) as I’d
be interested in others’ take on this. Especially Sean’s as I believe
this is a peeve of his.
To be very clear: I am not disputing the merit or desirability of the end
result, I am questioning the suggested mechanism for getting there.On Friday, 17 April 2015 15:26:53 UTC+1, Julian Halliwell wrote:
–
Adam
My pet peeve is developers not ensuring their code is portable across Windows/Mac/Linux because it’s easy to do: every time you get a file system path, turn it into something portable, then all your logic can work the same on every platform (using forward slashes).
As Adam notes, that’s as simple as always calling replace(path,“",”/",“all”) every time you’re given a native path, then using “/” to construct file paths. No need to mess with the various separator variables.
Now, should all of the functions that produce file paths — and all of the variables that produce file paths — do this for you automatically? There’s an argument in favor of that but it would touch a lot of functions, not just GCP and it would break Windows-only code. So I’m against that change (even tho’, long term, I think we’d have more portable code).
If you’re writing Windows-only code, you don’t care — and most CFML lives on Windows. Filenames are case-insensitive, either slash works.
Sean Corfield – (904) 302-SEAN
An Architect’s View – http://corfield.org/
“Perfection is the enemy of the good.”
– Gustave Flaubert, French realist novelist (1821-1880)On Apr 17, 2015, at 7:26 AM, Julian Halliwell <@Julian_Halliwell> wrote:
BitBucket isn’t displaying comment threads on issues for some reason,
so am posting Adam’s observation here (which I got via email) as I’d
be interested in others’ take on this. Especially Sean’s as I believe
this is a peeve of his.
If you’re writing Windows-only code, you don’t care — and most CFML
lives on Windows.
On the contrary, the number of places with Windows-only CFML code is
going to be close to zero.
There’s this little thing called “the Internet” that even CFML
developers stuck on Windows tends to work with, and it uses forward
slashes, and arsing about with switching slashes when working with URLs
and directories is a frustrating waste of time.
If there was an admin option to fix the slashes (or not) for all
functions/etc then CFML can default to backwards-compatible OS-specific
(but allow changing) and the new dialect can default to doing it the
right way, and developers can get on with producing useful code.
If you’re writing Windows-only code, you don’t care — and most CFML
lives on Windows.
On the contrary, the number of places with Windows-only CFML code is
going to be close to zero.
In my exposure to this, most CFML deployments are on *nix. HB is on
Windows, but that’s the first “big” site that’s been on Windows that I’ve
worked on. Other than that it’s only been the small sites on Windows.
I’m not suggesting that’s statistically meaningful, but in my experience
there’s more CFML-based traffic hosted on *nix than Windows.On Saturday, 2 May 2015 20:30:43 UTC+1, Peter Boughton wrote:
–
Adam
I’d be curious if there are any stats on distribution of different OS’s
using Lucee tbh - I mean anecdotally I know all the ones I work on are
Linux rather than Windows ( though at mso we do have some on windows
machines also )On Saturday, 2 May 2015 23:10:32 UTC+1, Adam Cameron wrote:
On Saturday, 2 May 2015 20:30:43 UTC+1, Peter Boughton wrote:
If you’re writing Windows-only code, you don’t care — and most CFML
lives on Windows.
On the contrary, the number of places with Windows-only CFML code is
going to be close to zero.
In my exposure to this, most CFML deployments are on *nix. HB is on
Windows, but that’s the first “big” site that’s been on Windows that I’ve
worked on. Other than that it’s only been the small sites on Windows.
I’m not suggesting that’s statistically meaningful, but in my experience
there’s more CFML-based traffic hosted on *nix than Windows.
–
Adam
For the record this is on Jira
Any comments would probably be worth putting on there if important for the
ticket :)On Friday, 17 April 2015 15:26:53 UTC+1, Julian Halliwell wrote:
BitBucket isn’t displaying comment threads on issues for some reason,
so am posting Adam’s observation here (which I got via email) as I’d
be interested in others’ take on this. Especially Sean’s as I believe
this is a peeve of his.
But seems you have point, Adam: canonical paths shouldn’t vary.
Not sure I care for convertSeparatorsToForwardSlashes() though.
Replace() probably best as you say.
Cheers for the feedback.
Julian.
Adam Cameron commented on issue #298:
GetCanonicalPath() BIF should always return forward slashes
Not sure I agree there. Canonical paths are supposed to express the
canonical path to the file, which is an actual accepted concept. It’s
not just something to make a CFML dev’s life easier.
Also, see this code:
path = "c:/temp/test.txt";
f = createObject("java", "java.io.File").init(path);
canonicalPath = f.getCanonicalPath();
writeDump(var=[path,canonicalPath],format="text");
I have even tried to suggest to the function here that I’m good with
forward slashes. But the output is:
Array
1 string c:/temp/test.txt
2 string C:\temp\test.txt
There’s probably a case for JVM languages to follow Java’s behaviour?
What you want is a different function which is along the lines of
convertSeparatorsToForwardSlashes(). But just going replace(path, "",
“/”, “ALL”) probably already covers this. However it’s always good to
have specific functions for specific use-cases though, so there’s
perhaps a case for the specialised function in a perfect world.
On 17 April 2015 at 14:26, Julian Halliwell <julianh...@gmail.com <javascript:>> wrote:
have raised a ticket:
Log in with Atlassian account
On 17 April 2015 at 13:59, Chris Schmitz <cfl...@gmail.com <javascript:>> wrote:
Railo/Lucee on the other hand do have a built in function
getCanonicalPath()
which does NOT replace the back slashes.
You have valid points Peter - please could you put them as a comment
against the ticket [LDEV-182] - Lucee ? -
Otherwise when it comes to triaging that ticket any supporting info in this
thread is not necessarily going to be seen!On Sunday, 3 May 2015 14:41:12 UTC+1, Peter Boughton wrote:
Where “couldn’t be bothered” may actually be “the entire sysadmin team
are fully qualified MCSEs and the servers are all paid for, configured,
stable, etc”.
But I was not talking about which is more used (though it is Windows,
whether we like it or not), I was simply pointing out “Windows-only”
was not meaningful, because URLs use forward slashes.
In short:
-
There is a significant quantity of current and potential Lucee
developers that need to cater for the contrary ways of Windows.
-
Having paths normalised to forward-slashes automatically - toggleable
via an admin setting for compatibility - is useful functionality.
-
Having to wrap every single file/directory-related function with a
function call (whether specifically named or using replace or
ListChangeDelims) is extra effort.
Where “couldn’t be bothered” may actually be “the entire sysadmin team
are fully qualified MCSEs and the servers are all paid for, configured,
stable, etc”.
But I was not talking about which is more used (though it is Windows,
whether we like it or not), I was simply pointing out “Windows-only”
was not meaningful, because URLs use forward slashes.
In short:
-
There is a significant quantity of current and potential Lucee
developers that need to cater for the contrary ways of Windows.
-
Having paths normalised to forward-slashes automatically - toggleable
via an admin setting for compatibility - is useful functionality.
-
Having to wrap every single file/directory-related function with a
function call (whether specifically named or using replace or
ListChangeDelims) is extra effort.
Peter, I’d actually withdrawn 298 accepting Adam’s argument that
slash-normalisation, while a good thing, isn’t GetCanonicalPath()'s
job. Guess that’s why it didn’t migrate.
If I’d seen you previous and far better suggestion, I wouldn’t have
created the ticket. Have voted for yours now.
Julian.On 3 May 2015 at 17:47, Peter Boughton <@Peter_Boughton> wrote:
Added comment to LDEV-182.
I was going to reference/comment on the bitbucket issue 298 too, but I
couldn’t find that (I checked all 7 pages on the “all issues” page.)
Log in with Atlassian account
Hi Peter
The issue I linked is the bitbucket issue I believe. As has been
mentioned on previous threads, the Bitbucket → Jira migration tool leaves
much to be desired.
Kind Regards, Simon Simon Hooker Head of Product Development t.
+44 (0)1474 704400 e. @Simon_Hooker w. mso.net
http://www.mso.net/ mso.net http://www.mso.net/, The Old Granary,
Malt House Farm, Green Street Green Road, Dartford, Kent DA2 8DX
https://www.facebook.com/msonet https://twitter.com/MSOdotnet The
information in this email is confidential and may be legally privileged. It
is intended solely for the addressee. The content does not necessarily
represent the opinion of mso.net http://www.mso.net/ or any of its
affiliates.
If you are not the intended recipient(s), any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on it,
is prohibited and may be unlawful. If you have received this communication
in error please notify us by e-mail postmaster@mso.net or by telephone +44
(0)1474 704400
Online New Media t/as mso.net http://www.mso.net/ Registered in England
No. 3824328. Registered office: The Old Granary, Malt House Farm, Green St
Green Road. Dartford. Kent DA2 8DX Please consider your environmental
responsibility before printing this emailOn 3 May 2015 at 17:47, Peter Boughton <@Peter_Boughton> wrote:
Added comment to LDEV-182.
I was going to reference/comment on the bitbucket issue 298 too, but I
couldn’t find that (I checked all 7 pages on the “all issues” page.)
Log in with Atlassian account
–
You received this message because you are subscribed to a topic in the
Google Groups “Lucee” group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/lucee/yMHUITwZLeM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/20150503174754.0000163b%40sorcerersisle.com
.
For more options, visit https://groups.google.com/d/optout.
As sad as it is - I’m aware of a lot of large CFML systems on Windows. To be fair, most of them are ACF or moved-from-ACF-to-Railo-and-couldnt-be-bothered-to-change.
Cheers
Kai>
On Saturday, 2 May 2015 20:30:43 UTC+1, Peter Boughton wrote:
If you’re writing Windows-only code, you don’t care — and most CFML
lives on Windows.
On the contrary, the number of places with Windows-only CFML code is
going to be close to zero.
In my exposure to this, most CFML deployments are on *nix. HB is on Windows, but that’s the first “big” site that’s been on Windows that I’ve worked on. Other than that it’s only been the small sites on Windows.
I’m not suggesting that’s statistically meaningful, but in my experience there’s more CFML-based traffic hosted on *nix than Windows.
–
replace(path,“",”/",“all”) every time you’re given a native path, then
using “/” to construct file paths. No need to mess with the various
separator variables.
Except on Windows when the path uses Unicode characters or is longer than
260 characters:
JochemOn Apr 17, 2015 18:56, “Sean Corfield” wrote:
As Adam notes, that’s as simple as always calling
Added comment to LDEV-182.
I was going to reference/comment on the bitbucket issue 298 too, but I
couldn’t find that (I checked all 7 pages on the “all issues” page.)
My “couldn’t be bothered” comment referred more to:
People having a Win box with ACF, literally swapping ACF with Railo/Lucee
and not making any other change.
If people have a good reason to host a non-.NET web app on Windows, I’m
happy for them to do so and they totally should use that as a platform of
their choice. In my personal experience the vast majority of people who
host CFML on Windows do so because it’s the path of least resistance when
starting.
Cheers
KaiOn Monday, May 4, 2015 at 1:41:12 AM UTC+12, Peter Boughton wrote:
Where “couldn’t be bothered” may actually be “the entire sysadmin team
are fully qualified MCSEs and the servers are all paid for, configured,
stable, etc”.
But I was not talking about which is more used (though it is Windows,
whether we like it or not), I was simply pointing out “Windows-only”
was not meaningful, because URLs use forward slashes.
In short:
-
There is a significant quantity of current and potential Lucee
developers that need to cater for the contrary ways of Windows.
-
Having paths normalised to forward-slashes automatically - toggleable
via an admin setting for compatibility - is useful functionality.
-
Having to wrap every single file/directory-related function with a
function call (whether specifically named or using replace or
ListChangeDelims) is extra effort.