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

A "PDir" issue...

Discussion in 'Support' started by mathewsdw, Oct 2, 2011.

  1. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    For the first time in the 20 years plus that I've been using Take Command/TCC or one of its predecessors<!--[if gte mso 9]><xml> <w:WordDocument> <w:View>Normal</w:View> <w:Zoom>0</w:Zoom> <w:PunctuationKerning/> <w:ValidateAgainstSchemas/> <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid> <w:IgnoreMixedContent>false</w:IgnoreMixedContent> <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText> <w:Compatibility> <w:BreakWrappedTables/> <w:SnapToGridInCell/> <w:WrapTextWithPunct/> <w:UseAsianBreakRules/> <w:DontGrowAutofit/> </w:Compatibility> <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel> </w:WordDocument> </xml><![endif]--><!--[if gte mso 9]><xml> <w:LatentStyles DefLockedState="false" LatentStyleCount="156"> </w:LatentStyles> </xml><![endif]--><!--[if gte mso 10]> <style> /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;} </style> <![endif]-->, 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]
     
  2. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,277
    Likes Received:
    38
    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?
     
  3. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,788
    Likes Received:
    29
    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?
     
  4. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    Vince, "Which Sort" returns "sort is an external : C:\Windows\system32\sort.exe"
     
  5. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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>
     
  6. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,730
    Likes Received:
    80
    Not reproducible here. First, try removing both the pipe and the
    redirection. Then try just the pipe, and just the redirection.
     
  7. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    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
     
  8. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,788
    Likes Received:
    29
    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.
     
  9. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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.)
     
  10. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    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
     
  11. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,277
    Likes Received:
    38
    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.
     
  12. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,277
    Likes Received:
    38
    Oh yeah. Is a .GPF file being created in TCC's home directory?
     
  13. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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.
     
  14. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    <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>
     
  15. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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...
     
  16. vpdura

    Joined:
    Jun 3, 2008
    Messages:
    27
    Likes Received:
    0
    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?
     
  17. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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.
     

Share This Page