Occasional COLORDIR issue

[Jim Cook]

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.

 

[rconn]

Jim Cook wrote:

> 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.
>
> Has anyone else seen an occasional mangling of some environment
> variables in a long running TCC box?

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

 

[Jim Cook]

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 wrote:
>
>
> ---Quote---
>> 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.
>>
>> Has anyone else seen an occasional mangling of some environment
>> variables in a long running TCC box?
> ---End Quote---
> 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
>
>
>
>
>

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

 

[Charles Dye]

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.

A hasty copy-and-paste from the screen buffer into ESET, perhaps?

 

[Jim Cook]

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:

>

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.

>
> A hasty copy-and-paste from the screen buffer into ESET, perhaps?
>
>
>
>
>

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

 

[rconn]

Jim Cook wrote:

> Every now and then, I notice that my directories no longer conform to
> the COLORDIR variable.

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

 

[Jim Cook]

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 wrote:
>
>
> ---Quote---
>> Every now and then, I notice that my directories no longer conform to
>> the COLORDIR variable.
> ---End Quote---
> 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
>
>
>
>
>

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

 

[Jim Cook]

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 <[email protected]> wrote:

> 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 wrote:
>>
>>
>> ---Quote---
>>> Every now and then, I notice that my directories no longer conform to
>>> the COLORDIR variable.
>> ---End Quote---
>> 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
>>
>>
>>
>>
>>
>
>
>
> --
> 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.
>

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

 

[Jim Cook]

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:

> 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 <[email protected]> wrote:
>
>
> ---Quote---
>> 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 wrote:
>>>
>>>
>>> ---Quote---
>>>> Every now and then, I notice that my directories no longer conform to
>>>> the COLORDIR variable.
>>> ---End Quote---
>>> 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
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> 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.
>>
> ---End Quote---
>
>
> --
> 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.
>
>
>
>
>

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

 

[samintz]

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:

> 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 <[email protected]> wrote:
>
>
> ---Quote---
> > 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 wrote:
> >>
> >>
> >> ---Quote---
> >>> Every now and then, I notice that my directories no longer conform

to

> >>> the COLORDIR variable.
> >> ---End Quote---
> >> 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
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> > --
> > 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.
> >
> ---End Quote---
>
>
> --
> 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.
>
>
>
>

 

[Jim Cook]

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:

> e.g. * *COLORDIR=COLORDIR=blah blah blah

Yes. That's exactly the symptom.

> What do you mean by "Control Panel settings?"

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.

> Why did you have to "reduce your PATH?"

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.

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

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.

> What does "WHICH HELLOWORD.PL" return?

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

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

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.

> -Scott

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.

 

[samintz]

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:

> 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:
>
>
> ---Quote---
> > e.g. * *COLORDIR=COLORDIR=blah blah blah
> ---End Quote---
> Yes. That's exactly the symptom.
>
>
>
> ---Quote---
> > What do you mean by "Control Panel settings?"
> ---End Quote---
> 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.
>
>
>
> ---Quote---
> > Why did you have to "reduce your PATH?"
> ---End Quote---
> 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.
>
>
>
> ---Quote---
> > And after HELLOWORLD.PL runs and you get back your prompt, your
> > environment has changed?
> ---End Quote---
> 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.
>
>
>
> ---Quote---
> > What does "WHICH HELLOWORD.PL" return?
> ---End Quote---
> helloworld.pl is an external: <currentfolder>helloworld.pl
>
>
>
> ---Quote---
> > If you run "TASKLIST tcc" before and after you run HELLOWORD do you

get

> > the same number of instances of TCC running?
> ---End Quote---
> 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.
>
>
>
> ---Quote---
> > -Scott
> ---End Quote---
> 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.
>
>
>
>

 

[Jim Cook]

No. It is not checked.


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

> 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:
>
>
>
> ---Quote---
>> 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:
>>
>>
>> ---Quote---
>> > e.g. * *COLORDIR=COLORDIR=blah blah blah
>> ---End Quote---
>> Yes. That's exactly the symptom.
>>
>>
>>
>> ---Quote---
>> > What do you mean by "Control Panel settings?"
>> ---End Quote---
>> 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.
>>
>>
>>
>> ---Quote---
>> > Why did you have to "reduce your PATH?"
>> ---End Quote---
>> 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.
>>
>>
>>
>> ---Quote---
>> > And after HELLOWORLD.PL runs and you get back your prompt, your
>> > environment has changed?
>> ---End Quote---
>> 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.
>>
>>
>>
>> ---Quote---
>> > What does "WHICH HELLOWORD.PL" return?
>> ---End Quote---
>> helloworld.pl is an external: <currentfolder>helloworld.pl
>>
>>
>>
>> ---Quote---
>> > If you run "TASKLIST tcc" before and after you run HELLOWORD do you
> ---End Quote---
> get
>
>
> ---Quote---
>> > the same number of instances of TCC running?
>> ---End Quote---
>> 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.
>>
>>
>>
>> ---Quote---
>> > -Scott
>> ---End Quote---
>> 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.
>>
>>
>>
>>
> ---End Quote---
>
>
>
>

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

 

[rconn]

Jim Cook wrote:

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

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

 

[rconn]

Jim Cook wrote:

> 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

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

 

[Jim Cook]

>> Now the question, is why does my environment get changed when I use an
>> executable extension? I don't believe it should.
> ---End Quote---
> 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.

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.

 

[vefatica]

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

 

[rconn]

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.

 

[Jim Cook]

On Thu, Mar 5, 2009 at 9:32 AM, vefatica <> wrote:

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

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.

 

[vefatica]

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

 

[Jim Cook]

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:

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

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

 

[Jim Cook]

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:

> 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:
>
>
> ---Quote---
>> 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.
>>
>>
>>
>>
>>
> ---End Quote---
>
>
> --
> 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.
>
>
>
>
>

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

 

[vefatica]

Other than PATH, is there a way to tell TCC which perl58.dll to load when its own scripting is turned on?

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"