REV 4932 snapins parameters with \ in command not correct in database

[Claude Girard]

@Claude-Girard said:

When arguments in snapins contains “”, they aren’t correctly saved in database.

Arghhh! I wrote \ but like in snapin it’s interpreted by HTML

[Tom Elliott]

I’m confused, what is the problem?

[Sebastian Roth]

Missing/double back slashes…?

[Claude Girard]

@Uncle-Frank said:

Missing/double back slashes…?

Yes back slashes are concerned.
Sorry for confusion but in my first message I wrote back slash between quotes and it disappeared from text.

You can see in screen captures:
Snapin run with: c:\program files\7-zip\7z.exe
That is before clicking update button.
In database, double back slashes

And after clicking update:
Snapin run with is transformed in: c:\program files-zipz.exe
Back slash and number 7 disappeared
And in database, only one back slash

[Tom Elliott]

I’ve added some code (add and strip slash functions) to the appropriate areas for display and push to the client. Please test and let me know if it is working properly.

Thank you,

[Claude Girard]

@Tom-Elliott Thank you but sorry, it doesn’t work.

After update, no modification of snapin, in database I had:
in snapin run with:
c:\\program files\\7-zip\\7z.exe
in snapin run with arguments:
e -y -o"E:\XPAresGACO1"

On display, I have:

If I delete and write again these lines:
Before validation:

After validation:

And in database, after validation:
in snapin run with:
c:\\program files\\7-zip\\7z.exe
(seems ok the same than at beginning)
in snapin run with arguments:
e -y -o\\\“E:\\XPAresGACO1\\\”
3 anti-slashes, then 2, then 3 !

And I understand that anti-slashes can disappear, but I don’t understand how number 7 can disappear from display

And from client:

In fog.log:

Real command in processes:

[Tom Elliott]

This is now fixed. I don’t think it’s perfect, but it should work a bit better now.

[Claude Girard]

@Tom-Elliott said:

This is now fixed. I don’t think it’s perfect, but it should work a bit better now.

Almost.

Really sorry Tom but now each time I click on update button without any change, one antislash is added in red areas in my screen capture (and two antislashes added in database for each click )
Only in “snapin run with arguments” (I hope …)

[tian]

@Tom-Elliott
at least in git5473 and git5483 the backslash update behavior described by Claude Girard happens to me in “Snapin Run With”.

I tried to remove all the backslashes and update - but it is getting more and more.

The weird thing is, that the snapin still runs fine on the client (0.9.7, git5483) even the client fog log shows all the backslashes in the “run with” path.

• Return code is 0
• snapin status is 4
• changes the batch file should do have been made

It still would be great to get rid of all the backslashes.

(fyi: in git 5473 return code of the same snapins was -1 and the client fog log missed all the backslashes at the “run with” path)

[tian]

@Tom-Elliott Thanks! It is working now.

In git5499 the saving/updating of the snapins in working again without adding more and more backslashes.

But the snapins only run ok after updating them. Even when the backslashes were displayed ok (with 1 backslash between folders and file) it seems to be necessary in my case:

• existing snapin with “run with”: c:\windows\system32\cmd.exe
  – exit code “-1”
  – from client log: “RunWith: c:windowssystem32cmd.exe”
• after updating the same snapin on the web interface (without changing anything)
  – exit code “0”
  – from client log: “RunWith: c:\windows\system32\cmd.exe”

[Tom Elliott]

@tian Some of the updating is kind of to be expected. It was literally adding more and more backslashes to the whole of the command. So, in some cases, the single backslash would remain, but depending on the following letters or characters \n \r \t \7 or any other slash statement would be literally interpreted to their respective escaped character (\n == newline, \t == tab, etc…)

To fix I have to escape all the characters especially those dealing with a backslash as a direct part. So this should be fixed and functional, though I’m sure there could be the potential for some funny things down the road (funny being I don’t know what to expect and maybe you won’t either).

[tian]

@Tom-Elliott Since I just use “c:\windows\system32\cmd.exe” in “run with” to run batch files there should be no surprises with other snapins for now.
And knowing the “workaround” to fix existing snapins (that won’t run) by simply updating them, there is no problem left at the moment related to this topic.