On Tue, Sep 14, 2010 at 12:56 AM, Walter Bright <newshound2@digitalmars.com> wrote:
> Andrei Alexandrescu wrote:
>>
>> There's nothing wrong about preferring Windows over Linux. I'm just saying (much like you) that badly reinventing Unix tools under Windows is not quite productive.
>
> The unix version of zip has no option to set the file attributes either.
>

It has the (default) option of preserving the attributes and the
option (-X) to explicitly not save the attributes.

What is the reason for delivering executables for 4 different
operating systems in the same archive anyway?
Having a different archive for each OS would reduce the download-size
and you could use archive formats that are better suited for each
platform, e.g. tar for unixoid systems. Tar *does* allow to set the
owner/group/mode attributes when adding files to a tarball. At least
gnu tar does, but probably there are ports for windows are able to do
the same thing.

Cheers,
- Daniel

On 09/13/2010 05:56 PM, Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> There's nothing wrong about preferring Windows over Linux. I'm just
>> saying (much like you) that badly reinventing Unix tools under Windows
>> is not quite productive.
>
> The unix version of zip has no option to set the file attributes either.

It does preserve them. Zip a binary and then unzip it - it'll run.

Andrei

Andrei Alexandrescu wrote:
> On 09/13/2010 05:56 PM, Walter Bright wrote:
>> Andrei Alexandrescu wrote:
>>> There's nothing wrong about preferring Windows over Linux. I'm just
>>> saying (much like you) that badly reinventing Unix tools under Windows
>>> is not quite productive.
>>
>> The unix version of zip has no option to set the file attributes either.
> 
> It does preserve them. Zip a binary and then unzip it - it'll run.


zip on unix has no way to set the Windows attributes, and zip on Windows has no way to set the unix attributes. Both have attributes that have no analogs on the other. Both have no way to set the non-native attributes.

On 09/13/2010 07:47 PM, Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> On 09/13/2010 05:56 PM, Walter Bright wrote:
>>> Andrei Alexandrescu wrote:
>>>> There's nothing wrong about preferring Windows over Linux. I'm just
>>>> saying (much like you) that badly reinventing Unix tools under Windows
>>>> is not quite productive.
>>>
>>> The unix version of zip has no option to set the file attributes either.
>>
>> It does preserve them. Zip a binary and then unzip it - it'll run.
>
>
> zip on unix has no way to set the Windows attributes, and zip on Windows
> has no way to set the unix attributes. Both have attributes that have no
> analogs on the other. Both have no way to set the non-native attributes.

I didn't know there is an executable attribute on Windows.

Anyhow, I guess that underlines the necessity to do what everybody does - assemble the installer on the distribution platform, and have it only contain the files for that platform. An increasingly large audience is looking at us, and we should avoid being provincial. I'm not even sure why we're having this discussion - there should be no debate here: we do what people do. This reminds me of the discussion of yesteryear - people were complaining about C++ files in dmd having the .c extension, and the right answer would have been to change the blessed thing to be like everybody else has it, instead of finding arguments on why it worked the way it was.


Andrei

Andrei Alexandrescu wrote:
> On 09/13/2010 07:47 PM, Walter Bright wrote:
>> zip on unix has no way to set the Windows attributes, and zip on Windows
>> has no way to set the unix attributes. Both have attributes that have no
>> analogs on the other. Both have no way to set the non-native attributes.
> 
> I didn't know there is an executable attribute on Windows.

There isn't. But there are system, hidden, and archive attribute bits that have no analog on unix. Not that we use any of those bits, I'm just arguing the point that unix utilities are not always better - in this case, they have the same deficiency. Googling this particular issue brings up pages where people are told to use python scripts to set the attributes in a zip file.

It's also nice to eat our own dogfood, and do something useful with std.zip.

> Anyhow, I guess that underlines the necessity to do what everybody does - assemble the installer on the distribution platform, and have it only contain the files for that platform. An increasingly large audience is looking at us, and we should avoid being provincial. I'm not even sure why we're having this discussion - there should be no debate here: we do what people do. This reminds me of the discussion of yesteryear - people were complaining about C++ files in dmd having the .c extension, and the right answer would have been to change the blessed thing to be like everybody else has it, instead of finding arguments on why it worked the way it was.

Hard to argue with that.

On Mon, 2010-09-13 at 23:44 +0200, Andrej Mitrovic wrote:
> Can't you use your archiver to do that for you? F2, rename, extract. Done deal. I like to keep the latest version in the DMD2 folder, all the better for compatibility with existing build scripts. I really wouldn't want to have to keep renaming paths in makefiles for every release of DMD2. Although I'll never have that problem since I can rename the folder inside the zip.

That is what symbolic links are for.  The binary distribution should unpack into a version specific directory.  This then allows multiple versions to be installed at the same time and for selection to be by trivially changing a symbolic link.

