Community

I'm trying to define a set of Clip Library inserts to build command prompt rename commands.

The clipping should wrap a rename command around the selection, so that starting with a selection -

BadOldFilename.ext

we end with -

rename c:\users\me\desktop\BadOldFilename.ext GoodNewFilenameMask.ext

TextPad lets me do that - until I save the .TCL file and restart.

After restart, editing the clipping shows no 'after' portion and the 'before' portion suffixed with debris followed by the former 'after' portion.

As a diagnostic, I replace the trailing backslash in the 'before' portion with a percent character. That survives .TCL save and restart and produces -

rename c:\users\me\desktop%BadOldFilename.ext GoodNewFilenameMask.ext

That works as intended, but isn't useful.

Question: Have I missed something about escaping trailing backslashes or do we have a more unpleasant issue involving .TCL file read parsing?

Note - I report the issue as observed in 7.5.1(32). The behavior in 7.6.4(32) might be marginally different, but still incorrect.

The backslash is most likely a control character instead of a literal one - in that case if you want to use a literal backslash you have to use two of them, i.e.

Thanks for the reply.

I've tried your suggestion, it does not circumvent the issue described.

It is not clear to me that you understand the issue. Your suggestion doubles all four backslashes in the 'before' part, but there is no issue with the first three. There is only an issue when the last character in the 'before' part is a backslash.

I've tried a 'before' part in the form -

rename c:\users\me\desktop\\

It didn't work for me. Before save and restart, it inserts both trailing backslashes, it does not un-escape the sequence. After save and restart the behavior is as previously described with the additional backslash.

Note that in the .TCL file the trailing backslash is adjacent to the 'hot spot' marker (which is: backslash caret: \^ ), so the .TCL file line is:

rename c:\users\me\desktop\\^ GoodNewFilenameMask.ext

The sequence, \\^, is why I'm inclined to wonder about a file read parse issue.

Thanks again,

Still lookin' for guidance..