A "PDir" issue...

mathewsdw · 2011-10-02

For the first time in the 20 years plus that I've been using Take Command/TCC or one of its predecessors, I find I am actually teed-off, I think is the "polite" way to put it; and I don't really think that this is a "forum" issue, per se, but rather a significant bug report. And it isn't too complicated.

So here it is - the fairly simple and straightforward command:

Code:

PDir C:\Windows\winsxs\* /A-D /S /(-128.182fn zc dy/m/d th:m:s fp) | Sort >Z:\WinSXSFiles.txt

causes the TCC session in which it is issued to just terminate, period, end of sentence; no error message, no dialog box of any kind, nothing; just terminate without notice.

While there is data in "WinSXSFiles.txt", I don't know if it is, in fact, all of the data that should be there. I have tried this multiple times (including in "newly opened" TCC sessions), and the result is always the same. I will note that the "C:\Windows\winsxs" directory should presumably exist on all version(s) of Windows 7, at least, and therefore anyone running Windows 7 can, and is certainly welcome to, try it out on their own. (If their session doesn't just "disappear" (I'm not quite sure that "crash" is the right word in this circumstance since there doesn't seem to be any "evidence" of a "crash" left behind when this happens) that, in and of itself, will be useful information.)

I will add that this is not, by any means, the first time I've had this problem; it is just the first time that I can totally eliminate my bad memory, my partial blindness, a "mistake" of some kind that I made while writing a batch file, etc., etc., etc., although even if any of the previous things were applicable, TCC should still not just exit without notice. And as you can easily see from the previous, absolutely none of those things do or even can apply.

TCC 12.11.76 Windows 7 [Version 6.1.7601]

Charles Dye · 2011-10-02

It goes to completion here. Does it still gork for you if you do only the PDIR without the pipe and redirection? Have you tried starting TCC without the .INI file or TCSTART?

vefatica · 2011-10-02

On Sun, 02 Oct 2011 16:23:34 -0400, mathewsdw <> wrote:

|Code:
|---------
|PDir C:\Windows\winsxs\* /A-D /S /(-128.182fn zc dy/m/d th:m:s fp) | Sort >Z:\WinSXSFiles.txt
|---------
|causes the TCC session in which it is issued to just terminate, period, end of sentence; no error message, no dialog box of any kind, nothing; *just terminate* without notice.

It works fine here. What does "WHICH SORT" report?

mathewsdw · 2011-10-02

vefatica said:
On Sun, 02 Oct 2011 16:23:34 -0400, mathewsdw <> wrote:

|Code:
|---------
|PDir C:\Windows\winsxs\* /A-D /S /(-128.182fn zc dy/m/d th:m:s fp) | Sort >Z:\WinSXSFiles.txt
|---------
|causes the TCC session in which it is issued to just terminate, period, end of sentence; no error message, no dialog box of any kind, nothing; *just terminate* without notice.

It works fine here. What does "WHICH SORT" report?

Vince, "Which Sort" returns "sort is an external : C:\Windows\system32\sort.exe"

mathewsdw · 2011-10-02

Charles Dye said:
It goes to completion here. Does it still gork for you if you do only the PDIR without the pipe and redirection? Have you tried starting TCC without the .INI file or TCSTART?

Charles, no, and those are all very good suggestions; I will try them now.

So, #1, The PDir command by itself has not failed, but it has not yet finished either; for some strange reason it often pauses for 10 to 15 seconds (I timed one at about 15 seconds) at a time... Now it just finished (it took about 10 minutes), and did not fail when writing its output to the screen.

#2, Re-runing the PDir command again, this time redirecting its output to a file caused the TCC session in which it was just run to just terminate, again without notice. However, the "output" file (where the output of the PDir command was re-directed to) is 3,083,128 bytes, whereas the output of the "sort" command at the other end of the pipe in the original posting is only 559,945 bytes long, meaning the previous "final" output file is only 18% the size of the new "intermediate" file, so my suspicion that a substantial amount of data was missing was correct.

#3, Just to presumably eliminate this as a factor in the whole thing, my Z: drive (again, a RAM disk as has been previously mentioned in postings on this bulletin board) is 47.6% in use with 211,009,536 free, and those numbers are with both of the files mentioned in item #2 above still present. Clearly, "running out of space" is not an issue.

Well, since 3,083,128 bytes is far better than was 559,945 bytes, I can at least accomplish a significant portion of what I was trying to accomplish...

