file path parsing for external program in 3.2.0

[obo78]

I previously had qBittorent run a simple explorer.exe /select, "D:/Download/_torrent downloads/%n" to open the file manager to the most recent file download location.  This worked fine until today when I upgraded to 3.2.0.  Now Explorer doesn't get fed the "D:/Download/_torrent downloads/%n" parameter correctly and it defaults to My Documents.

What has changed in 3.2.0 to cause this?  Is the file path parsing different?  I understand the differing uses of \ and / in Linux and Windows but qBittorent was able to parse this correctly prior to this version.

Any help will be greatly appreciated.

[obo78]

In playing with this a bit further I have come to believe that 3.2.0 is not parsing properly past the first space in a file or folder name.

I ran the following batch file as an external program on torrent completion with %f %n as command line parameters:

Code: Select all

@echo off
echo F= is %1
echo N= is %2

pause

Downloading a small book with the file name that starts "English How to Speak English Fluently..", I get the following echo from the batch file:

F= is D:/Download/_torrent
N= is downloads/

The %f parameter cuts off at the first space.  It looks like the "downloads/" in the %n parameter is coming from from the folder name after the first space.

Changing the download folder name to _torrentdownloads (eliminating the space) results in:

F= is D:/Download/_torrentdownloads
N= is English

Once the %f parameter gets the correct folder, the %n parameter only parses to the first space of the file name.

[ciaobaby]

In playing with this a bit further I have come to believe that 3.2.0 is not parsing properly past the first space in a file or folder name.

Nothing to do with qbittorrent not parsing spaces.

Spaces are ALWAYS used as a delimiter in command line operations and IF there MIGHT be a space in one of the parameters the WHOLE command should be enclosed in quote marks as in

Code: Select all

 "[command] this has a space" 

[obo78]

In playing with this a bit further I have come to believe that 3.2.0 is not parsing properly past the first space in a file or folder name.

Nothing to do with qbittorrent not parsing spaces.

Spaces are ALWAYS used as a delimiter in command line operations and IF there MIGHT be a space in one of the parameters the WHOLE command should be enclosed in quote marks as in

Code: Select all

 "[command] this has a space" 

Thanks ciaobaby, I appreciate the help.

I just tried enclosing the entire command in quotes as you suggested -  "explorer.exe /select, D:/Download/_torrentdownloads/%n" (Note I eliminated the space in the download folder name)
On completion of the download nothing ran at all.  Explorer did not even start.  I also tried enclosing the entire command in quotes and also the path parameter ("explorer.exe /select, "D:/Download/_torrentdownloads/%n"") - a belt and suspenders approach that didn't work either.  I remember that when I first applied this command I had to play around with the placement of the quotes before I got it to work.

Previous to 3.2.0 the command ran fine for over a year as I originally posted.  Running the command as I quoted originally above at least results in explorer.exe running, it just isn't getting the folder/file names as it did before.

Again, the syntax above worked fine until the first download after updating to 3.2.0. 

[ciaobaby]

(Note I eliminated the space in the download folder name)

Then you don't need quotes

or maybe just quotes around the variables, .... ... eg: command "%n" "%f"

[obo78]

(Note I eliminated the space in the download folder name)

Then you don't need quotes

or maybe just quotes around the variables, .... ... eg: command "%n" "%f"

That seems to have done the trick with a couple of changes.  Enclosing just the %n in quote now passes the entire file or folder name but it also includes the quotes. 

I'm now trying to do this with a batch file which at least gets me to my download folder so I only have to pass the file or folder name.  For testing it looks like this:

Code: Select all

explorer.exe /select,D:\Download\_torrentdownloads\%1

@echo off

echo N= is %1

pause

Without the %1 the %n wasn't included in the execution.  With the %1 I get the file name but it is enclosed in quotes.  Surprisingly that doesn't seem to matter.  I've trimmed the echo/pause out of the batch and it appears to work fine this way.

Thanks again for the assistance.

[ciaobaby]

Just to enlighten anyone else.

[language type="geekinese"]
The %1 in the processing script is used to represent the first (1st) parameter that is passed in the command line, so command "file name" " disc location" would mean that %1 == "file name" and %2 == "disc location". The more variables you pass, ...  the more %n's you need to collect them
[/language]