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

Occasional COLORDIR issue

Discussion in 'Support' started by Jim Cook, Mar 2, 2009.

  1. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    Every now and then, I notice that my directories no longer conform to
    the COLORDIR variable.

    Just today I figured out why. The COLORDIR variable becomes corrupted
    by repeating the variable name.

    E.g.:

    Originally:
    D:\>echo %COLORDIR
    DIRS:Bright White;c h :Bright Green

    Occasionally:
    D:\>echo %COLORDIR
    COLORDIR=DIRS:Bright White;c h :Bright Green


    Notice that the second one mistakenly has "COLORDIR=" as part of the value.

    I believe I've seen this in both V9 and certainly in 10.00.57

    Once I noticed that problem, I used the following search to see of
    there were others, and TreeExclude was similarly messed up.

    *set | *ffind /m /k /v /e"^(?i)(.*?=)\1"

    Has anyone else seen an occasional mangling of some environment
    variables in a long running TCC box?

    I am certain that I do not modify COLORDIR and TreeExclude, except in
    my TCSTART.BTM where I simply say

    SET COLORDIR=DIRS:Bright White;c cpp h sr sg pro equ inc asm ob? bas
    psm pin asi uas uin ?ob :Bright Green ;??v vcs :Green ;qqq :Bright
    White on Red;hp ini me txt pdf doc man his cnf dc cli wp* htm* :Bright
    Cyan ;exe com bat btm pl cmd pdb prc :Bright Red; gz z tar zip 7z lzh
    arj arc pak zoo lzw :Bright Yellow ;bak &* TMP :Black on Cyan

    TreeExclude=C:\RAM;D:\;C:\TEMP;G:\;C:\DEVELOP2;C:\DEVELOP3;\\SVPROG\;N:\;M:\;Q:\;Y:\;U:\;Z:\;\\*\*;C:\Documents
    and Settings\Cookie\Local Settings\Application Data\JPSoft\Archive

    I do not yet know what stimulates the problem.

    --
    Jim Cook
    2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Sunday.
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,090
    Likes Received:
    85
    Jim Cook wrote:

    Not reproducible here.

    TCC sets and gets environment variables using the Windows API calls, so
    this would necessitate either something on your end resetting the
    variable, or a Windows bug.

    When you see the corrupted variables, is the only problem that the name
    is returned with the value? (I.e., if you do a SET, is there any other
    corruption? What does a "set colordir" display?

    Rex Conn
    JP Software
     
  3. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    I believe the only corruption is that the name is returned with the
    value. It happens very rarely, but now that I know what to look for, I
    may be able to find out what is doing it.

    On Mon, Mar 2, 2009 at 3:12 PM, rconn <> wrote:



    --
    Jim Cook
    2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Sunday.
     
  4. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,372
    Likes Received:
    40
    A hasty copy-and-paste from the screen buffer into ESET, perhaps?
     
  5. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    I would happily admit to blowing ESET in this case, but I never do
    that to these variables. I used it a lot in other places, but just
    never for either COLORDIR or TreeExclude, both of which I know got
    goofed up by the time I was diagnosing my current trouble.

    Thanks for the suggestion -- I'm willing to entertain any others people have.

    On Mon, Mar 2, 2009 at 4:04 PM, Charles Dye <> wrote:

     
  6. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,090
    Likes Received:
    85
    Jim Cook wrote:

    You can also set COLORDIR in TCMD.INI. Try setting it there and see if
    it eventually reappears in your environment in the invalid form.

    Rex Conn
    JP Software
     
  7. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    Solved!!

    I found that in my Control panel system variable, I had COLORDIR
    defined badly -- with the duplicated bit.

    Since my TCSTART overwrote it, I rarely saw the problem.

    Now, I'm using an executable extension for .PL:

    SET .PL=<path>perl.exe

    When I would type MYSCRIPT.PL, it would overwrite my current
    environment from the control panel setting.

    Now the question, is why does my environment get changed when I use an
    executable extension? I don't believe it should.

    On Tue, Mar 3, 2009 at 6:17 PM, rconn <> wrote:



    --
    Jim Cook
    2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Sunday.
     
  8. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    It looks like the .PL environment variable is not required. If I
    reduce my PATH enough, I'll get this error message:

    TCC: (Sys) DLL not found: perl58.dll

    Then, putting my R:\PERL\BIN into the path, when I run HELLOWORLD.PL I
    will get the message displayed, and then my environment variables are
    reloaded from the Control Panel settings.

    perl -v returns in part:
    This is perl, v5.8.0 built for MSWin32-x86-multi-thread

    On Wed, Mar 4, 2009 at 9:29 AM, Jim Cook <jimrcook@gmail.com> wrote:



    --
    Jim Cook
    2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Sunday.
     
  9. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    One more piece of information: It appears that Option must have
    Scripting \ Perl checked.

    On Wed, Mar 4, 2009 at 10:00 AM, Jim Cook <> wrote:



    --
    Jim Cook
    2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Sunday.
     
  10. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,203
    Likes Received:
    11
    Jim,

    You haven't been real clear on what you're doing vs. the outcome. As I
    understand it, you were seeing a variable with an extra var= in its
    defintion.

    e.g. COLORDIR=COLORDIR=blah blah blah

    What do you mean by "Control Panel settings?"

    Do you mean the entries stored in the following registry locations?
    HKLM\System\CurrentControlSet\Control\Session Manager\Environment
    HKCU\Environment
    HKCU\Volatile Environment

    Why did you have to "reduce your PATH?"

    And after HELLOWORLD.PL runs and you get back your prompt, your
    environment has changed?

    What does "WHICH HELLOWORD.PL" return?

    If you run "TASKLIST tcc" before and after you run HELLOWORD do you get
    the same number of instances of TCC running?

    -Scott

    Jim Cook <> wrote on 03/04/2009 01:00:31 PM:


    to

    if

     
  11. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    TCC 10.00.57 Windows XP [Version 5.1.2600]
    TCC Build 57 Windows XP Build 2600 Service Pack 3

    Problem also in 9.02.154 at least.

    On Wed, Mar 4, 2009 at 11:40 AM, samintz <> wrote:

    Yes. That's exactly the symptom.


    I'm sorry for the lack of clarity -- I left out too much in the
    interest of brevity.

    "Control Panel Settings" meant clicking Control Panel \ Performance
    and Maintenance \ System \ Advanced tab \ Environment Variables button
    \ System variables section. Also the User variables section.

    The information there is the same as returned by TCC's internal
    commands SET /S and SET /U.


    I "reduced the path" for two reasons.

    1) To remove my own perl installation from the path.
    2) To make an easily identifiable visible difference in case the PATH
    were changed.

    After I removed my own perl installation, I saw that TCC was trying to
    load the DLL from my perl installation, according to the error
    message.


    Yes. Typing PATH both before and after gives radically different
    results. Before, it is the reduction that I manually performed. After,
    it was reloaded as if from the SET /U and SET /S PATH variables.


    helloworld.pl is an external: <currentfolder>helloworld.pl


    I'm using both 4NT.EXE and TCC.EXE. So, I ran both TASKLIST 4NT and
    TASKLIST TCC and got exactly the same results before running and after
    running.


    Thanks for your efforts, Scott.

    --
    Jim Cook
    2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Sunday.
     
  12. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,203
    Likes Received:
    11
    One last thing. When you run OPTION and select the Startup tab. Is
    "Update Environment on System Change" checked or unchecked?

    -Scott

    Jim Cook <> wrote on 03/04/2009 03:51:03 PM:


    get

     
  13. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    No. It is not checked.


    On Wed, Mar 4, 2009 at 1:13 PM, samintz <> wrote:



    --
    Jim Cook
    2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Sunday.
     
  14. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,090
    Likes Received:
    85
    Jim Cook wrote:

    >

    It won't be. The only things that can cause the environment to be
    updated are an explicit SET, or if the SettingChange .INI directive is
    set. (Note that this can be in TCMD and/or TCC.)

    So either your Perl script or Perl itself is triggering that.

    Rex Conn
    JP Software
     
  15. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,090
    Likes Received:
    85
    Jim Cook wrote:

    Note that there are two ways you could be executing Perl -- by setting
    the Perl scripting option in TCC (which would result in TCC
    automatically calling the perl58.dll), or by using an executable
    extension & calling the Perl executable. You should never try to do both!

    Rex Conn
    JP Software
     
  16. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    The perl script purely says print 'hello world', so I don't believe
    it's that. The perl dll is being loaded by TCC (I believe based on
    your statements and my check boxes) and if the dll is modifying my
    environment, then that's certainly a bug inside perl.

    However, if I type "perl test.pl" then the environment is not modified.
    If I type "test.pl" then the environment IS modified.

    I removed my .PL executable extension and the problem remains. If I
    have both perl scripting checked, and a .PL environment variable,
    which will actually happen?

    I have perl scripting checked in TCC / Option.

    I do not have Update Environment on System Change in either TCC or TCMD.

    To try a bare-bones test, I removed my TCSTART.BTM and TCMD.INI and
    replaced them with empty files. Then, I used OPTION to check Perl
    scripting and remove all other scripting checks. I closed TCC then
    used Start \ Run to launch TCC again. With that setup I continue to
    get the problem only when running "test.pl" and not running "perl
    test.pl". I have no aliases or functions defined.

    Could the perl dll really be changing TCC's environment?

    The effect that I see is variables in the Control Panel \ System \
    Advanced \ Environment replace whatever values I have in my current
    environment.

    In fact, if I type "UNSET *" and add only my perl installation to my
    path, once I type "test.pl" then my environment gets reloaded with all
    the variables. I presume others have tested this and found no trouble.

    We have two different machines, running two different versions of
    perl, and they both do the same thing.

    Is there anything else I can look at to test this? Where's a perl dll
    that is blessed by JPSoft? The way I built perl is by downloading the
    sources and compiling, as suggested by cpan.

    --
    Jim Cook
    2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Sunday.
     
  17. vefatica

    Joined:
    May 20, 2008
    Messages:
    8,129
    Likes Received:
    33
    On Thu, 05 Mar 2009 10:47:51 -0600, Jim Cook <> wrote:

    |Could the perl dll really be changing TCC's environment?

    Sure, if you're using the built-in Perl support. If TCC loads the Perl DLL then
    anything that DLL does happens inside the TCC process. It's just like a plugin
    modifying TCC's environment.
    --
    - Vince
     
  18. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    10,090
    Likes Received:
    85
    Remember that if you're running Perl via the internal support in TCC, that the Perl dll is running in the same address space as TCC, so it's definitely capable of accessing and rewriting the environment used by TCC. This is normally a feature, as it allows Perl & TCC to share environment variables. If you do *not* want this behavior, disable the internal Perl support and invoke Perl scripts with the extern Perl.exe.

    The Perl we've tested TCC with is the ActiveState Perl, which is already pre-built for Windows.
     
  19. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    On Thu, Mar 5, 2009 at 9:32 AM, vefatica <> wrote:

    I realized that I was ambiguous after I sent the message. Clearly, as
    you and Rex point out, the dll is in the same process and has the
    ability.

    I just can't imagine that the perl dll _would_ be coded to overwrite
    my entire environment from the default system settings.

    --
    Jim Cook
    2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Sunday.
     
  20. vefatica

    Joined:
    May 20, 2008
    Messages:
    8,129
    Likes Received:
    33
    On Thu, 05 Mar 2009 11:57:42 -0600, Jim Cook <> wrote:

    |I just can't imagine that the perl dll _would_ be coded to overwrite
    |my entire environment from the default system settings.

    There are other cases where perl58.dll does some strange things when embedded
    ... for example, calling ExitProcess() on an interrupt. It's quite likely that
    any manipulations of the environment (if it does any) are quite in keeping with
    being loaded by perl.exe.

    You said you built it. Have you tried to find such a manipulation of the
    environment in the source? With some luck there'd be a environ.c. :-)
    --
    - Vince
     
  21. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    Thanks for all the help; I've certainly learned more about the perl
    scripting support in TCC as a result.

    I downloaded the current 5.8 ActiveState perl and put it in my path
    with the perl script checkbox checked and the problem does not show
    up. So, it looks like it is just my version of perl58.dll that is
    doing it.

    I'll look at the sources to see if I can figure why the heck it would
    be doing that.

    On Thu, Mar 5, 2009 at 9:36 AM, rconn <> wrote:



    --
    Jim Cook
    2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Sunday.
     
  22. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    Other than PATH, is there a way to tell TCC which perl58.dll to load
    when its own scripting is turned on?

    I can't run the ActiveState version in production because we have so
    many additional modules required for our usage, but I would like to
    take advantage of the exchange of information in cases, now that I
    know it's possible.

    On Thu, Mar 5, 2009 at 2:12 PM, Jim Cook <> wrote:



    --
    Jim Cook
    2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Sunday.
     
  23. vefatica

    Joined:
    May 20, 2008
    Messages:
    8,129
    Likes Received:
    33
    You could try puttting the one you want TCC to use in the same directory as TCC.EXE (where another app is unlikely to find it). Of the LoadLibrary function, which TCC may well use, the docs say:

    "The first directory searched is the one directory containing the image file used to create the calling process"
     

Share This Page