Path Copy Copy

VanguardLH or any other users of this tool around please?

If so, anyone discovered an alternative since we discussed it in May
2017 ago in the thread:
Flaw in 'Copy Path'
about its failing when any file or path includes symbols like +.

I reported that at the time.

I've just installed what is apparently the latest version, 15.0, but see
that serious disadvantage remains.

Used to be so easy under XP.

Terry, East Grinstead, UK

Terry Pinnell wrote:

If so, anyone discovered an alternative since we discussed it in May
2017 ago in the thread:

Flaw in 'Copy Path'
about its failing when any file or path includes symbols like +.

I reported that at the time. I've just installed what is apparently
the latest version, 15.0, but see that serious disadvantage remains.

According to the release notes at:

https://github.com/clechasseur/pathc...ases/tag/v15.0
and
https://github.com/clechasseur/pathcopycopy/issues/11

version 15 should've been updated to support (escape) '+' characters in
a URI. Your bug ticket was referenced in the one above. Both were
closed. The author thinks he fixed it. Perhaps the author needs more
details an example URI, like OS, version, edition, file system, and the
steps to reproduce the problem. You might see if you can reopen your
ticket as "Not Fixed" or similar status.

VanguardLH wrote:

Terry Pinnell wrote:

If so, anyone discovered an alternative since we discussed it in May
2017 ago in the thread:

Flaw in 'Copy Path'
about its failing when any file or path includes symbols like +.

I reported that at the time. I've just installed what is apparently
the latest version, 15.0, but see that serious disadvantage remains.

According to the release notes at:

https://github.com/clechasseur/pathc...ases/tag/v15.0
and
https://github.com/clechasseur/pathcopycopy/issues/11

version 15 should've been updated to support (escape) '+' characters in
a URI. Your bug ticket was referenced in the one above. Both were
closed. The author thinks he fixed it. Perhaps the author needs more
details an example URI, like OS, version, edition, file system, and the
steps to reproduce the problem. You might see if you can reopen your
ticket as "Not Fixed" or similar status.

Just a thought: Since you are using the '+' character to represent a
aggregate of features (GPS and GPX), couldn't the '&' (ampersand)
character suffice for the same purpose? It would also need to be
escaped to prevent a parser from thinking you were trying to run
multiple commands in one command line (cmd1 & cmd2 = run cmd2 regardless
of return code from cmd1, cmd1 && cmd2 = run cmd2 only if return code
aka errorlevel is zero from cmd1, shown spaced but not required).

https://www.microsoft.com/resources/...loverview.mspx

Since '&' must be escaped (i.e,. '^&') in the submitted string (if not
double-quoted to delimit the string to a parser), maybe the author of
Path Copy Copy already figured out how to handle ampersands.

The author commented that he escaped (preceded with '^' character) the
'+' character when what he might need to do is delimit the string with
double quotes. In fact, in my batch files or registry entries that run
commands, I don't care if an argument does or doesn't need double
quoting (e.g., a path or filename might have spaces in it but might
not). I always double-quote when using the args passed into the .bat
file. They don't hurt but can save my butt if a later real use case
happens to contain spaces or other special characters in the input
argument.

I would think the Path Copy Copy author should be delimiting all
arguments with double quotes whether they have special characters in
them or not.

VanguardLH wrote:

VanguardLH wrote:

Terry Pinnell wrote:

If so, anyone discovered an alternative since we discussed it in May
2017 ago in the thread:

Flaw in 'Copy Path'
about its failing when any file or path includes symbols like +.

I reported that at the time. I've just installed what is apparently
the latest version, 15.0, but see that serious disadvantage remains.

According to the release notes at:

https://github.com/clechasseur/pathc...ases/tag/v15.0
and
https://github.com/clechasseur/pathcopycopy/issues/11

version 15 should've been updated to support (escape) '+' characters in
a URI. Your bug ticket was referenced in the one above. Both were
closed. The author thinks he fixed it. Perhaps the author needs more
details an example URI, like OS, version, edition, file system, and the
steps to reproduce the problem. You might see if you can reopen your
ticket as "Not Fixed" or similar status.

Just a thought: Since you are using the '+' character to represent a
aggregate of features (GPS and GPX), couldn't the '&' (ampersand)
character suffice for the same purpose? It would also need to be
escaped to prevent a parser from thinking you were trying to run
multiple commands in one command line (cmd1 & cmd2 = run cmd2 regardless
of return code from cmd1, cmd1 && cmd2 = run cmd2 only if return code
aka errorlevel is zero from cmd1, shown spaced but not required).

https://www.microsoft.com/resources/...loverview.mspx

Since '&' must be escaped (i.e,. '^&') in the submitted string (if not
double-quoted to delimit the string to a parser), maybe the author of
Path Copy Copy already figured out how to handle ampersands.

The author commented that he escaped (preceded with '^' character) the
'+' character when what he might need to do is delimit the string with
double quotes. In fact, in my batch files or registry entries that run
commands, I don't care if an argument does or doesn't need double
quoting (e.g., a path or filename might have spaces in it but might
not). I always double-quote when using the args passed into the .bat
file. They don't hurt but can save my butt if a later real use case
happens to contain spaces or other special characters in the input
argument.

I would think the Path Copy Copy author should be delimiting all
arguments with double quotes whether they have special characters in
them or not.

Thanks for that.

I re-installed, but no change.

Path Copy Internet Path works OK for this file:
C:\Users\terry\SnagIt Catalog\Symbols-1.png
file://terry-2016/Users/terry/SnagIt%20Catalog/Symbols-1.png

But this (with '+' in the path) fails:
C:\Users\terry\Dropbox\Excel+VBA (Sundry)\HyperlinkProblem-2.jpg
file://terry-2016/Users/terry/Dropbox/Excel+VBA%20(Sundry)/HyperlinkProblem-2.jpg

And so does this, with '+' in both filename and path:
D:\Pictures\PHOTOS\House+Garden\2000House+BMW.jpg
file://terry-2016/Pictures/PHOTOS/House+Garden/2000House+BMW.jpg

I expected to see some attempt to escape the plus signs?

I have several thousand files on my PC containing one or more plus signs
(excluding daily and weekly backups).

Terry, East Grinstead, UK