======================================================================

So "disabling" TCMD.INI (by renaming it to "TCMD.JNJ") and "disabling" TCSTART.btm (by renaming it to "TCStart.mtb" caused the PDir command to actually run to completion, the output file this time is 9,246,519 bytes, meaning the previously-mentioned output file as only 33% of the final output file.

The contents of TCMD.INI were:

Code:

[PopupFont]
Font=Lucida Console
Size=-27
Weight=400
Italic=0
Script=0
[4NT]
ProxyPort=80
FirewallType=None
FirewallPort=1080
PassiveFTP=Yes
FTPTimeout=180
HTTPTimeout=180
TFTPTimeout=180
MailPort=25
RLocalPort=0
SHLocalPort=0
SSHPort=22
SSLStartMode=0
SSLPort=0
AutoCancel=No
AutoCDD=Yes
AutoRun=Yes
BatchAliases=Yes
BatchEcho=Yes
CMDExtensions=No
CopyPrompt=Yes
DelayedExpansion=No
DelGlobalQuery=Yes
DirJunctions=Yes
DuplicateBugs=No
ExecWait=No
HistLogOn=No
LocalAliases=Yes
LocalDirHistory=Yes
LocalFunctions=Yes
LocalHistory=Yes
LogAll=No
LogOn=No
LogErrors=No
MouseWheel=No
NoClobber=Yes
PathExt=No
Perl=No
Python=No
RecycleBin=No
Rexx=No
Ruby=No
SettingChange=Yes
SHChangeNotify=Yes
Tcl=Yes
UnicodeOutput=No
UnixPaths=No
UpdateTitle=Yes
Win32SFNSearch=Yes
Wow64FsRedirection=Yes
ZoneId=0
ANSI=No
CDDWinLeft=20
CDDWinTop=20
CDDWinWidth=300
CDDWinHeight=140
PopupWinHeight=140
PopupWinTop=10
PopupWinLeft=40
PopupWinWidth=300
WindowHeight=0
WindowState=Standard
WindowWidth=0
WindowX=0
WindowY=0
Transparency=255
InactiveTransparency=255
AppendToDir=Yes
CompleteHiddenFiles=Yes
CompleteHiddenDirs=Yes
CompletePaths=Yes
CompletePercents=Yes
CursorIns=100
CursorOver=15
DirHistory=4096
DirHistoryOnEntry=No
EditMode=InitInsert
FuzzyCD=0
HistMin=0
History=20000
HistCase=No
HistCopy=No
HistDups=Last
HistMove=Yes
HistWrap=Yes
ServerCompletion=Local
AmPm=No
BeepFreq=440
BeepLength=2
CommandSep=&
DecimalChar=Auto
DescriptionMax=512
NTFSDescriptions=Yes
Descriptions=Yes
EscapeChar=^
EvalMax=14
EvalMin=0
ExpandPseudovariables=Yes
ParameterChar=$
RegularExpressions=Perl
SwitchChar=/
TabStops=8
ThousandsChar=Auto
[Font]
font=Lucida Console
size=-27
weight=400
italic=0
Script=0
[TakeCommand]
AlwaysOnTop=No
AppendToDir=Yes
CompleteHiddenFiles=Yes
CompleteHiddenDirs=Yes
CompletePaths=Yes
CompletePercents=Yes
IBeamCursor=No
InactiveTransparency=255
ServerCompletion=Local
SingleInstance=No
Transparency=255
Tray=No
WindowState=Standard
AutoAttachConsoles=No
ConsoleBufferRows=5000
IBeamCaret=No
LeftAltKey=Yes
LeftCtrlKey=No
RightAltKey=No
RightCtrlKey=No
SmoothScroll=No
StartTabWait=0
TabIcons=Yes
Tabs=Top
TabSize=20
TabRotation=No
TabX=Selected
AutoUpdateFolders=Yes
CloseIfNoTabs=Yes
ClosePrompt=No
DescriptionMax=512
Descriptions=Yes
LinuxSelection=No
LockExplorerBar=No
LockMenuBar=No
LockTabBar=No
MinimizeOnClose=No
MouseWheel=No
NTFSDescriptions=Yes
PathExt=No
RegularExpressions=Perl
SettingChange=Yes
SHChangeNotify=Yes
ShowHiddenFiles=Yes
ShowSysFiles=No
ShowSuperHidden=No
SingleClick=No
ShowExtensions=Yes
UpdateTitle=No
Wow64FsRedirection=Yes
ZoneId=0

And the contents of my TCSTART.btm file were:

Code:

@If %_Pipe != 0 .OR. %_Transient != 0 Quit
@CDD C:\
@CDD D:\
@CDD Z:\
@Alias /R D:\Dos\Alias.txt
@Function Link=`%@If["%@SymLink[%1]"=="",%@If["%@Junction[%1]"=="",^^<not a="" junction="" or="" symbolic="" link^^="">,%@Quote[%@Junction[%1]]],%@Quote[%@SymLink[%1]]]`
@Set TitlePrompt=PID %_PID
@CLS /C

To put it simply, because of my bad memory I know longer remember what changes (in any?) I made to TCMD.INI (last modified 9/26/2011). As far as TCSTART.btm goes, its contents are fairly simple and straightforward to understand...
</not>

rconn · 2011-10-02

> ---------
> PDir C:\Windows\winsxs\* /A-D /S /(-128.182fn zc dy/m/d th:m:s fp) |
> Sort >Z:\WinSXSFiles.txt
> ---------

Not reproducible here. First, try removing both the pipe and the
redirection. Then try just the pipe, and just the redirection.

Steve Fabian · 2011-10-02

From: mathewsdw
| Originally Posted by vefatica
| On Sun, 02 Oct 2011 16:23:34 -0400, mathewsdw <> wrote:
|
|| Code:
|| ---------
|| PDir C:\Windows\winsxs\* /A-D /S /(-128.182fn zc dy/m/d th:m:s fp) |
|| Sort >Z:\WinSXSFiles.txt ---------
|| causes the TCC session in which it is issued to just terminate,
|| period, end of sentence; no error message, no dialog box of any
|| kind, nothing; *just terminate* without notice.
|
| It works fine here. What does "WHICH SORT" report?
|
| Vince, "Which Sort" returns "sort is an external :
| C:\Windows\system32\sort.exe"

Two issues I see. One is probably a miscopy: 128.182fn - I presume it is intended to be either 128.128 or 182.182 ... The second: one of the posts reported "sort" as d:\gnu\sort.exe, the other a standard Windows sort. Possibly the piped-to session has a different PATH?
--
Steve

vefatica · 2011-10-02

On Sun, 02 Oct 2011 18:38:35 -0400, Steve Fabian <> wrote:

|The second: one of the posts reported "sort" as d:\gnu\sort.exe, the other a standard Windows sort. Possibly the piped-to session has a different PATH?

I had tried it with the Windows SORT.EXE first, then with Gnu SORT to see if it
made a difference. My mentioning Gnu SORT in another thread was entirely
coincidental.

mathewsdw · 2011-10-02

Steve Fabian said:
Two issues I see. One is probably a miscopy: 128.182fn - I presume it is intended to be either 128.128 or 182.182 ... The second: one of the posts reported "sort" as d:\gnu\sort.exe, the other a standard Windows sort. Possibly the piped-to session has a different PATH?
--

Steve

Steve, you were right, the first was a miscopy (sorry, transcriptions are one of my largest "error-modes"). As far as the second goes, no, the piped-to session absolutely does not have a "different" path (or at least it does not have one by any "mechanism" that I am aware of). But the bottom line is that Charles Dye made some suggestions traced to either of two possible sources: TCMD.INI or TCStart.btm. That was definitely an improvement (although I have no idea what any change in either file would have to do with it). And I have no clue whatsoever as to where you saw that "GNU" "sort" command, particularly since the "GNU" directory (yes, there is one) is not even in my path (or at least not now). And my path, for confirmation, is:

Code:

Z:;C:\Windows\System32;C:\Windows;D:\SysInternals;D:\DOS;C:\Windows\System32\WindowsPowerShell\v1.0;"C:\Program Files\Microsoft SQL Server\100\Tools\Binn";"C:\Program Files\Microsoft SQL Server\100\DTS\Binn";C:\Windows\System32\wbem;"C:\Program Files\QuickTime\QTSystem";"D:\Program Files - Junctioned to C Drive\Regular Expression Component Library Vc8\Dll";"D:\Program Files\Prio";"C:\Program Files\QuickTime\QTSystem"

I compared the path "as known" by a TCC session with the path that is stored in the registry (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Path), and they are, in fact, identical. (I will note that the GNU "sort" program on my machine is in ""\Program Files\GnuWin32\bin", which is not consistent with the output of the "which" command as you reported.)

Steve Fabian · 2011-10-02

From: mathewsdw
| (I will
| note that the GNU "sort" program on my machine is in ""\Program
| Files\GnuWin32\bin", which isn't consistent to the output of the
| "which" command which you reported.)

Sorry, I was confused. Vince Fatica used your PDIR command but with the GNU sort and reported a problem not related to your issue at all, it was not even in the same thread.

Regardless, on my system the help for the Microsoft SORT.EXE explicitly mentions that specifying the output file with the /O option is faster than redirection. See below. Since you are obviously dealing with large quantities of data you may find it better to do so.

/O[UTPUT] [drive:][path]filename
Specifies the file where the sorted input is to be stored. If not specified, the data is written to the standard output. Specifying the output file is faster than redirecting standard output to the same file.

I just remembered that I, too, had issues with PDIR quitting before all the matching entries were reported. IIRC the issue was some illegal filenames, or possibly extremely long ones - the latter issue had been improved in the latest build, V13 B24, through making TCC work even when there are problems in Windows.
--
Steve

Charles Dye · 2011-10-02

mathewsdw said:
So "disabling" TCMD.INI (by renaming it to "TCMD.JNJ") and "disabling" TCSTART.btm (by renaming it to "TCStart.mtb" caused the PDir command to actually run to completion, the output file this time is 9,246,519 bytes, meaning the previously-mentioned output file as only 33% of the final output file.

Then a next step would be to try the experiment with only the .INI file disabled, and then with only TCSTART disabled. Hopefully you can narrow the problem down to one or the other.

And then from there, comment out portions of the problematic file (REM in the batch file of course, or semicolon in the .INI file) to narrow it down. I admit that this is a slow, tedious, annoying process -- but if you can focus it down to one line, probably somebody else can reproduce the issue. (And even if nobody else can, narrowing it down to a single line may give Rex some insight into what's going on.)

P.S. My output file from that command weighs in at about nine million bytes too. So I guess that's a reasonable size.

Charles Dye · 2011-10-02

mathewsdw said:
... causes the TCC session in which it is issued to just terminate, period, end of sentence; no error message, no dialog box of any kind, nothing; just terminate without notice.

Oh yeah. Is a .GPF file being created in TCC's home directory?

mathewsdw · 2011-10-02

Steve Fabian said:
From: mathewsdw

Regardless, on my system the help for the Microsoft SORT.EXE explicitly mentions that specifying the output file with the /O option is faster than redirection. See below. Since you are obviously dealing with large quantities of data you may find it better to do so.

/O[UTPUT] [drive:][path]filename
Specifies the file where the sorted input is to be stored. If not specified, the data is written to the standard output. Specifying the output file is faster than redirecting standard output to the same file.

I just remembered that I, too, had issues with PDIR quitting before all the matching entries were reported. IIRC the issue was some illegal filenames, or possibly extremely long ones - the latter issue had been improved in the latest build, V13 B24, through making TCC work even when there are problems in Windows.
--
Steve

Steve, thank you for your input (and I had no clue about the "/O" and its effect in "speeding up" the sort; but since I never found the speed of the Windows built-in sort program to be an issue it is not something I would have "looked" for), but as it turns out the "sort" command had absolutely nothing to do with the problem (nor did "piping" per se) and Charles Dye suggested some things to try and, in fact, at least one those things (I really haven't "investigated" enough yet to know which one, and frankly since I am more interested in what I was trying to accomplish with the PDir command than in why it was crashing TCC at the present moment, it may be a while before I do any more "experimentation"), did, in fact, "fix" the problem. Rather than repeating all of that stuff here, I suggest you look at his positing (today, October 2, 2011, at 16:08) and my response to his posting (today at 17:31) to see where things now stand.

mathewsdw · 2011-10-03

<not a="" junction="" or="" symbolic="" link^^="">As a really quick update, I have had the time to do some more "experimentation" and it is definitely the TCMD.INI file and not the TCStart.btm file. I have to admit that I'm a little bit relieved in that the TCStart file is so simple and straightforward that it was hard to imagine that it was the problem; whereas the same was definitely not true (as far as I am concerned, at least) for the TCMD.INI file.

</not>

mathewsdw · 2011-10-03

After several hours of work, I was able to isolate the single line in TCC.ini that was causing TCC to consistently GPF (consistently because every time, absolutely no exceptions, that I start TCC with this line in the TCC.ini file and run the previously-mentioned command, it (silently) GPF's. Without this single line, absolutely no problem.

So what is this single line? Simple:

NTFSDescriptions=Yes

And I say "GPF" because there is a "GPF" file in my "AppData" directory ("C:\Users\MyUserId\AppData\Local\JPSoft"), which I had not noticed before (bad eyesight again as usual). I don't know how useful this is, but the contents of said GPF file are:

TCC 12.11.76
Module=D:\Program Files\JPSoft\TCMD12BuildLast\TakeCmd.dll
Address=1000637A
Exception=C0000005
EAX=0D430D88 EBX=7F4F0008 ECX=0D430D88 EDX=029A03E0
ESI=029AC760 EDI=00010000 EBP=01706A60 ESP=016FA9F0
CS=0000001B DS=00000023 ES=00000023 SS=00000023
Flags=00010206

Stack:
1 : TakeCmd.dll 00000001:0000537a
2 : TakeCmd.dll 00000001:0000ceb6
3 : TakeCmd.dll 00000001:0000a85e

And, just as a reminder, the command that is (absolutely consistently repeatably) causing TCC to crash is:

PDir C:\Windows\winsxs\* /A-D /S /(-128.128fn zc dy/m/d th:m:s fp) >AFile.txt

And, as always:

TCC 12.11.76 Windows 7 [Version 6.1.7601]

I can't think of anything else to add here...

vpdura · 2011-10-04

On Mon, 03 Oct 2011 23:54:48 -0400, mathewsdw <>
wrote Re RE: [Support-t-3255] Re: A "PDir" issue...:

>So what is this single line? Simple:
>
>NTFSDescriptions=Yes

How did you determine this?

mathewsdw · 2011-10-04

vpdura said:
On Mon, 03 Oct 2011 23:54:48 -0400, mathewsdw <>
wrote Re RE: [Support-t-3255] Re: A "PDir" issue...:
How did you determine this?

As I said in my posting, this took me several hours to accomplish.

First, I split the file TCMD.ini into 4 individual "sections", "[PopupFont]", "[4NT]", "[Font]", "[TakeCommand]", and tried the given "PDir" command with a TCC session started using a TCMD.ini file consisting of one, and only one, of those complete "sections". The only TCC session that "crashed" in this configuration was the TCC session that was using the TCMD.ini file containing the "[TakeCommand]" section, and only the "[TakeCommand]" section.

So I then essentially did a "binary" search. I "cut" out the second half of the file (again, the TCC.ini containing only the "[TakeCommand]" section), tested it, not bomb, added back one quarter of what I had cut out, tested it, if bombed, cut out the "last" 1/2 of the quarter (or 1/8th) of the file, if didn't bomb, cut out the "first" 1/8 of the file in the quarter that had been originally cut, if bombed, cut out the "last" 1/2 of the the 1/8th (or 1/16th of the file) that had been added...; and I repeated this sequence over and over and over until I had it (each iteration cutting and/or restoring fewer and fewer lines) down to only 1 line.

And finally, again after several hours of doing this (each individual test in the sequence took me between 5 and 10 minutes), I found that the line I reported caused the TCC session to "silently" GPF if present, and the "PDir" command successfully ran to completion if absent. As final test(s) to "confirm" my results, executing the "PDir" command with the original "total" TCC.ini file (containing all four "sections") caused a GPF, executing the "PDir" command with the original "total" TCC.ini file minus the "NTFSDescriptions=Yes" line caused the "PDir" command to run to completion without a GPF. And I executed the last two tests 4 or 5 times with always exactly the same results (i. e., it was totally and completely repeatable in all respects).

I have to say that, in all honestly, I don't really particularly care at this point in time whether or not anyone else in the world can repeat this problem, and that is because, for me, running without the "NTFSDescriptions" line (which I don't need anyway since I don't use NTFS "Descriptions") is not at all an issue. However, when I was a programmer type for about 30 years, I would want to know about any "crashes" that occurred in programs that I wrote; and I am sort of assuming that the same is true for Rex.

Search

Welcome!

A "PDir" issue...

mathewsdw

Charles Dye

Super Moderator

vefatica

mathewsdw

mathewsdw

rconn

Administrator

Steve Fabian

vefatica

mathewsdw

Steve Fabian

Charles Dye

Super Moderator

Charles Dye

Super Moderator

mathewsdw

mathewsdw

mathewsdw

vpdura

mathewsdw