Welcome!

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

SignUp Now!

Last call for v12 feature requests

On Tue, 04 May 2010 19:04:50 -0400, rconn <> wrote:

|p.s.: If you've already posted a suggestion, repeating it will *not* make it more likely to be adopted!

I think I've suggested this for the last several versions but not for v12. TCC:
please add a space after the first token on a command line is tab-completed (so
I don't have to type the space before entering args).
--
- Vince
 
If I repeat any of these, it's only because I do not know whether I've asked
for V12.

.) For DIR /S, have an option to gather all the files and display / sort
them in one list, instead of folder-by-folder.

2010-05-04 18:15 <DIR> sub1
2010-05-04 18:15 <DIR> sub2
2010-05-04 18:15 <DIR> subfolder3
2010-05-04 18:15 0 text0
2010-05-04 18:15 0 text1
2010-05-04 18:15 0 text1
2010-05-04 18:15 0 text2
2010-05-04 18:15 0 textfile3

.) For DIR (especially useful with /S), optionally show the relative or full
path for each filename:

2010-05-04 18:15 <DIR> sub1
2010-05-04 18:15 <DIR> sub2
2010-05-04 18:15 <DIR> subfolder3
2010-05-04 18:15 0 sub2\text0
2010-05-04 18:15 0 sub1\text1
2010-05-04 18:15 0 subfolder3\text1
2010-05-04 18:15 0 sub1\text2
2010-05-04 18:15 0 sub2\textfile3

or

2010-05-04 18:15 <DIR> D:\test\sub1
2010-05-04 18:15 <DIR> D:\test\sub2
2010-05-04 18:15 <DIR> D:\test\subfolder3
2010-05-04 18:15 0 D:\test\sub2\text0
2010-05-04 18:15 0 D:\test\sub1\text1
2010-05-04 18:15 0 D:\test\subfolder3\text1
2010-05-04 18:15 0 D:\test\sub1\text2
2010-05-04 18:15 0 D:\test\sub2\textfile3

.) For DIR, allow just the simple (RHSAD) attributes to be displayed. I
rarely care about the full /T options, but do use the RHSAD subset
regularly.

2010-05-04 18:15:18 0 ___A_ text1
2010-05-04 18:15:23 0 ___A_ text2

.) For DIR, allow filenames to be quoted. Or, just quoted if they contain
awkward characters.
2010-05-04 18:15 <DIR> "."
2010-05-04 18:15 <DIR> ".."
2010-05-04 18:15 <DIR> "sub1"
2010-05-04 18:15 <DIR> "sub2"
2010-05-04 18:15 <DIR> "subfolder3"


.) For DIR /S with paths, allow the filename portion to be aligned:
2010-05-04 18:15 <DIR> sub1
2010-05-04 18:15 <DIR> sub2
2010-05-04 18:15 <DIR> subfolder3
2010-05-04 18:15 0 sub2\text0
2010-05-04 18:15 0 sub1\text1
2010-05-04 18:15 0 subfolder3\text1
2010-05-04 18:15 0 sub1\text2
2010-05-04 18:15 0 sub2\textfile3

On Tue, May 4, 2010 at 4:04 PM, rconn <> wrote:


> I'm finalizing the feature list for v12. If you have suggestions, please
> post them here or in the Suggestions forum by the end of this week.
>
> Thanks!
>
> p.s.: If you've already posted a suggestion, repeating it will *not* make
> it more likely to be adopted!
>
>
>
>
>



--
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.
 
I'm finalizing the feature list for v12. If you have suggestions, please post them here or in the Suggestions forum by the end of this week.

I suppose you have kept a list of suggestions. Could you publish it (with no promises) so we could make comments?
 
Jim Cook wrote:
...
I concur in each and every one of Jim's suggestions.

Like Jim, I don't recall whether or not the suggestions below have been
previously requested for V12:

1/ provide all of the above for PDIR, too;

2/ in PDIR allow the user to specify the width of the size field to be
narrower than maximum width, as often one knows that a directory has no
large files, e.g. one dedicated to batch files;

3/ when size is reported, right justify the <DIR> and/or <JUNCTION> report
in the size column;

4/ when only basic attributes are reported (RHSAD) report junctions
(symbolic links) with the letter J or L in the same column as the D
attribute;

