On 9/14/10 18:24 CDT, Denis Koroskin wrote:
On Wed, 15 Sep 2010 02:58:45 +0400, Andrei Alexandrescu
<[email protected]> wrote:
On 9/14/10 16:04 CDT, Walter Bright wrote:
Steven Schveighoffer wrote:
Not that anyone here is in charge of your time, I think Andrei's
"waste of time" point is that there are better, more productive things
you can do for the good of D. If someone else wants to write this
utility, great. But in the meantime, can we just put in the easy fix?
It's arguable whether the "easy" fix is to write a trivial utility, or
to rejigger all my build and install scripts.
In any case, it's done. Here it is, it's mostly a cut&paste from another
zip utility I wrote long ago.
I might be missing something, but as I mentioned, I fail to see how
this program serves the packaging process better than the zip utility
available on Linux.
Andrei
I think we've spent far more time on this discussion that Walter on the
zipper :)
I'm actually on his side tbh. Sometimes it's plain faster to reinvent
the wheel than learn third-party solution. You are also forgetting about
the fun-factor: sometimes you are getting hooked on something even if
it's actually useless or silly, there is still an experience gain.
The problem is twofold. One, writing one custom program for a typical
scripting task does not foster learning stuff that you'll be using for
the next unrelated scripting task. It's squarely the wrong kind of
reinforcement. Second, doing this systematically takes us to
Creativity's ugly cousins: Provincialism and Isolation.
Walter delivers the way he can. It might not be an optimal solution from
other peoples' perspective, but I do think it's viable. And if it is a
replaceable part of a building process, why not? Make it work first,
then make it right.
BTW, in spite of hearing that unix zip is capable of doing the job many
times today I didn't see the solution posted.
zip gorramfile.zip gorramfiles/*
Andrei
