Doubling backslashes in JavaScript - it's unorthodox, but it works...

I

indi

I've spent the last two hours trying every other solution listed, to
no avail: this works, so I'm sharing it for the other folks who
couldn't find a solution other than switching to another language.

var fileString = "\\mydev\folder\folder2\folder3\file.txt";

var myPat = /%5C/g; //this is using regular expression to
define the escaped version of a backslash

fileString = escape(fileString);
fileString = fileString.replace(myPat,"%5C%5C");
fileString = unescape(fileString);

fileString now equals "\\\\mydev\\folder\\folder2\\folder3\
\file.txt"

Hope this keeps someone else from pounding their heads against the
monitor. Enjoy!
 
G

Geoffrey Summerhayes

I've spent the last two hours trying every other solution listed, to
no avail: this works, so I'm sharing it for the other folks who
couldn't find a solution other than switching to another language.

var fileString = "\\mydev\folder\folder2\folder3\file.txt";

var myPat = /%5C/g; //this is using regular expression to
define the escaped version of a backslash

fileString = escape(fileString);
fileString = fileString.replace(myPat,"%5C%5C");
fileString = unescape(fileString);

fileString now equals "\\\\mydev\\folder\\folder2\\folder3\
\file.txt"

What browser? Did you try this?

fileString.replace(/\\/g,"\\\\");
 
R

ron.h.hall

Geoffrey Summerhayes said the following on 5/18/2007 3:40 AM:






var fileString = "c:\new folder";
fileString.replace(/\\/g,"\\\\");
alert(fileString)

Did *you* test it?

The first thing to note is that fileString, as you've presented,
doesn't actually contain a backslash at the time of the attempt to
perform replacement. That's because a backslash in a string literal is
an escape character. In this case, since the backslash precedes an
"n", it results in a newline character being generated when converting
the string to its internal form.

Also, you've used only a string replacement expression, without
assigning the result. Therefore the alert will present the string
without the effect of the replacement operation, i.e, a representation
of the original internal version.
 
R

ron.h.hall

(e-mail address removed) said the following on 5/19/2007 3:23 PM:





And testing, if not directly, would have indirectly caused that to be
discovered. If you alert fileString before the replace, the results
should make one wonder why before continuing.

Correct! Did *you* test it? ;-)
True, but, assigning it to another variable had no impact on what was
being written/alerted.

Agreed, but that's only because of the choice of the initial test
string that has no backslash to be replaced. It remains a faulty test
which is what I presumed it was to be.

<..>

The point is that

fileString.replace(/\\/g,"\\\\");

when assigned should give the desired result in a more direct fashion
than the process given by the OP. No?
 
G

Geoffrey Summerhayes

Geoffrey Summerhayes said the following on 5/18/2007 3:40 AM:



var fileString = "c:\new folder";
fileString.replace(/\\/g,"\\\\");
alert(fileString)

I wrote half a line of code and you
criticize it based on a half-built
test that is already fatally flawed
no matter what method you use, try:

var fileString = "file:\\\\c:\\new folder\\test\\";
alert(fileString); // print original string for comparison!!!
alert(fileString.replace(/\\/g,"\\\\"); // print result of replace
 
G

Geoffrey Summerhayes

Geoffrey Summerhayes said the following on 5/20/2007 4:28 PM:



That you didn't thoroughly test.

WTF? I'm sorry, when you were peering
over my shoulder, you should have said
something, I didn't see you here.
My test was very well thought out and designed to specifically show a
flaw in both approaches. Typically, when a string that contains a file
path needs to be escaped it is because it is not already escaped. If
that string comes from a file input (which some browsers won't let you
read the .value of), then you can not get back to the original if it
contains certain characters in it. My fileString was designed with that
in mind to show that it is not a trivial task.

Pfui. All your test showed was that the GIGO
rule still holds. Putting an alert box showing
the original string before processing would
have a more to the point, and a little more
intellectually honest, because it would have
shown that the input wasn't the *desired* path
string.
Why does that string need escaping though? It is already escaped.

Imprecise. It's escaped in the source only.
fileString will hold the unescaped string,
it's length will be 26 NOT 31.

Look, why have the replace in the first
place? Well, when I write a web page to
display HTML, I don't type <body>, I type
&lt;body&gt;. It displays properly, can be
cut and pasted from the page to an editor.
Do people write functions/regexps to do
this kind of translation? Sure.

The only credible reason for having this is
to create a string that can be eval'd or
cut-and-pasted into javascript source, or some
other language that follows the same escaping
rules. A poor man's *PRINT_READABLY* (Common
Lisp), specific to pathnames.

var foo="C:\\somepath";
var bar=eval("'"+foo+"'");
var baz=eval("'"+foo.replace(/\\/g,"\\\\")+"'");
alert('foo = bar: '+(foo==bar)+'\nfoo = baz: '+(foo==baz));

displays

foo = bar: false
foo = baz: true
It is easy to come up with a test case to show that a particular piece
of code will work. But, when that piece of code can be shown to be
flawed when presented with another piece of string code then the
original is still flawed.

As I said above, if you feed it junk, you
get junk back. That's not flaw in the tool,
it's a mistake on the user's part.
 

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top