Renaming bug?

[nickles]

How would I accomplish this (I assure you, this is a real-world problem here):

ren `"àsdf (%23%39).pdf"` <new_name>

where <new_name> should be (in this case):

àsdf (#9).pdf

I tried a lot of combinations (quoting with " ` ' @quote[], setdos /x-...) but to no avail.

How would I make a working command into a macro/function?

 

[rconn]

I don't think this constitutes a "bug" -- unless you can do it in CMD and you can't in TCC. (Or if the TCC documentation says it should work.)

REN is (severely) constrained by the requirements for compatibility with CMD, which limits the transformations you can make on the target name. Vince has a plugin that allows regex renaming (using a variable function); you might want to look into that.

 

[Charles Dye]

Here's another option that you can try if you wish:
http://www.unm.edu/~cdye/plugins/fixnames.html

 

[nickles]

@Rex

Sorry, I was a little unspecific. I wanted to express that the following commands were not working (and grab a solution for my problem):

ren `"àsdf (%23%39).pdf"` "%@urldecode[àsdf (%23%39).pdf]" => àsdf (39).pdf
ren `"àsdf (%23%39).pdf"` `"%@urldecode[àsdf (%23%39).pdf]"` => %@urldecode[àsdf (%23%39).pdf] (not coming as a surprise...)
ren `"àsdf (%23%39).pdf"` "%@urldecode[`àsdf (%23%39).pdf`]" => `àsdf (#9).pdf` (get rid of the backticks, and I'm fine!)
...

How would I use @urldecode[] with files named like the one above and produce the expected/correct/desired (àsdf (#9).pdf) result? How would I write a macro/alias? The problem lies in the parser's interpretation of the backtick characters (or in my inability to understand the quoting mechanism of TCC...).

@Charles

I'd like to go w/o any plugins as long as there is a chance to get "it" working with the means provided in TCC itself (this does not go against your plugin!). I simply feel that - at this point - TCC is not working correctly (a feeling btw, that never comes to me when working with bash or zsh - which have their issues as well...).

 

[Charles Dye]

@Charles

I'd like to go w/o any plugins as long as there is a chance to get "it" working with the means provided in TCC itself (this does not go against your plugin!).

I can certainly understand that; just wanted to present one possible approach.

 

[nickles]

Any chances to get this fixed?

 

[rconn]

It doesn't have anything to do with RENAME, it's not a bug, and it will not be "fixed" (it would break nested variable expansion and make it impossible to use variable arguments in variable functions).

Your first example:

ren `"àsdf (%23%39).pdf"` %@urldecode[àsdf (%23%39).pdf]
passes the string inside the @urldecode function back to the variable expansion parser before @urldecode sees it. So it is converted to:

ren `"àsdf (%23%39).pdf"` %@urldecode[àsdf (39).pdf]
before expanding @urldecode, and before REN sees it.

One simple workaround is:

ren `"àsdf (%23%39).pdf"` %@strip[^`,%@urldecode[`àsdf (%23%39).pdf`]]

 

[nickles]

Embracing %@strip[^`,%@urldecode[`àsdf (%23%39).pdf`]]" with "s (making it ren `"àsdf (%23%39).pdf"` "%@strip[^`,%@urldecode[`àsdf (%23%39).pdf`]]") actually works but this whole construct is pretty awkward.

How about changing the variable expansion parser to also accept []s for positional variables?
The following obviously already works:

set a=b
echo %[a]x
bx
echo %ax
ECHO is OFF

Doing so would let %23%39 go unchanged but %[2]3%[3]9 would get converted to 39 (like now). The whole rename thing would then become:

ren `"àsdf (%23%39).pdf"` "%@urldecode[àsdf (%23%39).pdf]"

EDIT Correction: ... Doing so would - obviously - change "%23%39" to ""! So - for positional variables a more sophisticated solution would be necessary like "if it's not embraced in []s and it's more than two digits wide let it go unchanged"...
--------------

Regardless of the above, could you please detail the exact sequence in which a command line is evaluated?

 

[rconn]

How about changing the variable expansion parser to also accept []s for positional variables?

That would require a major rewrite, and it would also break positional arguments > 9.

Regardless of the above, could you please detail the exact sequence in which a command line is evaluated?

It's documented in detail in the help; see "Command Parsing".

 

[nickles]

That would require a major rewrite, and it would also break positional arguments > 9.

I was afraid you would say that ;-)

It's documented in detail in the help; see "Command Parsing".

Thanks for the info.