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

Miscellaneous suggestions

Discussion in 'Suggestions' started by Steve Fabian, Mar 7, 2010.

  1. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    1/ Ranges

    1.1/ Order - Relax the requirement for range options to precede other
    options. While this is essentially implemented in V11, it would be nice for
    it to be generally applicable

    1.2/ Multiple ranges of a given type (e.g., multiple exclusion ranges) -
    currently cause errors. The options below would be useful:

    1.2.1/ Cumulative ranges - for example, many of my aliases which process
    hidden files contain /[!DESCRIPT.ION], disallowing me from adding additional
    file exclusions. This concept would also be useful for other ranges, e.g.,
    to look for files created within 10 min of either midnight or noon. A new
    syntax would be needed, e.g., /+[!*.tmp] to also exclude *.tmp files. The
    new syntax would guarantee backward compatibility.

    1.2.2/ Overriding range - this would result in handling ranges more like
    other options, where generally a second use of an option with different
    suboptions overrides earlier use, as is done with /a: and /o:

    2/ Extension of the "no junction" type iteration restrictions to all
    commands, e.g. FFIND and FOR.

    3/ New suboption P for the ordering option /o: - ordering by pathname. I
    realize this will delay command completion, but the delay should be less
    than that caused by the need to follow the command by an external sort
    utility, and in case of FFIND returning file contents, the ability to
    provide ordering by filenames including paths would eliminate the need for
    very sophisticated and much slower sorting.

    4/ Add /U unicode option to SETDOS to make switching between ASCII and
    Unicode easier

    5/ Add option to SETDOS to force command output case, e.g., /O:n - 0:mixed
    case, 1: lower case, 2: upper case. This option could be combined with the
    unicode option. The benefit of forcing case would be for output that needs
    to be sorted or searched.

    --
    Steve
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,722
    Likes Received:
    80
    It is already allowed, *unless* it's in a command where the order is
    essential (like DO or FOR), where it's necessary to determine to which
    command the ranges should apply.


    What's wrong with the existing /A:-J?


    This would require a parser rewrite, a complete rewrite of the file search
    code, and rewriting the argument handling for all file commands. Minimally
    10K lines of code, and probably 3-4 months - or roughly the amount of time
    it takes to write 300 new features and put out a major update. (And it
    definitely would *not* be faster than using an external sort utility.)

    Maybe not the most effort for least return ever, but it'd be a contender!
    :-)


    SETDOS is obsolete and deprecated, and I definitely will not be adding any
    new options to it. Why not just alias the "option //unicodeoutput=yes"?


    (1) See above, and (2) I have no idea what you're looking for here. Forcing
    case in what? If you want to convert STDOUT to upper or lower case for a
    specific purpose (though I have no idea *why* that would ever be necessary),
    you can write a 3-line filter and pipe the output to it.

    Rex Conn
    JP Software
     
  3. David Marcus

    Joined:
    Jun 4, 2008
    Messages:
    646
    Likes Received:
    1
    Is this feature documented in the Help? I'd like to use it, but I try to avoid using undocumented features.

    Is this mentioned in the Help? Is there a list of deprecated features?
     
  4. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,722
    Likes Received:
    80
    Is what documented? That ranges don't have to be the first argument (no,
    but neither does it say that they *do*), or that the order is significant in
    DO and FOR (yes)?


    It has been mentioned a few hundred times in the support forum.

    I had a list of deprecated features a while back, but it generated an
    enormous amount of support noise. Some users were unable to distinguish
    between "deprecated" and "I'm maliciously removing this feature in order to
    break all of your batch files and aliases". :-)

    Deprecated features (like SETDOS) will never, ever (ever, ever) be enhanced.
    They will not be removed.

    Rex Conn
    JP Software
     
  5. David Marcus

    Joined:
    Jun 4, 2008
    Messages:
    646
    Likes Received:
    1
    The "File Exclusion Ranges" page says, "When you use an exclusion range in a command it should immediately follow the command name."

    The "Ranges" page says, "When you use range specifications in a command, they should immediately follow the command name, so that any additional switches for the command are after any range(s) used. If the range is placed later in the command it may be ignored, or cause an error."

    Isn't that saying that they *do*?

    Then I don't want or need a list. Thanks.
     
  6. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    | ---Quote---
    || 2/ Extension of the "no junction" type iteration restrictions to all
    || commands, e.g. FFIND and FOR.
    | ---End Quote---
    | What's wrong with the existing /A:-J?

    It prevents listing the junction itself, but it does not prevent recursion
    INTO the junction, as the /NJ option does. However, I should have mentioned
    that /NJ would be relevant in FOR /R and FFIND /S only.

    || 3/ New suboption P for the ordering option /o: - ordering by
    || pathname.
    | ---End Quote---
    | This would require a parser rewrite, a complete rewrite of the file
    | search code, and rewriting the argument handling for all file
    | commands. Minimally 10K lines of code, and probably 3-4 months - or
    | roughly the amount of time
    | it takes to write 300 new features and put out a major update. (And
    | it definitely would *not* be faster than using an external sort
    | utility.)
    |
    | Maybe not the most effort for least return ever, but it'd be a
    | contender! :-)

    It could then be combined with other ordering codes, e.g., /o:p-sne.
    External sort to achieve the same would require either field separators or
    strict columnar alignment, and a sort utility which can locate the field
    separators or columns. Furthermore, the /O ordering does not require that
    the key field be actually present in the command output, but an external
    sort would. And think of ordering files and text lines from files found via
    FFIND - you would need to treat all lines of output from a single file as a
    single record for sorting. To achieve that goal in V11 I'd need to use FFIND
    or maybe PDIR to just return matching filenames, sort them in the desired
    order, and then use the result as an indirect file (@file)... oops, no,
    FFIND does not work with @file, so I would need to do something like this
    (all in one line, and real criteria instead of symbolic ones:

    pdir [file match criteria] /(fields in order needed for sorting) | sort |
    for %x in (@con) ffind [text match criteria] @filespec_from_line[%x]

    An alternative to /o:p would be to provide ordering that covers all files,
    regardless of their paths, when dealing with directory hierarchies.

    | ---Quote---
    || 4/ Add /U unicode option to SETDOS to make switching between ASCII
    || and Unicode easier
    | ---End Quote---
    | SETDOS is obsolete and deprecated, and I definitely will not be
    | adding any
    | new options to it. Why not just alias the "option
    | //unicodeoutput=yes"?

    I do have aliases uni*code and nou*incode. I think SETDOS (though you may
    deprecate it, many of us love it, or at least use it frequently) would be
    useful as it allows easily combining several changes into a single CONCISE
    command.

    | ---Quote---
    || 5/ Add option to SETDOS to force command output case, e.g., /O:n -
    || 0:mixed case, 1: lower case, 2: upper case. This option could be
    || combined with the unicode option. The benefit of forcing case would
    || be for output that needs to be sorted or searched.
    | ---End Quote---
    | (1) See above, and (2) I have no idea what you're looking for here.
    | Forcing case in what? If you want to convert STDOUT to upper or
    | lower case for a specific purpose (though I have no idea *why* that
    | would ever be necessary), you can write a 3-line filter and pipe the
    | output to it.

    I often pipe to the GNU "translate" program, aliased to "lc" (translate to
    lower case). I also have an alias "uc", which is rarely used. DIR has the /L
    option, which translates filenames to lower case, but not other fields. PDIR
    has no equivalent. Having a "setdos"-type option would eliminate the need to
    pipe. Many of the features you added since the first version of 4DOS
    provided nothing more than simpler or faster methods to achieve something
    the previous versions could already do. IMHO a major goal of every feature
    is to be able to do something SIMPLY, even if the same could be done without
    that feature. This set of options is in that category. And I just thought of
    another member of the same class: "invert case".
    --
    Steve
     
  7. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,722
    Likes Received:
    80
    So -- you want this one sort option instead of v12? (You cannot have both!)

    Rex Conn
    JP Software
     
  8. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    | ---Quote---
    || 3/ New suboption P for the ordering option /o: - ordering by
    || pathname.
    | ---End Quote---
    | So -- you want this one sort option instead of v12? (You cannot
    | have both!)

    Actually, it depends on what you plan for V12! Many other features have been
    requested for V12, so perhaps it could be planned for V13?

    BTW, having the output of a command sorted by fields not included in the
    output is something that cannot be done by postprocessing. To do it at all
    would require including all key fields in the output, sorting by the desired
    keys, then removing the unwanted keys from the sorted output.

    Having all of the output of commands like PDIR ordered as a unit, instead of
    subordering the sections from each subdirectory, is a request that has been
    made in the past more than once...
    --
    Steve
     
  9. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,722
    Likes Received:
    80
    I don't think you're quite grasping the issue here -- if I were to implement
    this feature, no other feature, from you, or anybody else, could also be
    implemented. Would you rather have this than 200 other features you've
    asked for? (The development time would be about the same; roughly 200 or
    300 other features to this one feature.)

    Would you be willing to pay for an upgrade that only had this one feature?
    And more to the point, would anybody else?

    In essence, this seems like an excellent way for me to go broke after
    spending months to develop something that only one person has ever asked
    for. (And even you only asked for it after using TCC for years, so you've
    apparently never had a compelling need!)

    Rex Conn
    JP Software
     
  10. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    | And even you only asked for it after using TCC for years, so
    | you've apparently never had a compelling need!

    In the /o:p form I never asked previously. In what is probably much more
    relaxed form, i.e., that ordering based on e.g. size or date when /S is also
    used would be for ALL entries, instead of ordering entries from each
    directory independently, is a request I have made in the past. As is many
    times I just specify /ou in PDIR, since I need to sort all results together,
    e.g., to find all identical files no matter where on the drive they are.

    | I don't think you're quite grasping the issue here -- if I were to
    implement this
    | feature, no other feature, from you, or anybody else, could also be
    | implemented. Would you rather have this than 200 other features you've
    | asked for? (The development time would be about the same; roughly 200 or
    | 300 other features to this one feature.)

    At this point I give up on /o:p. There are many other features of greater
    value for V12 and V13. I'd like a clarification however. When you refer to
    the magnitude of the task, are you referring to that of implementing /o:p,
    or are you referring to the ability of e.g. /o:s to order return values
    jointly from all paths, or is the task about the same for both alternatives?
    Just a WAG is OK...
    --
    Steve
     
  11. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,722
    Likes Received:
    80
    I was referring to /o:p. The /o:s option is worse.

    Rex Conn
    JP Software
     

Share This Page