5/ new RANGE type: link count with same syntax as size ranges (the potential
performance penalty is worth it by reducing the processing time of the next
operation);

6/ extend the style of PDIR's file report syntax to FFIND. Reporting fields
relevant for FFIND would be file path (absolute or relative, as above), file
name, line number, matched line. If the match type is /T, an additional
option would be trimming.
--
Steve
 
On Tue, 04 May 2010 19:04:50 -0400, rconn <>
wrote Re [Support-t-1942] Last call for v12 feature requests:


>I'm finalizing the feature list for v12. If you have suggestions, please post them here or in the Suggestions forum by the end of this week.

Add a switch to the zip/unzip commands to 1) allow zip to copy a
file's descript.ion line to the zip file comment; and 1) allow unzip
to copy a ziped file's comment to descript.ion.
--
At first they laugh at you, then they ignore you, then they fight you, then you win.
 
My usual request:

Changing directory is reflected immediately in the directory stack and not when changing away.

Thanks

Stephen Howe
 
That's fine with me -- then will you please take my request list as requests
for PDIR?


On Wed, May 5, 2010 at 5:31 AM, rconn <> wrote:


> As I've said before, there is *no* chance of any new features being added
> to
> DIR, which has no switches available, and is by far the most complex
> command
> in TCC.
>
> Any additions will be made in PDIR.
>
> Rex Conn
> JP Software
>
>
>
>
>



--
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.
 
.) In TakeCommand, I would like a keyboard method for switching between
tabs. I'm not talking about the e.g. TCC/CMD windows (for which I use
Alt-Left/Right a LOT), but the toolbar tabs that include "Start a new
window" and "Send to the current tab", etc.

.) In TakeCommand, enable optional horizontal scrolling (like the console
handler for TCC does, with visible / buffer selections). Some of our
projects have link lines thousands of characters wide.

.) In TakeCommand tabs, allow the individual commands to be reordered. If I
add a new command, I'd like to group it where it belongs.

On Wed, May 5, 2010 at 6:38 AM, Jim Cook <> wrote:


> That's fine with me -- then will you please take my request list as
> requests
> for PDIR?
>
>
> On Wed, May 5, 2010 at 5:31 AM, rconn <> wrote:
>
>
>
> ---Quote---
> > As I've said before, there is *no* chance of any new features being added
> > to
> > DIR, which has no switches available, and is by far the most complex
> > command
> > in TCC.
> >
> > Any additions will be made in PDIR.
> >
> > Rex Conn
> > JP Software
> >
> >
> >
> >
> >
> ---End Quote---
>
>
> --
> 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.
>
>
>
>
>



--
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.
 
On Wed, 05 May 2010 08:01:11 -0400, Stephen Howe <> wrote:

|Changing directory is reflected immediately in the directory stack and not when changing away.

I'll second that.
--
- Vince
 
I have no idea if this is on the list or not. I'd like an easy way to
generate a list of files with a relative path.

Today I can do DIR /SB (or something similar) and get a list of full
pathnames. However, sometimes I want that list with the CWD portion
removed. I realize that I can use exisiting functions to create relative
paths, and that's easy enough inside a script. I'm more interested in
something at the command line.

This works today but is a bit clunky:
function foo=`.\%@right[-%@len[%_CWDS],%@unquote[%1]]`
pdir /s /a:-d /(@foo[*]) > clip:

It would be nice to do PDIR /SB (for example) and have it do the same
thing without the need for a function and all the extra switches.
Unfortunately, I do this infrequently enough that I can never remember the
syntax for PDIR and have to go spelunking through the help to relearn it.

-Scott


rconn <> wrote on 05/04/2010 07:04:49 PM:


> I'm finalizing the feature list for v12. If you have suggestions,
> please post them here or in the Suggestions forum by the end of this
week.

>
> Thanks!
>
> p.s.: If you've already posted a suggestion, repeating it will *not*
> make it more likely to be adopted!
>
>
>
>
 
Jim,

I use a tool called V - The file viewer. http://www.fileviewer.com
You can pipe output to it as well as have it display files. It works like
the built-in LIST function but does a whole lot more. You can dynamically
turn on/off word wrap based on window size or column.

