1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Ren command confusion

Discussion in 'Support' started by myarmor, Feb 24, 2010.

  1. myarmor

    Joined:
    May 30, 2008
    Messages:
    65
    Likes Received:
    1
    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 "."?

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

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,277
    Likes Received:
    38
    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
    [*]"
    
     
  3. myarmor

    Joined:
    May 30, 2008
    Messages:
    65
    Likes Received:
    1
    Thanks..
    Well it does work, but somehow it feels like a workaround for a bug.
    I'll be using this for now.

    Regards
     
  4. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    | ---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
     
  5. myarmor

    Joined:
    May 30, 2008
    Messages:
    65
    Likes Received:
    1
    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:

    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.
     
  6. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    | 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
     
  7. myarmor

    Joined:
    May 30, 2008
    Messages:
    65
    Likes Received:
    1
    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.
     
  8. myarmor

    Joined:
    May 30, 2008
    Messages:
    65
    Likes Received:
    1
    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.
     
  9. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    605
    Likes Received:
    0
    On Thu, Feb 25, 2010 at 5:44 AM, Steve Fábián <> wrote:


    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.
     
  10. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    | 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
     
  11. myarmor

    Joined:
    May 30, 2008
    Messages:
    65
    Likes Received:
    1
    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.
     
  12. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    | ---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
     
  13. myarmor

    Joined:
    May 30, 2008
    Messages:
    65
    Likes Received:
    1
    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.
     
  14. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,730
    Likes Received:
    80
    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
     

Share This Page