On 09/14/2010 05:38 AM, 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?

Yes. Please, let's not waste our time rewriting shell two-liners as specialized programs.

Andrei

On 09/14/2010 05:41 AM, retard wrote:
> Mon, 13 Sep 2010 18:44:35 -0700, Walter Bright wrote:
>> It's also nice to eat our own dogfood, and do something useful with
>> std.zip.
>
> And D is a pragmatic language? Listen man, you the Superman of the D
> world and instead of fighting crimes, you're always knitting socks.

Well ideally we'd eat our dogfood by bootstrapping dmd. I think that'll happen at some point in the future due to the nice ddmd ongoing effort. Walter is itching to use D's power in day-to-day work.

There is a fuzzy limit regarding what should be a script vs. a program. For example, rdmd did start as a script. Probably it still could be, but it's involved and specialized enough to justify writing it in D. My guess is that the script would have more lines and would be much more difficult to maintain than the D program.

But writing a zipper in D that essentially emulates a zip command line... I mean come on.


Andrei

P.S. Never been fond of std.zip's interface...

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:i6o3c3$tep$1@digitalmars.com...
> On 09/14/2010 05:41 AM, retard wrote:
>> Mon, 13 Sep 2010 18:44:35 -0700, Walter Bright wrote:
>>> It's also nice to eat our own dogfood, and do something useful with std.zip.
>>
>> And D is a pragmatic language? Listen man, you the Superman of the D world and instead of fighting crimes, you're always knitting socks.
>
> Well ideally we'd eat our dogfood by bootstrapping dmd. I think that'll happen at some point in the future due to the nice ddmd ongoing effort. Walter is itching to use D's power in day-to-day work.
>
> There is a fuzzy limit regarding what should be a script vs. a program. For example, rdmd did start as a script. Probably it still could be, but it's involved and specialized enough to justify writing it in D. My guess is that the script would have more lines and would be much more difficult to maintain than the D program.
>

It also wouldn't work for us Windows users without having to deal with a PITA like MSYS or Cygwin. (I'm not saying we do or don't need a D-based zip tool. I'm just saying I'm glad rdmd isn't a shell script.)

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


import std.c.stdio;
import std.c.stdlib;
import std.stdio;
import std.file;
import std.date;
import std.zip;
import std.zlib;

int main(string[] args)
{
    if (args.length == 1)
    {
	writeln("Usage: zip zipfile attr members...");
	exit(0);
    }

    if (args.length == 2)
    {
	auto zipname = args[1];
	auto buffer = cast(byte[])std.file.read(zipname);
	auto zr = new std.zip.ZipArchive(cast(void[])buffer);
	writefln("comment = '%s'", zr.comment);
	foreach (ArchiveMember de; zr.directory)
	{
	    zr.expand(de);
	    writefln("name = %s", de.name);
	    writefln("\tcomment = %s", de.comment);
	    writefln("\tmadeVersion = x%04x", de.madeVersion);
	    writefln("\textractVersion = x%04x", de.extractVersion);
	    writefln("\tflags = x%04x", de.flags);
	    writefln("\tcompressionMethod = %d", de.compressionMethod);
	    writefln("\tcrc32 = x%08x", de.crc32);
	    writefln("\texpandedSize = %s", de.expandedSize);
	    writefln("\tcompressedSize = %s", de.compressedSize);
	    writefln("\teattr = %03o, %03o", de.externalAttributes >> 16, de.externalAttributes & 0xFFFF);
	    writefln("\tiattr = %03o", de.internalAttributes);
	    writefln("\tdate = %s", std.date.toString(std.date.toDtime(de.time)));
	}
	return 0;
    }

    auto zipname = args[1];
    auto attr = args[2];
    auto members = args[3 .. $];

    uint newattr = 0;
    foreach (c; attr)
    {
	if (c < '0' || c > '7' || attr.length > 4)
	    throw new ZipException("attr must be 1..4 octal digits, not " ~ attr);
	newattr = (newattr << 3) | (c - '0');
    }

    auto buffer = cast(byte[])std.file.read(zipname);
    auto zr = new std.zip.ZipArchive(cast(void[])buffer);

    foreach (member; members)
    {
	foreach (ArchiveMember de; zr.directory)
	{
	    if (de.name == member)
		goto L1;
	}
	throw new ZipException(member ~ " not in zipfile " ~ zipname);
      L1:
	;
    }

    bool changes;
    foreach (ArchiveMember de; zr.directory)
    {
	zr.expand(de);

	foreach (member; members)
	{
	    if (de.name == member && ((de.externalAttributes >> 16) & 07777) != newattr)
	    {	changes = true;
		de.madeVersion = 0x317;	// necessary or linux unzip will ignore attributes
		de.externalAttributes = (de.externalAttributes & ~(07777 << 16)) | (newattr << 16);
		break;
	    }
	}
    }

    if (changes)
    {	void[] data2 = zr.build();
	std.file.write(zipname, cast(byte[])data2);
    }
    return 0;
}

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.

On Tue, 14 Sep 2010 17:04:21 -0400, Walter Bright <newshound2@digitalmars.com> 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.

Not knowing what your build scripts look like, I don't know the answer.  I'm assuming you have some manual work to do because you are building on several different machines, and I was assuming that due to that fact, the packaging step was not part of the build steps.  In that case, it would be a trivial, change package command from running on a windows box to running on a linux box.

It might be a simple assumption, but I very much doubt you would have to rejigger *all* your build 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'm not sure what this does, I really *really* hope it doesn't set the attrs of all files to a+x.

In any case, if it works, it's done, let's move on (I still prefer separate packages per OS though).

-Steve

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.

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.

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

I meant it's semantically a similar convention.

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

A power user version of the zipper would support both sets of attributes and would also provide an interface for modifyin them.

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!

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.