|> ll -d ~/lib*/*[dD][mM][dD]*
lrwxrwxrwx  1 russel russel    9 2010-08-13 16:50 /home/users/russel/lib/DMD1 -> dmd-1.063/
drwx------ 10 russel russel 4096 2010-08-13 16:49 /home/users/russel/lib/dmd-1.063/
lrwxrwxrwx  1 russel russel    9 2010-08-13 18:33 /home/users/russel/lib/DMD2 -> dmd-2.048/
drwx------  9 russel russel 4096 2010-08-13 16:50 /home/users/russel/lib/dmd-2.048/
lrwxrwxrwx  1 russel russel   17 2010-08-13 16:52 /home/users/russel/lib.Linux.ix86/DMD1 -> ../lib/DMD1/linux/
lrwxrwxrwx  1 russel russel   17 2010-08-13 16:52 /home/users/russel/lib.Linux.ix86/DMD2 -> ../lib/DMD2/linux/
lrwxrwxrwx  1 russel russel   17 2010-08-13 16:55 /home/users/russel/lib.Linux.x86_64/DMD1 -> ../lib/DMD1/linux/
lrwxrwxrwx  1 russel russel   17 2010-08-13 16:55 /home/users/russel/lib.Linux.x86_64/DMD2 -> ../lib/DMD2/linux/
|>

Better still, get the whole thing packaged by Debian and thence in the Debian and Ubuntu distributions by default.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Mon, 2010-09-13 at 19:57 -0500, Andrei Alexandrescu wrote: [ . . . ]
> Anyhow, I guess that underlines the necessity to do what everybody does - assemble the installer on the distribution platform, and have it only contain the files for that platform. An increasingly large audience is
[ . . . ]

So create a Linux distribution on a Linux box (*) containing only the Linux materials with tar not zip using bzip2 or gzip compression. Solaris, FreeBSD, etc. all go the same.  Doing this for the source distribution will assist getting things into the Debian packaging system.

On Windows I guess zip created on a Windows box (*) is the only option.
I am sure Windows people will be happy not to have all the Linux and Mac
OS stuff (which to them is crud).

For Mac OS X the question is whether to make a Mac OS X installer, or ship a zipfile or tarball -- difficult for me to call I am not really a Mac OS X person, but . . . it would be really good to have a port in MacPorts to save the hassle of doing any manual installation. (**)

Can I suggest that as part of the revolution that is going to be caused by having a 64-bit as well as 32-bit version of D v2, that there is a campaign to have D in Debian, Fedora and MacPorts.

(*)  No need for separate Linux and Windows hardware, though that is best, you can just use virtual machines.

(**) Mac OS X sort of does require A$$le hardware.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Mon, 13 Sep 2010 21:44:35 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> Andrei Alexandrescu wrote:
>> On 09/13/2010 07:47 PM, Walter Bright wrote:
>>> zip on unix has no way to set the Windows attributes, and zip on Windows
>>> has no way to set the unix attributes. Both have attributes that have no
>>> analogs on the other. Both have no way to set the non-native attributes.
>>  I didn't know there is an executable attribute on Windows.
>
> There isn't. But there are system, hidden, and archive attribute bits that have no analog on unix. Not that we use any of those bits...

Um... ok, so logic says that in this particular case, the most universally useful archive is formed on Linux.  I don't see where your point is...

> I'm just arguing the point that unix utilities are not always better - in this case, they have the same deficiency. Googling this particular issue brings up pages where people are told to use python scripts to set the attributes in a zip file.

This isn't a unix vs. windows war.  We aren't counting up the points that the utilities score to see who is better.  We just want an archive that does the right thing on all OSes.  This can be achieved by building it on Linux.  So do it already :)

BTW, the fact that zip is not all-encompassing on Linux is not surprising -- the main method of archive distribution on Linux is tar.gz/bz2.

> It's also nice to eat our own dogfood, and do something useful with std.zip.

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?

-Steve

Mon, 13 Sep 2010 18:44:35 -0700, Walter Bright wrote:

> Andrei Alexandrescu wrote:
>> On 09/13/2010 07:47 PM, Walter Bright wrote:
>>> zip on unix has no way to set the Windows attributes, and zip on Windows has no way to set the unix attributes. Both have attributes that have no analogs on the other. Both have no way to set the non-native attributes.
>> 
>> I didn't know there is an executable attribute on Windows.
> 
> There isn't. But there are system, hidden, and archive attribute bits that have no analog on unix. Not that we use any of those bits, I'm just arguing the point that unix utilities are not always better - in this case, they have the same deficiency.

The difference is, on *nix the disabled executable flag prevents *all users* from launching the application. The attributes have a standard meaning. *nix also has the 'hidden flag' in form of files with names starting with a dot.

The S, H, and A attributes don't have any use when shipping 3rd party userspace applications. The A attribute would matter if various archivers actually preserved it and there was a standard on when to set it on.

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

On 09/13/2010 11:51 PM, Russel Winder wrote:
> On Mon, 2010-09-13 at 19:57 -0500, Andrei Alexandrescu wrote:
> [ . . . ]
>> Anyhow, I guess that underlines the necessity to do what everybody does
>> - assemble the installer on the distribution platform, and have it only
>> contain the files for that platform. An increasingly large audience is
> [ . . . ]
>
> So create a Linux distribution on a Linux box (*) containing only the
> Linux materials with tar not zip using bzip2 or gzip compression.
> Solaris, FreeBSD, etc. all go the same.  Doing this for the source
> distribution will assist getting things into the Debian packaging
> system.
>
> On Windows I guess zip created on a Windows box (*) is the only option.
> I am sure Windows people will be happy not to have all the Linux and Mac
> OS stuff (which to them is crud).
>
> For Mac OS X the question is whether to make a Mac OS X installer, or
> ship a zipfile or tarball -- difficult for me to call I am not really a
> Mac OS X person, but . . . it would be really good to have a port in
> MacPorts to save the hassle of doing any manual installation. (**)
>
> Can I suggest that as part of the revolution that is going to be caused
> by having a 64-bit as well as 32-bit version of D v2, that there is a
> campaign to have D in Debian, Fedora and MacPorts.

My thoughts exactly.

Andrei