REN bug

[nickles]

Using version 12.10-0.58 and trying to execute the below commands:

mkdir x
ren x "x [y]"

I receive the following error message:

TCC: (Sys) The system cannot find the file specified.
"E:\temp\down\x"

This doesn't happen for plain files:

> x
ren x "x [y]"

E:\temp\down\x -> E:\temp\down\x [y]
1 file renamed

nickles

 

[Charles Dye]

If you want to rename a directory and the new name contains wildcards, you'll have to use /S. See HELP REN for more info.

 

[vefatica]

See REN's "/S" option. Apparently it's seeing "[x]" as a wildcard.


On Sun, 27 Mar 2011 14:25:21 -0400, nickles <> wrote:

|Using version 12.10-0.58 and trying to execute the below commands:
|
|mkdir x
|ren x "x [y]"
|
|I receive the following error message:
|
|TCC: (Sys) The system cannot find the file specified.
| "E:\temp\down\x"
|
|This doesn't happen for plain files:
|
|> x
|ren x "x [y]"
|
|E:\temp\down\x -> E:\temp\down\x [y]
| 1 file renamed
|
|nickles

 

[nickles]

Which it shouldn't (as it isn't). It used to work in prior versions!

nickles

 

[rconn]

> Which it shouldn't (as it isn't). It used to work in prior versions!

Not in anything recent -- that code hasn't changed in at least a couple of
years. REN has *always* required a /S to rename directories, though
sometimes (but only recently) it is able to guess that you're trying to
rename a directory.

There's no way for the parser to automagically know whether you want []
characters to be wildcards or literal characters. See the help for REN when
renaming directories to targets with wildcards.

Rex Conn
JP Software

 

[Charles Dye]

On the other hand, bracket wildcards make no sense in REN's new_name parm anyway. Maybe COPY's target filename too, and a few other places? Perhaps in some future version, these commands could check only for simple wildcards (question marks and asterisks) in target parameters?

 

[nickles]

move works w/o problems.

Also, the behavior is inconsistent with renaming files (see first post).
Also - as I've used this exact syntax quite often before - I'm pretty sure (not keeping old versions) that it worked before 12.10.

nickles

 

[rconn]

move works w/o problems.

Also, the behavior is inconsistent with renaming files (see first post).
Also - as I've used this exact syntax quite often before - I'm pretty sure (not keeping old versions) that it worked before 12.10.

I tried it back on versions to 8.0 and it didn't work (as expected) without the /S option on any of them.

I suspect that either you had an alias in the past, or you weren't using the square brackets.

 

[nickles]

Also - because I used to rename files instead of directories - call me a blockhead ;-)

Sorry for that.

But - this behavior is not consistent with cmd and - from my point of view - generally "nasty" (as unexpected):

ren "some name" "some name [details]" would give my an error when being a directory, not however when being a file.

 

[rconn]

But - this behavior is not consistent with cmd and - from my point of view - generally "nasty" (as unexpected):

ren "some name" "some name [details]" would give my an error when being a directory, not however when being a file.

The only way to make it consistent with CMD would be to eliminate extended wildcards (which CMD doesn't support).

 

[CaesarR]

On Mon, 28 Mar 2011 17:35:33 -0400, rconn <>
wrote Re RE: [Support-t-2729] Re: REN bug:

>The only way to make it consistent with CMD would be to eliminate extended wildcards

Please don't do that.

>(which CMD doesn't support).

 

[nickles]

@rconn

Move uses these too, doesn't it?

Maybe there should be a switch allowing us to turn on/off extended wildcards?

Is there a setdos option?

nickles