Thoughts on Tcl (long but necessary)

Bruce Dubbs bruce.dubbs at
Fri Apr 28 18:40:14 PDT 2006

Randy McMurchy wrote:
> Bruce Dubbs wrote these words on 04/28/06 19:01 CST:
>> The whole thing is a bit confusing.  Let me see if I understand.
>> Version one is:
>> cd unix &&
>> ./configure --prefix=/usr --enable-threads &&
>> make &&
>> sed -i -e "s:${PWD}/unix:/usr/lib:" \
>>        -e "s:${PWD}:/usr/include/tcl&tklver;:" \
>>        -e "/TCL_LIB_FILE/ s:':\":g" \
> This isn't what was in my message, this is what was in your message
> to the bug. And it won't work. In fact, looking at it harder, you
> included the semantic changes I made, yet you are stuck on using
> $PWD in both places, even though this breaks the whole deal.
> Using $PWD in both -e scripts is broken. Plain and simple. It must
> be $PWD in one and a directory level lower for the other. $PWD
> cannot satisfy both of those conditions.

OK, I'm going back and questioning why this sed is in the book at all.
Looking at the history in the book, this was here when we made the major
structure change in June 2004 and I can't see before that because
subordinate files were deleted then.

The script merely sets environment files.  Nothing more.
The only place the $PWD comes into play is for the variables
TCL_BUILD_*.  I see no valid reason for changing them at all.  If we do
change them, they will certainly be pointing to the wrong place.  Better
missing than wrong.

As far as the 3rd expression goes, there are 14 environment variables
that have ${var} expressions inside single quotes.  Why are we changing
only one?

I looked for "TCL_LIB_FILE"  in the archives and found 14 hits.  12 were
in commits and 2 in bugs in 2005 and 2006.  There has never been any
discussion on why this change is needed.

On a RH9 system, all the entries have single quotes.  The BUILD vars
look like:


Based on this analysis, I am in favor of eliminating the sed completely.
 Its one of those legacy things that has developed a life of its own for
no documented reason.

  -- Bruce

More information about the blfs-dev mailing list