Walter Bright Wrote:

> Steven Schveighoffer wrote:
> > I'm not sure what this does, I really *really* hope it doesn't set the attrs of all files to a+x.
> 
> You can download the new beta and see how it worked!

Now it works. However, you're wasting bandwidth because the zipper is a lot worse than 7zip at making .zips!

On 9/14/10 17:05 CDT, Walter Bright wrote:
> retard wrote:
>> Tue, 14 Sep 2010 14:14:42 -0700, Walter Bright wrote:
>>
>>> retard wrote:
>>>> The difference is, on *nix the disabled executable flag prevents *all
>>>> users* from launching the application. The attributes have a standard
>>>> meaning.
>>> No, the meanings are not standard between Windows and Linux. There's no
>>> way to make them standard, either. The file systems are *different*.
>>
>> Across *nixen. I couldn't care less about Windows.
>
> Dmd supports Windows, therefore it must care about it.
>
>
>> A power user version of the zipper would support both sets of
>> attributes and would also provide an interface for modifyin them.
>
> Except that I could not find such a utility - for Windows or Unix.

So please let's restart - what _exactly_ is the utility we need? Far as I can tell what we're looking for looking for a zip utility that knows how to preserve the executable bit on Unix, and produce otherwise readable archives for Windows. That's it. From what I can tell, the zip already available on Linux does all that.

Andrei

On 9/14/10 16:14 CDT, Walter Bright wrote:
> retard wrote:
>> The difference is, on *nix the disabled executable flag prevents *all
>> users* from launching the application. The attributes have a standard
>> meaning.
>
> No, the meanings are not standard between Windows and Linux. There's no
> way to make them standard, either. The file systems are *different*.
>
>
>> *nix also has the 'hidden flag' in form of files with names starting
>> with a dot.
>
> A filename convention is not a file attribute bit, and there's no way to
> pretend they are the same in a portable archiver.
>
>
>> The S, H, and A attributes don't have any use when shipping 3rd party
>> userspace applications.
>
> That's up to the distributor. I don't like 'em and don't use 'em, but
> I'd support them properly if I was writing a file packager/unpackager.
>
> The right solution is supported by the zip file format - there are
> separate attribute fields for unix and Windows. The unzipper follows
> them, it's just that the zipper offers no way to set them for systems
> other than the one the zipper is run on.

What flags do you need to set specifically for Windows?

Andrei

On 9/14/10 16:06 CDT, Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> Yes. Please, let's not waste our time rewriting shell two-liners as
>> specialized programs.
>
> It's not always a waste of time. For example, I stopped using lib and ar
> to generate libraries and instead built it into dmd. The result is quite
> pleasing, it's very very fast to build libraries and does not litter
> one's directories with object files.

There is no comparison. You have spent time replacing a simple but inefficient tool with one that improves efficiency sensibly. That is in keeping with your own recent article on optimization. Your zip utility (better call it "inutility") goes straight against your own advice and also against common sense. It is not right to hijack the positive reinforcement you got from replacing lib and ar, and use it to justify the monumental waste of time that zip is.

Andrei

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

Andrei Alexandrescu wrote:
> 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.

All the build, install, and test scripts run on windows (using plink to build things on the other platforms). Writing a script to transfer all the files to linux, reset the permissions, run zip, copy the results back, etc., will take longer than just writing that trivial utility. That's what programming languages are for.

On Wed, 15 Sep 2010 02:58:45 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> 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.

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.

On Tuesday, September 14, 2010 15:50:22 Andrei Alexandrescu wrote:
> On 9/14/10 17:05 CDT, Walter Bright wrote:
> > retard wrote:
> >> Tue, 14 Sep 2010 14:14:42 -0700, Walter Bright wrote:
> >>> retard wrote:
> >>>> The difference is, on *nix the disabled executable flag prevents *all users* from launching the application. The attributes have a standard meaning.
> >>> 
> >>> No, the meanings are not standard between Windows and Linux. There's no way to make them standard, either. The file systems are *different*.
> >> 
> >> Across *nixen. I couldn't care less about Windows.
> > 
> > Dmd supports Windows, therefore it must care about it.
> > 
> >> A power user version of the zipper would support both sets of attributes and would also provide an interface for modifyin them.
> > 
> > Except that I could not find such a utility - for Windows or Unix.
> 
> So please let's restart - what _exactly_ is the utility we need? Far as I can tell what we're looking for looking for a zip utility that knows how to preserve the executable bit on Unix, and produce otherwise readable archives for Windows. That's it. From what I can tell, the zip already available on Linux does all that.
> 
> Andrei

I understood that the files in question are being zipped on a windows box, and since the windows file system is not going to retain any of the unix permissions, the zipped files won't either. I take it that Walter's utility is meant to appropriately set the unix permissions when it zips the files.

Of course, I could have completely misunderstood, but that's what it seemed to me was going on.

Personally, I would think that it would make more sense to do the linux build on a linux machine and package it with tar and bzip2 (or gzip if you're old school and want a larger download), while the windows build is done a windows machine and zipped there, creating two separate downloads - one for linux and one for windows (and presumably, you'd do the same for the other architectures). All file permissions are thus properly maintained. Since I assume that you have to do the build on the appropriate machine _anyway_, I don't see why we should be going to the trouble of creating a single zip file with both. Normally, people only want one of the two anyway.

- Jonathan M Davis

On 9/14/10 18:24 CDT, Denis Koroskin wrote:
> On Wed, 15 Sep 2010 02:58:45 +0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> 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

Hello Walter,

> retard wrote:
> 
>> Tue, 14 Sep 2010 14:14:42 -0700, Walter Bright wrote:
>> 
>>> retard wrote:
>>> 
>>>> The difference is, on *nix the disabled executable flag prevents
>>>> *all users* from launching the application. The attributes have a
>>>> standard meaning.
>>>> 
>>> No, the meanings are not standard between Windows and Linux. There's
>>> no way to make them standard, either. The file systems are
>>> *different*.
>>> 
>> Across *nixen. I couldn't care less about Windows.
>> 
> Dmd supports Windows, therefore it must care about it.

Do any of the attribute bits for the files in the DMD zips matter on windows? If not, just zip it up on linux and be done with it.

-- 
... <IXOYE><