It's one of those tools that after you start to use it you wonder how you
got along without it.

-Scott

Jim Cook <> wrote on 05/05/2010 10:03:30 AM:


> .) In TakeCommand, I would like a keyboard method for switching between
> tabs. I'm not talking about the e.g. TCC/CMD windows (for which I use
> Alt-Left/Right a LOT), but the toolbar tabs that include "Start a new
> window" and "Send to the current tab", etc.
>
> .) In TakeCommand, enable optional horizontal scrolling (like the
console

> handler for TCC does, with visible / buffer selections). Some of our
> projects have link lines thousands of characters wide.
>
> .) In TakeCommand tabs, allow the individual commands to be reordered.
If I

> add a new command, I'd like to group it where it belongs.
>
> On Wed, May 5, 2010 at 6:38 AM, Jim Cook <> wrote:
>
>
>
> ---Quote---
> > That's fine with me -- then will you please take my request list as
> > requests
> > for PDIR?
> >
> >
> > On Wed, May 5, 2010 at 5:31 AM, rconn <> wrote:
> >
> >
> >
> > ---Quote---
> > > As I've said before, there is *no* chance of any new features being
added

> > > to
> > > DIR, which has no switches available, and is by far the most complex
> > > command
> > > in TCC.
> > >
> > > Any additions will be made in PDIR.
> > >
> > > Rex Conn
> > > JP Software
> > >
> > >
> > >
> > >
> > >
> > ---End Quote---
> >
> >
> > --
> > 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.
> >
> >
> >
> >
> >
> ---End Quote---
>
>
> --
> 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.
>
>
>
>
 
|| Changing directory is reflected immediately in the directory stack
|| and not when changing away.
|
| I'll second that.

Not just in the directory stack, but also in directory history. AFAIK the
directory stack is not shared between TCC instances, but the directory
history, if it is global, is. This would make the current directory of each
instance available to all other instances immediately. One of the many
benefits is that when one instance writes a large file it is easy for
another instance to navigate to the same directory and use TAIL /F to watch
the output.
--
Steve
 
On Wed, May 5, 2010 at 7:30 AM, samintz <> wrote:


> I have no idea if this is on the list or not. I'd like an easy way to
> generate a list of files with a relative path.
>
> Today I can do DIR /SB (or something similar) and get a list of full
> pathnames. However, sometimes I want that list with the CWD portion
>

This is something I also find very useful, and I requested as well (for
PDIR). You might find my timedir at jcook.info/timedir app helpful for this
task. timedir /S /B /F:G will generate what you want.

--
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.
 
I meant the dirhistory.

On Wed, 05 May 2010 10:30:13 -0400, Steve Fábián <> wrote:

||| Changing directory is reflected immediately in the directory stack
||| and not when changing away.
||
|| I'll second that.
|
|Not just in the directory stack, but also in directory history. AFAIK the
|directory stack is not shared between TCC instances, but the directory
|history, if it is global, is. This would make the current directory of each
|instance available to all other instances immediately. One of the many
|benefits is that when one instance writes a large file it is easy for
|another instance to navigate to the same directory and use TAIL /F to watch
|the output.
--
- Vince
 
| I have no idea if this is on the list or not. I'd like an easy way
| to generate a list of files with a relative path.
...
| function foo=`.\%@right[-%@len[%_CWDS],%@unquote[%1]]`

My function is simpler:
function relpath=`%@replace[%_cwds,,%@path[%@full[%&]]]`

|
| It would be nice to do PDIR /SB (for example) and have it do the same
| thing without the need for a function and all the extra switches.
| Unfortunately, I do this infrequently enough that I can never
| remember the syntax for PDIR and have to go spelunking through the
| help to relearn it.

I have defined in a very systematic way aliases for a large number of PDIR
options and reporting formats. For example, appending the letter R at the
end of the alias means I want to recurse into subdirectories, reporting
paths relative to the _CWD of the start directory; L is recursion with long
(i.e., absolute) paths; neither L nor R that recursion and thus path
reporting are not desired.

Regardless, I would like two enhancements (which I probably requested):

1/ fr - relative path (without filename, combinable into frn for relative
path and name)

