Read this if you're having trouble unpacking Tcl

[Tom Neff]

In article <MEISSNER.91Jan2004316 at curley.osf.org> meissner at osf.org (Michael Meissner) writes:
>Pray tell how do you deal with the following situation (which I did
>run into):
>
>Site A posts something that has tabs in it, but is otherwise clean.
>Site B (for bitnet) converts the tabs into spaces and passes it on.
>Side C unpacks it, and it doesn't work at all, because make wants tabs
>in front of the commands, or the next patch (which goes by way of site
>D instead of B) doesn't apply because the lines don't match.

OK, that's actually two sub-situations with some common solutions.

First, it's a MAKE idiocy to require those leading tabs.  Hardly
sporting behavior for a dumb keyword oriented source language.  I know
that not all implementations still need it.  YOU tell ME how people on
tabless machines deal with them, eh?

But of course, it's no good preaching against prior art.  So how do
tab-hungry people survive on the other side of a tab-stripping news
link?  I'd say use a little C program that reinserts leading tabs.  It
ought to be so short you could include it right next to the Makefile.

Beyond that, I would think that people living in the above mentioned
environment would learn to use the '-l' switch for patch!  For ordinary
source files, whitespace alone should never cause a patch reject.

>Programs aren't the only things that are sent.  I've seen ASCII data
>files which are not meant for human eyes, that have hundreds of
>characters, and no form of continuation characters.

Oh yes, I agree.  The same thing goes for little bitmaps and other such
INTRINSICALLY binary data which must be included with a source
distribution in order to complete the packages.  By all means uuencode
those individual components within the shar.  But don't uuencode the
whole thing just for the sake of one or two auxiliary files.
-- 
Thank God for atheism!        8=8=8=8          Tom Neff / tneff at bfmny0.BFM.COM