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

Suggestion: enhanced automatic quoting of filenames

Discussion in 'Support' started by Steve Fabian, Nov 18, 2009.

  1. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    Add options to DO and FOR to automatically quote the control variable when
    it is a file or directory name. Two modes: a/ always quote (provides more
    consistent string handling), b/ quote when needed, as if by @QUOTE[] (when
    the name is not parsed).

    Add optional parameter to functions which parse or process filenames (e.g.,
    @name, @ext, @lfn) to do the same.

    Add internal variables _cwdq and _cwdsq for like purpose.

    These new features would substantially reduce the development time of batch
    programs (and aliases) which process files. Admittedly, these features can
    be emulated already, but at much greater cost in batch file design time and
    complexity.
    --
    Steve
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,870
    Likes Received:
    83
    I believe I've mentioned a few dozen times that there is no chance of any additional options being added to FOR. (Not to mention the fact that it would seriously bend and/or break a lot of existing batch files that are already quoting the arguments -- and that you'd need the DWIM parser to automagically guess when you want it quoted and when you don't.)
     
  3. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    rconn wrote:
    | ---Quote (Originally by Steve Fbin)---
    || Add options to DO and FOR to automatically quote the control
    || variable when
    || it is a file or directory name. Two modes: a/ always quote (provides
    || more
    || consistent string handling), b/ quote when needed, as if by @QUOTE[]
    || (when the name is not parsed).
    | ---End Quote---
    |
    | I believe I've mentioned a few dozen times that there is no chance
    | of any additional options being added to FOR.

    I accept that FOR has so many options already that more cannot be added.
    I may forget this though.
    Strangely though FOR is the one where the feature is needed more,
    because in DO it is easy to add an extra SET command, but in FOR the extra
    command may make it necessary to use a command group instead of a plain
    command, or may necessitate repeated application. As an example:
    FOR %f in (...) copy %@quote[%f] %@replace[s,x,%@quote[%f]]

    | (Not to mention the
    | fact that it would seriously bend and/or break a lot of existing
    | batch files that are already quoting the arguments -- and that you'd
    | need the DWIM parser to automagically guess when you want it quoted
    | and when you don't.)

    Any new command features that are not default, but require the use of a
    new option to be activated are 99.99% backward compatible. The 0.01% is for
    coincidences - those users who created an alias (or batch file) with the
    same name as the command which parses the command dynamically for the
    specific option code. Likewise, any new command (or new internal variable or
    new function) may have a name already used by someone. This possible
    coincidence should not, and has never in the past did, stop adding new
    features. However, for the specific suggestion of added option to DO and FOR
    I cannot conceive that anybody would have created aliases or batch files
    named DO or FOR...
    As to when the value should be quoted and when not I think my suboptions
    are clear: a/ requires unconditional quoting; b/ requires the internal
    application of the logic used by the @QUOTE[] function. Selecting between
    none of the options, option a/ or option b/ is indeed DWIM - DWIM coding,
    that is. I must figure out what I need in the subsequent code, and tell the
    parser explicitly what it is to do. I am not asking the parser to do
    anything autonomously.
    --
    Steve
     

Share This Page