Possible bug in {sourcepath} and spaces in 9.1.3

Help & Support
1

Hi,

Assume a command to compress files or folders placed in "D:\Mes Programmes" with 7zip such as:

@nodeselect @runonce "D:\Mes Programmes\Outils\7-ZIP\7zG.exe" a -r "{dlgchoose|Where?|Here={sourcepath}+Destination={destpath}}{dlgchoose|Archive name:|{file|noext}+{sourcepath|noterm|nopath}}" -mx9 {allfilepath$}

This worked nice in previous version but I recently noticed something weird in {sourcepath} behavior. When there is one or more spaces in a path, as in "D:\Mes Programmes" DOpus does this:

e.g. with {sourcepath|noterm|nopath}

(nom de l'archive is the french for archive name)

e.g. with just {sourcepath}

e.g. with {sourcepath|noterm}

As you can see there is leading and trailing weird character in the name and the archive produced with this name have no extension. Everything would be ok if the source path were "D:\MesProgrammes" (no space)

e.g. the file "toto.exe" is normally compressed as "toto.7z" but if there is space in the sourcepath it results just "toto"

2

[quote="fred"]
As you can see there is leading and trailing weird character in the name ...[/quote]

Maybe you already know this, but the "weird characters" should be quotes around parts of filenames containing spaces. I seem to get quotes here which makes me wonder if what you see is a bug in a French translation of Opus. Just guessing.

I can eliminate the quotes by adding @nofilenamequoting to the code. Maybe @nofilenamequoting would eliminate the "weird characters" and, if so, maybe the code would work. It seems to work the same for me either with or without @nofilenamequoting which surprises me, but haven't thoroughly analyzed why that would be the case.

3

Much of what I said in my previous post is wrong. I do get the "weird characters" at the beginning and end of {sourcepath}, but seemingly only when {sourcepath} is a choice within {dlgchoose}, not for usage of {sourcepath} in general. {destpath} has the same characteristics, so it appears the real problem may be with {dlgchoose}.

@nofilenamequoting does get rid of the "weird characters", but leads to other problems with the code.

4

[quote="rcoleman1943"]Much of what I said in my previous post is wrong. I do get the "weird characters" at the beginning and end of {sourcepath}, but seemingly only when {sourcepath} is a choice within {dlgchoose}, not for usage of {sourcepath} in general. {destpath} has the same characteristics, so it appears the real problem may be with {dlgchoose}.

@nofilenamequoting does get rid of the "weird characters", but leads to other problems with the code.[/quote]

Yes. For more details, here is my test with @nofilenamequoting

@nodeselect @nofilenamequoting @runonce "D:\Mes Programmes\Outils\7-ZIP\7zG.exe" a -r "{dlgchoose|Where?|Here={sourcepath}+Destination={destpath}}{dlgchoose|Archive Name:|{file|noext}+{sourcepath|noterm|nopath}}" -mx9 "{allfilepath$}"

I try to compress this pdf file D:\Docs Temp\Téléchargement direct.PDF in current folder.

indeed there are not weird characters anymore

but 7z can't correctly make an archive

error warning translation:incorrect syntax name of files or directories or disk

5

Add the quotes back into the command yourself.

@nofilenamequoting @set SomeVariable = {sourcepath} SomeCommand OPTION="{$SomeVariable}"

As a hard-fast rule, I always use @nofilenamequoting and add the quotes where I know they belong for the command in question.

6

[quote="kenalcock"]Add the quotes back into the command yourself.

@nofilenamequoting @set SomeVariable = {sourcepath} SomeCommand OPTION="{$SomeVariable}"
As a hard-fast rule, I always use @nofilenamequoting and add the quotes where I know they belong for the command in question.[/quote]

I did it in my previous post and it doesn't help in this case.

For now, this code is the best :

@nodeselect @runonce "D:\Mes Programmes\Outils\7-ZIP\7zG.exe" a -r "{dlgchoose|Where?|Here={sourcepath}+Destination={destpath}}{dlgchoose|Archive:|{file|noext}+{sourcepath|noterm|nopath}}" -mx9 {allfilepath$}
I get weird characters but at least I can compress multiple selected files in one archive. Adding @nofilenamequoting in this code makes 7zip unhappy because it detects an anomaly in :

@nofilenamequoting [bla bla bla] "{allfilepath$}"

indeed "{allfilepath$}" seems to return only the source drive letter [D:] (whithout backslash) instead of the all path [D:\allfilepath]. Though there is quotes around "{allfilepath$}" .

7

Add the quotes back into the command yourself.

@nofilenamequoting @set SomeVariable = {sourcepath} SomeCommand OPTION="{$SomeVariable}"

As a hard-fast rule, I always use @nofilenamequoting and add the quotes where I know they belong for the command in question.[/quote]

I know, but in the case at hand using @nofilenamequoting potentially caused no quoting of more than a single case of (sourcepath} and I hadn't attempted to figure out how compensate for the potential absence of quotes throughout the code given.

However, I think the whole problem has been diagnosed incorrectly. I installed 9.1.2.0. It also produces "weird characters", but, as far as I can tell, the only problem is that the display of the "weird characters" is, well, weird. They actually come out of {dlgchoose} as quotes. Pass the result of a similar {dlgchoose} to a batch file which echos its argument and you will see quotes.

So what is fred's real problem? I don't know, but unless I misunderstand, his code works OK for me.

His original post is made slightly confusing by his illustrating the "problem" using part of the path to his 7-zip.

I copied his code, changed it to reflect where I have 7-zip (C:\Program Files\7-Zip) and assigned the result to a key.

I then created a folder d:\Test Temp and put toto.exe in it.

With toto.exe selected, I press the key. I accept the default Here from the first {dlgchoose} dialog. The default archive name in the second dialog is toto. If I accept that, I get toto.7z in d:\Test Temp.

If, instead of accepting toto, I click the down arrow, I'm given a choice of Test Temp enclosed in "weird characters", but f I choose this, I get Test Temp.7z in d:\Test Temp. So apart from the admittedly weird display, I don't understand the problem.

As previously mentioned, I confirmed the weird display in 9.1.2.0 as well as 9.1.3.0, but the test just described involving toto,exe was performed on 9.1.3.0.

8

[quote="rcoleman1943"]If, instead of accepting toto, I click the down arrow, I'm given a choice of Test Temp enclosed in "weird characters", but f I choose this, I get Test Temp.7z in d:\Test Temp. So apart from the admittedly weird display, I don't understand the problem.
[/quote]

I partially take back what I said in first post about toto.exe, I prematurely concluded.

In fact, what I described occurs in special occasion. Let's me explain.

Assume you create a folder named "Shockwave Player 11.5" or even "Shockwave.Player" . Within it, create a test file e.g. toto.exe :smiley:

Let's run the command as you did it in your last post ie choose "here" then the 2nd choice with weird characters. It results an archive that's ok except it has no extension ie just named "Shockwave Player 11.5". In this particularly case, I have to manually add the "7z" extension.

Second to my tests it happens when there is a point in the archive name ie in the source path too.

I'm not sure it's due to DOpus, I think it's the way 7zip works with command and filename.

9

So is the only problem that quote characters appear strange (but are still really quotes in the command) in the {dlgchoose} drop-down?

Want to make sure I haven't missed any other issues that came out of this thread before I report anything to GPSoftware.

10

Well... I've already reported it :blush:

I confirm my last post : 7zip doesn't add "7z" extension if there is a point [.] in the name you give to the archive. DOpus is clear.

11

Thanks! Saves me doing it.

12

[quote="fred"]
Second to my tests it happens when there is a point in the archive name ie in the source path too.[/quote]

In the context of what's already been discussed, that statement (the "too") implies that you think the observed behavior is related to both spaces and dots (points) in the sourcepath.

Based on your following posts, you have probably come to the same conclusion, but I think what you observe (now known to not be an Opus problem) is related only dots/points. A sourcepath with spaces, but no dots/points doesn't seem to cause any problem except the dialog display problem.