Ren command confusion

[myarmor]

Hello.. This may sound trivial, but usually one may rename files like this:

ren 09.* "test file.*"

and it would get the extension of the original.

However, try doing the same with (I've anonymized it, but same result):

ren 09.* "09 - x x. x. x, x. x! x x x, x. x.*"

Expected: The file is renamed to the new name with the previous file extension.
Actual Result: The extension is removed.

Is this correct behaviour, and if so, how would I else rename a file and still have the previous file extension when it contains "."?

Edit: the source filename in this case is simply 09.txt, but the extension can be anything (and is the reason for the .*)

 

[Charles Dye]

Hello.. This may sound trivial, but usually one may rename files like this:

ren 09.* "test file.*"

and it would get the extension of the original.

However, try doing the same with (I've anonymized it, but same result):

ren 09.* "09 - x x. x. x, x. x! x x x, x. x.*"

Expected: The file is renamed to the new name with the previous file extension.
Actual Result: The extension is removed.

Is this correct behaviour, and if so, how would I else rename a file and still have the previous file extension when it contains "."?

Edit: the source filename in this case is simply 09.txt, but the extension can be anything (and is the reason for the .*)

Looks like a good place to use delayed expansion:

ren 09.* "09 - x x. x. x, x. x! x x x, x. x.%%@ext
[*]"

 

[myarmor]

Looks like a good place to use delayed expansion:

ren 09.* "09 - x x. x. x, x. x! x x x, x. x.%%@ext
[*]"

Thanks..
Well it does work, but somehow it feels like a workaround for a bug.
I'll be using this for now.

Regards

 

[Steve Fabian]

| ---Quote (Originally by Charles Dye)---
|| Looks like a good place to use delayed expansion:
||
||
|| Code:
|| ---------
|| ren 09.* "09 - x x. x. x, x. x! x x x, x. x.%%@ext[*]"
|| ---------
| ---End Quote---
| Thanks..
| Well it does work, but somehow it feels like a workaround for a bug.
| I'll be using this for now.

It's more an issue of working around syntactic limitations. When there is
more than one period in a file specification, where does the "name" end, and
the "extension" begin? The concept of "name" and "extension" have been
blurred. TCC offers different methods to make the determination, one of
which happens to work for you. The alternate would be to use more elaborate,
but eeasier to understand parsing rules, e.g., regular expressions.
--
Steve

 

[myarmor]

It's more an issue of working around syntactic limitations. When there is
more than one period in a file specification, where does the "name" end, and
the "extension" begin? The concept of "name" and "extension" have been
blurred. TCC offers different methods to make the determination, one of
which happens to work for you. The alternate would be to use more elaborate,
but eeasier to understand parsing rules, e.g., regular expressions.
--
Steve

I thought this was more or less determined from the early beginning, in other words good old DOS.
In other words, the last extension (.xxx) is the actual extension.
If you have a file named "test.doc.exe", then it's obvious what windows would call the actual extension as assorted virii etc has utilized that particular behaviour.

I don't think I've ever seen a file where more than one "extension" was actually used, in other words that "filename.data.txt" and "filename.doc.txt" behaved differently.

If seen that way, not much has changed (except the length, and allowing "." as part of the actual filename).

Edit: By the way, the reason I find this looking like a bug is that in the documentation it says:

You can also use REN to rename a group of files that you specify with wildcards, as multiple files, or in an include list. When you do, the new_name must use one or more wildcards to show what part of each filename to change.

The source filename in this case has only one extension ".txt", using the wildcard 09.* with the targetfilename as above, indicating what part of the filename should be changed with the single star.
In this example there isn't much that could be interpreted differently as both source and target uses a single star, and the source has a single "." separating filename and extension.

Edit:

I guess I've found the reason why.. CMD exhibit the same behaviour as TCC in this case.
I guess this is one of the compatibility bugs (TCC has apparently several of those, but this one doesn't seem to be mentioned in the docs), but no way to turn it off.

 

[Steve Fabian]

| I thought this was more or less determined from the early beginning,
| in other words good old DOS.
| In other words, the last extension (.xxx) is the actual extension.
| If you have a file named "test.doc.exe", then it's obvious what
| windows would call the actual extension as assorted virii etc has
| utilized that particular behaviour.

MS changed the way the file system interprets filenames since the days
of PC-DOS/MS-DOS. Back then the filename "a*" meant any file without
extension, with the name starting with A. Now it includes files with
extensions. To specify "files without extension" you must use a terminal
period, e.g., "a*.". With this in mind, how would you parse the file
specification "a.b.c." into name and extension?
A corollary problem occurs when you use the "save as" feature of many MS
utilities, esp. those in MS Office - even though you specify an explicit
extension, e.g., abc.xxx, it appends the default extension of the selected
type behind the one you specified, e.g., abc.xxx.csv.

| I don't think I've ever seen a file where more than one "extension"
| was actually used, in other words "filename.data.txt" and
| "filename.doc.txt" behaves differently.

I never tried to use the ASSOC command with a period embedded in the middle
of the extension. However, my above example indicates that indeed MS
software generally considers the last period as the separator of the file
extension, as I think you meant above.

| If seen that way, not much has changed (except the length, and
| allowing "." as part of the actual filename).

... and the syntax needed for handling of extensionless file specifications.
--
Steve

 

[myarmor]

MS changed the way the file system interprets filenames since the days
of PC-DOS/MS-DOS. Back then the filename "a*" meant any file without
extension, with the name starting with A. Now it includes files with
extensions. To specify "files without extension" you must use a terminal
period, e.g., "a*.". With this in mind, how would you parse the file
specification "a.b.c." into name and extension?
A corollary problem occurs when you use the "save as" feature of many MS
utilities, esp. those in MS Office - even though you specify an explicit
extension, e.g., abc.xxx, it appends the default extension of the selected
type behind the one you specified, e.g., abc.xxx.csv.

| I don't think I've ever seen a file where more than one "extension"
| was actually used, in other words "filename.data.txt" and
| "filename.doc.txt" behaves differently.

I never tried to use the ASSOC command with a period embedded in the middle
of the extension. However, my above example indicates that indeed MS
software generally considers the last period as the separator of the file
extension, as I think you meant above.

| If seen that way, not much has changed (except the length, and
| allowing "." as part of the actual filename).

... and the syntax needed for handling of extensionless file specifications.
--
Steve

Yes, I forgot that part about how to specify extensionless files, although it doesn't apply in this case because it uses simple oldstyle wildcard which hasn't changed meaning since dos.

As for your example "a.b.c." I'd call it extensionless due to no chars after the final dot.
However, "a.b.c.*" (which would be similar to my initial question) isn't extensionless because of the wildcard after the final dot indicates so in both source and target.

 

[myarmor]

Just for the fun of it I tried creating an association for ".test.txt" (using regedit), setting it to use "htmlfile" as its handler.
I then doubleclicked "testing.test.txt".
It still opened editpad pro (which is my handler for .txt files), so the "after final dot" definition seems to stand.

 

[Jim Cook]

On Thu, Feb 25, 2010 at 5:44 AM, Steve Fábián <> wrote:

>
> I never tried to use the ASSOC command with a period embedded in the middle
> of the extension. However, my above example indicates that indeed MS
> software generally considers the last period as the separator of the file
> extension, as I think you meant above.
>
>

I just tested that, and whereas it appears to accept an embedded period, it
does not appear to pay any heed to it.

--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.

 

[Steve Fabian]

| Just for the fun of it I tried creating an association for
| ".test.txt", setting it to use "htmlfile" as its handler. I then
| doubleclicked "testing.test.txt".
| It still opened editpad pro (which is my handler for .txt files), so
| the "after final dot" definition seems to stand.

Just for fun try
ASSOC .txt.test=htmlfile
and see what happens.
--
Steve

 

[myarmor]

Just for fun try
ASSOC .txt.test=htmlfile
and see what happens.
--
Steve

The result actually seems to confirm the "after last dot definition" (at least in W7).
Adding that extension, then trying to execute a file named "funny.txt.test" won't try to run any application (even though both "extensions" are present) but instead opens the "Open with" thingy.
I did check the validity of the created registry key before doing the above.

 

[Steve Fabian]

| ---Quote (Originally by Steve Fbin)---
|| Just for fun try
|| ASSOC .txt.test=htmlfile
|| and see what happens.
| ---End Quote---
| This actually seems to confirm the "after last dot definition".
| Adding that extension, then trying to execute a file named
| "funny.txt.test" won't try to run any application (even though both
| "extensions" are present).

In other words, the Windows "association" and the TCC function @ext[] use
the same parsing rules, which is the expected good news.
--
Steve

 

[myarmor]

In other words, the Windows "association" and the TCC function @ext[] use
the same parsing rules, which is the expected good news.
--
Steve

True, but currently REN doesn't.
Whether it should copy the CMD (most likely) bug or not as it does now, that's another question.

 

[rconn]

> ---Quote (Originally by myarmor)---
> Hello.. This may sound trivial, but usually one may rename files like
> this:
>
> Code:
> ---------
> ren 09.* "test file.*"
> ---------
> and it would get the extension of the original.
>
> However, try doing the same with (I've anonymized it, but same result):
>
> Code:
> ---------
> ren 09.* "09 - x x. x. x, x. x! x x x, x. x.*"
> ---------
> Expected: The file is renamed to the new name with the previous file
> extension.
> Actual Result: The extension is removed.
>
> Is this correct behaviour, and if so, how would I else rename a file
> and still have the previous file extension when it contains "."?

It may not be the "correct behavior", but it's the "CMD compatible
behavior". REN in CMD is severely wildcard-challenged; fortunately there's
a number of other ways to accomplish this in TCC using variable functions.

Rex Conn
JP Software