Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Done Miscellaneous suggestions

May
3,515
5
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
 
> 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

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.


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

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


> 3/ New suboption P for the ordering option /o: - ordering by pathname.

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!
:-)


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

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"?


> 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.

(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
 
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.

Is this feature documented in the Help? I'd like to use it, but I try to avoid using undocumented features.

SETDOS is obsolete and deprecated

Is this mentioned in the Help? Is there a list of deprecated features?
 
> ---Quote (Originally by rconn)---
> 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.
> ---End Quote---
> Is this feature documented in the Help? I'd like to use it, but I try
> to avoid using undocumented features.

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)?


> ---Quote (Originally by rconn)---
> SETDOS is obsolete and deprecated
> ---End Quote---
> Is this mentioned in the Help? Is there a list of deprecated features?

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
 
Is what documented? That ranges don't have to be the first argument (no, but neither does it say that they *do*) ...

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*?

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

Then I don't want or need a list. Thanks.
 
| ---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
 
> || 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.

So -- you want this one sort option instead of v12? (You cannot have both!)

Rex Conn
JP Software
 
| ---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
 
> | ---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?

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
 
| 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
 
> 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...

I was referring to /o:p. The /o:s option is worse.

Rex Conn
JP Software
 

Similar threads

Back
Top