Fix occasional escapes in the file path

[VK]

On Windows platforms path separator "\" collides with the script escape
sign "\"
Obvious and old way to prevent it is to double backslashes: "\\"

But I'm curious if there is a reliable way to *restore* the right path
is user occasionally forgets to double some slash? Naturally nothing we
can do in a case like:
getFolder("c:\docs\new\") because it will lead to the syntacs error
long before to arrive to getFolder function.

But in case like getFolder("c:\docs\new")
getFolder will get the path but it will be corrupted.

 

[Julian Turner]

On Windows platforms path separator "\" collides with the script escape
sign "\"
Obvious and old way to prevent it is to double backslashes: "\\"

But I'm curious if there is a reliable way to *restore* the right path
is user occasionally forgets to double some slash? Naturally nothing we
can do in a case like:
getFolder("c:\docs\new\") because it will lead to the syntacs error
long before to arrive to getFolder function.

But in case like getFolder("c:\docs\new")
getFolder will get the path but it will be corrupted.

Some amateur thoughts:-

When you say the "user" occasionally forgets, who is the user. Your
example suggests that the user is in fact writing Javascript, because
escaping back slash characters is only needed when writing a string
literal. If so, is that issue is more of a coding quality control
issue.

If the path checking is done at code writing stage, then if the user
types 'getFolder("c:\docs\new")' then it might be feasible to read the
source code and look for instances of '\d' and make an assumption that
'\\d' was intended, but '\n' will be an ambiguous case.

If the path checking is done at run-time, then the path will already be


'c:docs
ew'

which might be easy to guess, but what about

c:mydocumentsmypictures - there is no way to make a guess as to where
the diving lines were intended to be without some knowledge of the
likely paths that may be inputted.

If your "user" is typing backslashes into an INPUT text field or
TEXTAREA, or the file path is to be an attribute value in HTML markup,
then your user does not need to escape the backslash at all.

Julian

 

[VK]

Some amateur thoughts:-

When you say the "user" occasionally forgets, who is the user. Your
example suggests that the user is in fact writing Javascript, because
escaping back slash characters is only needed when writing a string
literal. If so, is that issue is more of a coding quality control
issue.

If the path checking is done at code writing stage, then if the user
types 'getFolder("c:\docs\new")' then it might be feasible to read the
source code and look for instances of '\d' and make an assumption that
'\\d' was intended, but '\n' will be an ambiguous case.

If the path checking is done at run-time, then the path will already be


'c:docs
ew'

which might be easy to guess, but what about

c:mydocumentsmypictures - there is no way to make a guess as to where
the diving lines were intended to be without some knowledge of the
likely paths that may be inputted.

Thanks for your response - indeed I was so concentrated on \n \f \t
cases that I missed the obvious \[normal char] case.
c:mydocumentsmypictures seems not resolvable w/o caller lookup and
study (getFolder.caller + a bunch of RegExp). Besides using deprecated
getFolder.caller it just gets too complicated and unreliable.

I guess I just put a check for the \n \f \t sweet trinity, as I don't
know any platform where new line, form feed or tab could be met in the
path name (?)

My abstract user is someone using 3rd party library, and my approach
(maybe questionnable) is that user has start to think only when the
computer cannot think for her anymore, not any earlier

 

[Thomas 'PointedEars' Lahn]

I guess I just put a check for the \n \f \t sweet trinity, as I don't
know any platform where new line, form feed or tab could be met in the
path name (?)

You probably know only Microsoft Windows on an IBM-compatible PC.

It is a matter of the filesystem, not of the platform. Certain
characters are not allowed in filenames on FAT or NTFS filesystems
while they are allowed in other filesystems. For example, it is
possible to create a file named

test
1

on a ext2/ext3 filesystem:

$ touch 'test
1'

$ ls -l test*
-rw-r--r-- 1 ******* users 0 2005-11-08 00:28 test?1

(The `?' of course represents the non-printable newline character `\n'.)

A compatible ext2/ext3 filesystem driver provided, this can also be done
on a Windows or Mac system.

My abstract user is someone using 3rd party library, and my approach
(maybe questionnable) is that user has start to think only when the
computer cannot think for her anymore, not any earlier

A JS programmer without a clue on JS is no JS programmer at all. Writing
a library that uses internal logic to counteract such incompetence on the
part of its user would be a recipe for disaster. More important, it cannot
be done since there is no difference between "c:abcde" and "c:\abcde" when
it comes to evaluation after which point the library would have to do
correction. Last but not least, there is no need for FAT/NTFS/UNC paths
on the Web as `file:' URIs serve their purpose.


PointedEars