2/ using q instead of f, e.g., qrn, to return the string quoted when
necessary.
--
Steve
 
| ---Quote---
|| 2/ using q instead of f, e.g., qrn, to return the string quoted when
|| necessary.
| ---End Quote---
| Why don't you just use the existing q?


My fault - RTFM failure.
--
Steve
 
I like that - except for the use of @path and @full. The obvious
advantage of using @full is that you can pass just a filename, a full path
spec, or a relative path spec and still get a relative path spec out. In
my case I already knew that PDIR was generating full paths so I simplified
it.

function foo=`%@replace[%_CWDS,,%1]`
pdir /s /a:-d /(@foo[*])

The above generates a list of files from the current directory and all the
subdirectories using relative paths.

-Scott

Steve F$BaC(Bi$BaO(B <> wrote on 05/05/2010 12:05:50 PM:


> | function foo=`.\%@right[-%@len[%_CWDS],%@unquote[%1]]`
>
> My function is simpler:
> function relpath=`%@replace[%_cwds,,%@path[%@full[%&]]]`
>
>
>
 
I would second making LIST much more powerful.

- The ability to redefine additional list keys. up down, page up, etc.
The Navigation keys.
- Colorize within list based on file extension. Like many text editor (I
use vim)
- Preprocessing within LIST would be nice. So if you list a zip file, you
could pipe it through zip and list the files
- Mark locations within list and then be able to jump back and forth between
them.
- RegEx searches would be useful.

List is not broken now, but I think it could become very powerful. I use it
hundreds of times a day and the above are features I've wished it had many
times.

Michael


On Wed, May 5, 2010 at 9:30 AM, samintz <> wrote:


> Jim,
>
> I use a tool called V - The file viewer. http://www.fileviewer.com
> You can pipe output to it as well as have it display files. It works like
> the built-in LIST function but does a whole lot more. You can dynamically
> turn on/off word wrap based on window size or column.
>
> It's one of those tools that after you start to use it you wonder how you
> got along without it.
>
> -Scott
>
> Jim Cook <> wrote on 05/05/2010 10:03:30 AM:
>
>
> Quote:
> > .) In TakeCommand, I would like a keyboard method for switching
> between
> > tabs. I'm not talking about the e.g. TCC/CMD windows (for which I use
> > Alt-Left/Right a LOT), but the toolbar tabs that include "Start a new
> > window" and "Send to the current tab", etc.
> >
> > .) In TakeCommand, enable optional horizontal scrolling (like the
> console
>
> Quote:
> > handler for TCC does, with visible / buffer selections). Some of our
> > projects have link lines thousands of characters wide.
> >
> > .) In TakeCommand tabs, allow the individual commands to be reordered.
> If I
>
> Quote:
> > add a new command, I'd like to group it where it belongs.
> >
> > On Wed, May 5, 2010 at 6:38 AM, Jim Cook <> wrote:
> >
> >
> >
> > ---Quote---
> > > That's fine with me -- then will you please take my request list as
> > > requests
> > > for PDIR?
> > >
> > >
> > > On Wed, May 5, 2010 at 5:31 AM, rconn <> wrote:
> > >
> > >
> > >
> > > ---Quote---
> > > > As I've said before, there is *no* chance of any new features being
> added
>
> Quote:
> > > > to
> > > > DIR, which has no switches available, and is by far the most complex
> > > > command
> > > > in TCC.
> > > >
> > > > Any additions will be made in PDIR.
> > > >
> > > > Rex Conn
> > > > JP Software
> > > >
> > > >
> > > >
> > > >
> > > >
> > > ---End Quote---
> > >
> > >
> > > --
> > > 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.
> > >
> > >
> > >
> > >
> > >
> > ---End Quote---
> >
> >
> > --
> > 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.
> >
> >
> >
> >
>
>
>
 
The ability to display "x" number of lines around the "found" line in
FFIND. This feature is similiar to the Window parameter in OpenVms
Search command.

/win=(2,2) would mean 2 lines before and 2 lines after the found line.
 
I'd like to propose something that's probably unpopular:

Prune down the command switches to what's really useful and not easily
done with an alias, a function or short piece of batch code. I fear that
by now more users are intimidated by the complexness of TCC than are
drawn to it by its superior power.

Best Regards,

* Klaus Meinhard *
<www.4dos.info>
 
| I'd like to propose something that's probably unpopular:
|
| Prune down the command switches to what's really useful and not
| easily done with an alias, a function or short piece of batch code.

Unpopular because:

1/ Removes backward compatibility
2/ Reduces performance - aliases and functions are OK, but batch programs
are way slower than command option parsing

| I fear that
| by now more users are intimidated by the complexness of TCC than are
| drawn to it by its superior power.

Superior power is made possible only by complexity.

But wait... Rex has already done this! It's called TCC/LE!
--
Steve
 
For those rare occasions when I have to run a BAT script written by some
third party developer, 100% CMD compatibility is desired. Since this is
not possible due to the contrasting ways in which the parsers function, it
would be a really nifty feature to run the BAT script in CMD but have any
environment variables or directory changes propagated back to TCC. Changes
to TITLE would be a nice touch too.

I'm not exactly sure how this could be done, but here's an idea:

Since CMD will inherit the environment from TCC when launched we know what
the initial environment is and what the current drive/directory status is.
run the BAT script in CMD
compute a differences file with what changed in the environment and which
directories changed.
Apply those changes to TCC.

A function called SNAPSHOT could save an initial copy and a second call
could compute the delta.
TCC could invoke a BAT file by enveloping it inside another BAT/CMD file.

TCC would invoke the user script by: CMD /c Compatibility100.CMD
users.bat arg1 arg2 arg3...

Compatibility100.CMD:
TCC /c SNAPSHOT
call %*
TCC /c DELTA

-Scott
 
On Wed, 05 May 2010 15:42:17 -0400, samintz <> wrote:

|I'm not exactly sure how this could be done, but here's an idea:
|
|Since CMD will inherit the environment from TCC when launched we know what
|the initial environment is and what the current drive/directory status is.
|run the BAT script in CMD
|compute a differences file with what changed in the environment and which
|directories changed.
|Apply those changes to TCC.
|
|A function called SNAPSHOT could save an initial copy and a second call
|could compute the delta.
|TCC could invoke a BAT file by enveloping it inside another BAT/CMD file.

I have a plugin code that will examine/alter another process's environment. One
problem with such code as you suggest is that TCC won't know when to do it ...
when the child CMD is about to exit. Does anyine know if it's possible to
"hook" process-exit and have a chance to examine its environment before it
exits?

But if the batfile, run by CMD, saved a record (SET > file) just before exiting,
TCC could process the file. In fact the user could process such a file quite
easily.
--
- Vince
 
----- Original Message -----
From: "vefatica" <>
To: <[email protected]>
Sent: 2010. May 5., Wednesday 16.16
Subject: RE: [Support-t-1942] Last call for v12 feature requests



> On Wed, 05 May 2010 15:42:17 -0400, samintz <> wrote:
>
> |I'm not exactly sure how this could be done, but here's an idea:
> |
> |Since CMD will inherit the environment from TCC when launched we know
> what
> |the initial environment is and what the current drive/directory status
> is.
> |run the BAT script in CMD
> |compute a differences file with what changed in the environment and which
> |directories changed.
> |Apply those changes to TCC.
> |
> |A function called SNAPSHOT could save an initial copy and a second call
> |could compute the delta.
> |TCC could invoke a BAT file by enveloping it inside another BAT/CMD file.
>
> I have a plugin code that will examine/alter another process's
> environment. One
> problem with such code as you suggest is that TCC won't know when to do it
> ...
> when the child CMD is about to exit. Does anyine know if it's possible to
> "hook" process-exit and have a chance to examine its environment before it
> exits?
>
> But if the batfile, run by CMD, saved a record (SET > file) just before
> exiting,
> TCC could process the file. In fact the user could process such a file
> quite
> easily.

Vince, your last paragraph prescribes a simple method to achieve the OP's
goal. Save the TCC environment in a file, run CMD including saving the CMD
environment in another file. On return sort both files, compare the files
(using Charles Dye's @SAFEREAD function appears best as it is not affected
by special characters) a line at a time. For each change (new variable or
modified variable) pop up a MSGBOX and query the user whether or not to make
the change.
--
Steve
 

Similar threads

Back
Top