www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Well, it's been a total failure

reply "Vladimir G. Ivanovic" <vladimir acm.org> writes:
 I'm running Fedora 13.x86_64 and I've tried various ways of getting a
D compiler to work. None have succeeded.

1. a. I can't install dmd 2.048:


        error: Failed dependencies:
           gcc(x86-32) >=3D 4.2.3 is needed by dmd-2.048-0.i386
   I don't know what package will satisfy this dependency.
   b. dmd is a closed compiler. Not good. I'm really not comfortable
running a compiler for which I don't have access to the source. The
risk of undetected malware is too great.
   c. So, I give up on dmd.

2. I can't run ldc because
   a. The ldc RPM requires Tango, even though this is not an RPM
dependency for ldc, i.e. you can install ldc without any errors.
   b. The installation instructions for Fedora on the LDC web site are
incorrect. "yum install ldc" works, but "yum install tango" doesn't.
"yum install tango-devel" is the correct command. (This is the first
time I've heard of <pkg>-devel without a corresponding <pkg>.)
   c. After I've gotten everything installed, it still doesn't work. I ge=
t
        $ ldc hello.d
        hello.d(5): Error: module stdio cannot read file 'std/stdio.d'
   d. OK, so I link /usr/include/d/tango/stdc to
/usr/include/d/tango/std, but it still doesn't work. I get:
        $ ldc hello.d
        hello.d(8): Error: undefined identifier writefln
        hello.d(8): Error: function expected before (), not writefln
of type int
   e. ldc only supports D v1.
   f. All of this is too much for me. I give up on ldc.

3. I can't get gdc to compile.
   a. First I have to get gcc-4.4.4 to compile, but that requires a 4
year old version of automake. I have to downgrade.
   b. After that's fixed, I'm still running into errors that prevent a
build. The errors change from changeset to changeset. So, I'm giving
up on gdc.

Getting a D compiler to run on x86_64 Linux is too hard. I'm giving up
on D.

I'm posting this message not as a plea for help, but to illustrate how
hard it is to get D to run on Fedora.x86_64. The success of D depends
on high quality, open source compilers being available (my belief),
and so far, D doesn't seem to be mature enough to be considered, at
least on Fedora.x86_64.

But, on the plus side, the existence of the book "The D Programming
Language" is a major step in getting D accepted as a serious system
programming language. Maybe installation will improve and D will move
forward.

--- Vladimir

--=20
Vladimir G. Ivanovic                            http://www.leonora.org
+1 650 450 4101                                       vladimir acm.org
Sep 11 2010
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Vladimir G. Ivanovic wrote:

  I'm running Fedora 13.x86_64 and I've tried various ways of getting a
 D compiler to work. None have succeeded.
 
 1. a. I can't install dmd 2.048:
 

         error: Failed dependencies:
            gcc(x86-32) >= 4.2.3 is needed by dmd-2.048-0.i386
    I don't know what package will satisfy this dependency.
    b. dmd is a closed compiler. Not good. I'm really not comfortable
 running a compiler for which I don't have access to the source. The
 risk of undetected malware is too great.
    c. So, I give up on dmd.


Complete source code comes with dmd. Try downloading:

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.063.zip

http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.048.zip

There are several people working on the source. Lots of D users compile their 
own versions of dmd. The complete dmd source code is also available here:

http://www.dsource.org/projects/dmd/browser/trunk/
Sep 11 2010
prev sibling next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 11/09/10 23:52, Vladimir G. Ivanovic wrote:

   I'm running Fedora 13.x86_64 and I've tried various ways of getting a
 D compiler to work. None have succeeded.

 1. a. I can't install dmd 2.048:


          error: Failed dependencies:
             gcc(x86-32)>= 4.2.3 is needed by dmd-2.048-0.i386
     I don't know what package will satisfy this dependency.


I've never used fedora, so I'll skip anything further about rpms.


     b. dmd is a closed compiler. Not good. I'm really not comfortable
 running a compiler for which I don't have access to the source. The
 risk of undetected malware is too great.


Only the backend is closed, and the source is still available. The front 
end is dual licensed under the GPL and artistic licenses:

http://www.dsource.org/projects/dmd/browser/trunk/src


     c. So, I give up on dmd.

 2. I can't run ldc because
     a. The ldc RPM requires Tango, even though this is not an RPM
 dependency for ldc, i.e. you can install ldc without any errors.


Again, I know nothing of RPMs/Fedora, but I can say ldc doesn't require 
tango - it's just a lot nicer to use if you have a standard library :)


     b. The installation instructions for Fedora on the LDC web site are
 incorrect. "yum install ldc" works, but "yum install tango" doesn't.
 "yum install tango-devel" is the correct command. (This is the first
 time I've heard of<pkg>-devel without a corresponding<pkg>.)
     c. After I've gotten everything installed, it still doesn't work. I get
          $ ldc hello.d
          hello.d(5): Error: module stdio cannot read file 'std/stdio.d'


std is part of phobos, and phobos does not support ldc. A hello world 
using tango would look like this:
---
import tango.io.Stdout;

void main() {
	Stdout("Hello World!").newline;
}
----

     d. OK, so I link /usr/include/d/tango/stdc to
 /usr/include/d/tango/std, but it still doesn't work. I get:
          $ ldc hello.d
          hello.d(8): Error: undefined identifier writefln
          hello.d(8): Error: function expected before (), not writefln
 of type int


Again, phobos doesn't support ldc.


     e. ldc only supports D v1.


Correct.


     f. All of this is too much for me. I give up on ldc.

 3. I can't get gdc to compile.
     a. First I have to get gcc-4.4.4 to compile, but that requires a 4
 year old version of automake. I have to downgrade.
     b. After that's fixed, I'm still running into errors that prevent a
 build. The errors change from changeset to changeset. So, I'm giving
 up on gdc.


I've only used gdc once, and it was a long time ago - I can't help here. 
Even then I do know that dmd is the only D compiler that supports D2 
currently. Gdc is getting there.


 Getting a D compiler to run on x86_64 Linux is too hard. I'm giving up
 on D.


Been there, done that :/


 I'm posting this message not as a plea for help, but to illustrate how
 hard it is to get D to run on Fedora.x86_64. The success of D depends
 on high quality, open source compilers being available (my belief),
 and so far, D doesn't seem to be mature enough to be considered, at
 least on Fedora.x86_64.


This will change most likely when dmd gets 64 bit support - this is 
progressing rapidly.
-- 
Robert
http://octarineparrot.com/
Sep 11 2010
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Vladimir G. Ivanovic wrote:


  I'm running Fedora 13.x86_64 and I've tried various ways of getting a
 D compiler to work. None have succeeded.
 
 1. a. I can't install dmd 2.048:
 

         error: Failed dependencies:
            gcc(x86-32) >= 4.2.3 is needed by dmd-2.048-0.i386
    I don't know what package will satisfy this dependency.


You need the i686 versions of some packages, probably start with libgcc (yum 
install libgcc.i686) and glibc, I don't remember which exactly are required. I 
have dmd running on 64 bit fedora just fine, it can work. There is also a
64-bit 
dmd in the making which should solve all those problems.


    b. dmd is a closed compiler. Not good. I'm really not comfortable
 running a compiler for which I don't have access to the source. The
 risk of undetected malware is too great.


dmd is not open source, but not closed source either :) You can compile it from 
scratch, the source is included with the zip file.
Sep 11 2010
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Lutger Wrote:


 You need the i686 versions of some packages, probably start with libgcc (yum 
 install libgcc.i686) and glibc, I don't remember which exactly are required. I 
 have dmd running on 64 bit fedora just fine, it can work. There is also a
64-bit 
 dmd in the making which should solve all those problems.


Based on a previous post by Walter, it sounds like he is working on just the
code generation for 64bit and does not see a need to make the compiler 64 bit
itself.
Sep 12 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Jesse Phillips (jessekphillips+D gmail.com)'s article

 Lutger Wrote:

 You need the i686 versions of some packages, probably start with libgcc (yum
 install libgcc.i686) and glibc, I don't remember which exactly are required. I
 have dmd running on 64 bit fedora just fine, it can work. There is also a
64-bit
 dmd in the making which should solve all those problems.


 Based on a previous post by Walter, it sounds like he is working on just the


code generation for 64bit and does not see a need to make the compiler 64 bit
itself.

The compiler already has been compilable as a 64-bit binary for months.  IMHO,
though, Walter should release a 64-bit pre-compiled binary to make life easy for
ppl with 64-bit installs.
Sep 12 2010
next sibling parent reply chmod+x <zip should.support.it> writes:
dsimcha Wrote:


 == Quote from Jesse Phillips (jessekphillips+D gmail.com)'s article

 Lutger Wrote:

 You need the i686 versions of some packages, probably start with libgcc (yum
 install libgcc.i686) and glibc, I don't remember which exactly are required. I
 have dmd running on 64 bit fedora just fine, it can work. There is also a
64-bit
 dmd in the making which should solve all those problems.


 Based on a previous post by Walter, it sounds like he is working on just the


 code generation for 64bit and does not see a need to make the compiler 64 bit
itself.
 
 The compiler already has been compilable as a 64-bit binary for months.  IMHO,
 though, Walter should release a 64-bit pre-compiled binary to make life easy
for
 ppl with 64-bit installs.


Another source of misery are the contents of the dmd zip file. Every time you
need to set +x flag for the executable. This is so ridiculous. Does the Creator
accept one bit binary patches to the distributions to make the solution a
reality? It's open source:

unzip dmdzip.zip
chmod +x executables
zip -r dmdzip *
Sep 12 2010
next sibling parent reply chmod+x <zip should.support.it> writes:
chmod+x Wrote:


 dsimcha Wrote:
 

 == Quote from Jesse Phillips (jessekphillips+D gmail.com)'s article

 Lutger Wrote:

 You need the i686 versions of some packages, probably start with libgcc (yum
 install libgcc.i686) and glibc, I don't remember which exactly are required. I
 have dmd running on 64 bit fedora just fine, it can work. There is also a
64-bit
 dmd in the making which should solve all those problems.


 Based on a previous post by Walter, it sounds like he is working on just the


 code generation for 64bit and does not see a need to make the compiler 64 bit
itself.
 
 The compiler already has been compilable as a 64-bit binary for months.  IMHO,
 though, Walter should release a 64-bit pre-compiled binary to make life easy
for
 ppl with 64-bit installs.


 
 Another source of misery are the contents of the dmd zip file. Every time you
need to set +x flag for the executable. This is so ridiculous. Does the Creator
accept one bit binary patches to the distributions to make the solution a
reality? It's open source:
 
 unzip dmdzip.zip
 chmod +x executables
 zip -r dmdzip *


Okey, the binary patch is actually 349 bytes. A repackaged dmd is also 523737
bytes smaller (dmd 2.048, repackaged with 7z). That would save 5% in bandwidth
cost and download time. Nobody cares.
Sep 12 2010
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Nobody would care if the download was fast. :) I always get around
~100-150KB/sec with downloads from digitalmars.com, even though I can
easily reach 0.5Mb/sec on other websites.

On Mon, Sep 13, 2010 at 3:52 AM, chmod+x <zip should.support.it> wrote:

 chmod+x Wrote:


 dsimcha Wrote:


 =3D=3D Quote from Jesse Phillips (jessekphillips+D gmail.com)'s articl=






e

 Lutger Wrote:

 You need the i686 versions of some packages, probably start with l=










ibgcc (yum

 install libgcc.i686) and glibc, I don't remember which exactly are=










 required. I

 have dmd running on 64 bit fedora just fine, it can work. There is=










 also a 64-bit

 dmd in the making which should solve all those problems.


 Based on a previous post by Walter, it sounds like he is working on =








just the

 code generation for 64bit and does not see a need to make the compiler=






 64 bit itself.

 The compiler already has been compilable as a 64-bit binary for months=






. =A0IMHO,

 though, Walter should release a 64-bit pre-compiled binary to make lif=






e easy for

 ppl with 64-bit installs.


 Another source of misery are the contents of the dmd zip file. Every tim=




e you need to set +x flag for the executable. This is so ridiculous. Does t=
he Creator accept one bit binary patches to the distributions to make the s=
olution a reality? It's open source:

 unzip dmdzip.zip
 chmod +x executables
 zip -r dmdzip *


 Okey, the binary patch is actually 349 bytes. A repackaged dmd is also 52=


3737 bytes smaller (dmd 2.048, repackaged with 7z). That would save 5% in b=
andwidth cost and download time. Nobody cares.





 Sep 12 2010



prev sibling  parent reply BCS <none anon.com>  writes:


Hello chmod+x,


 Another source of misery are the contents of the dmd zip file. Every
 time you need to set +x flag for the executable. This is so
 ridiculous. Does the Creator accept one bit binary patches to the
 distributions to make the solution a reality? It's open source:
 
 unzip dmdzip.zip
 chmod +x executables
 zip -r dmdzip *
 


IIRC the .zip is created on a windows box so that doesn't exactly work. :(

-- 
... <IXOYE><



 Sep 12 2010



 next sibling parent reply retard <re tard.com.invalid>  writes:


Mon, 13 Sep 2010 01:53:06 +0000, BCS wrote:


 Hello chmod+x,
 

 Another source of misery are the contents of the dmd zip file. Every
 time you need to set +x flag for the executable. This is so ridiculous.
 Does the Creator accept one bit binary patches to the distributions to
 make the solution a reality? It's open source:
 
 unzip dmdzip.zip
 chmod +x executables
 zip -r dmdzip *
 
 


 IIRC the .zip is created on a windows box so that doesn't exactly work.
 :(


FWIW, http://www.digitalmars.com/webnews/newsgroups.php?
art_group=digitalmars.D&article_id=114660 mentions that the build system 
uses *nix. I'm guessing the internal testing system uses modern *nix 
tools, but the final release is published on a windows machine. 



 Sep 12 2010



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 09/12/2010 10:05 PM, retard wrote:

 Mon, 13 Sep 2010 01:53:06 +0000, BCS wrote:


 Hello chmod+x,


 Another source of misery are the contents of the dmd zip file. Every
 time you need to set +x flag for the executable. This is so ridiculous.
 Does the Creator accept one bit binary patches to the distributions to
 make the solution a reality? It's open source:

 unzip dmdzip.zip
 chmod +x executables
 zip -r dmdzip *


 IIRC the .zip is created on a windows box so that doesn't exactly work.
 :(


 FWIW, http://www.digitalmars.com/webnews/newsgroups.php?
 art_group=digitalmars.D&article_id=114660 mentions that the build system
 uses *nix. I'm guessing the internal testing system uses modern *nix
 tools, but the final release is published on a windows machine.


My understanding is that Walter still uses Windows for the final 
packaging steps. It's ironic because he essentially uses cmd on Windows 
in conjunction with a few command-line tools of his use that emulate 
(badly, nonstandardly, and NIHily) 0.1% of Unix. I hope this to 
gradually change.

Andrei



 Sep 13 2010



  parent reply Justin Johansson <no spam.com>  writes:


On 13/09/2010 11:50 PM, Andrei Alexandrescu wrote:

 My understanding is that Walter still uses Windows for the final
 packaging steps. It's ironic because he essentially uses cmd on Windows
 in conjunction with a few command-line tools of his use that emulate
 (badly, nonstandardly, and NIHily) 0.1% of Unix. I hope this to
 gradually change.

 Andrei


If this is true I can well understand Walter's position.
My most prolific and effective coding days were back
when 80x25 character mode editing was the norm on a
DOS screen using the brilliant Brief (emacs-like) editor.

Ever since the invention of GUI and mouse and the depreciation
of keyboard skills, I feel that coding productivity has gone
backwards.

As for Unix command line skills that you allude to,
I also understand that one well-versed in the simplicity
of oft-scorned-upon DOS skills can work wonders over and
above others in the large.  Most unix scripts are not works
meant for understanding by the common man.  OTOH, simple
DOS scripts do oft make for the Fanfare for the Command Man.
Hey, perhaps Aaron Copland would have preferred to be a
DOS programmer.

Cheers
Justin Johansson



 Sep 13 2010



  parent reply Justin Johansson <no spam.com>  writes:


On 14/09/2010 12:55 AM, Justin Johansson wrote:

 meant for understanding by the common man. OTOH, simple
 DOS scripts do oft make for the Fanfare for the Command Man.
 Hey, perhaps Aaron Copland would have preferred to be a
 DOS programmer.



Seriously, that was just a serendipitous typo.
I meant the Common Man, not the "Command" Man
as in say a "command-line" man.  Maybe that wasn't
really a typo but some Freudian slip on my part. :-)

-- Justin



 Sep 13 2010



  parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


Command Man, and his sidekick, Clippy.

On Mon, Sep 13, 2010 at 5:29 PM, Justin Johansson <no spam.com> wrote:

 On 14/09/2010 12:55 AM, Justin Johansson wrote:

 meant for understanding by the common man. OTOH, simple
 DOS scripts do oft make for the Fanfare for the Command Man.
 Hey, perhaps Aaron Copland would have preferred to be a
 DOS programmer.



 Seriously, that was just a serendipitous typo.
 I meant the Common Man, not the "Command" Man
 as in say a "command-line" man. =A0Maybe that wasn't
 really a typo but some Freudian slip on my part. :-)

 -- Justin





 Sep 13 2010



  parent reply Justin Johansson <no spam.com>  writes:


He he.

Of course "SideKick" itself was some very popular TSR
utility wasn't it?  (But you didn't mean that?)
For the young people here, TSR is Terminate and Stay Resident,
an artifact of DOS 640KB days.  No doubt see Wikipedia for more.
Oh dear.  :-)

But Clippy? The only Clippy I know (and hated) it that
stupid yesteryear Word popup.  You meant that thing?

- Justin


On 14/09/2010 1:40 AM, Andrej Mitrovic wrote:

 Command Man, and his sidekick, Clippy.

 On Mon, Sep 13, 2010 at 5:29 PM, Justin Johansson<no spam.com>  wrote:

 On 14/09/2010 12:55 AM, Justin Johansson wrote:

 meant for understanding by the common man. OTOH, simple
 DOS scripts do oft make for the Fanfare for the Command Man.
 Hey, perhaps Aaron Copland would have preferred to be a
 DOS programmer.



 Seriously, that was just a serendipitous typo.
 I meant the Common Man, not the "Command" Man
 as in say a "command-line" man.  Maybe that wasn't
 really a typo but some Freudian slip on my part. :-)

 -- Justin







 Sep 13 2010



 next sibling parent  Robert Clipsham <robert octarineparrot.com>  writes:


On 13/09/10 21:43, Justin Johansson wrote:

 He he.

 Of course "SideKick" itself was some very popular TSR
 utility wasn't it? (But you didn't mean that?)
 For the young people here, TSR is Terminate and Stay Resident,
 an artifact of DOS 640KB days. No doubt see Wikipedia for more.
 Oh dear. :-)

 But Clippy? The only Clippy I know (and hated) it that
 stupid yesteryear Word popup. You meant that thing?

 - Justin


At some point during my childhood I acquired the nickname Clippy, it's 
followed me ever since. Fortunately very few people I know know the 
nickname commonly associated with that wretched paper clip, so it never 
causes too much dismay.

-- 
Robert
http://octarineparrot.com/



 Sep 13 2010



prev sibling  parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


Lost in translation.

Yes I was only kidding. :)

On Mon, Sep 13, 2010 at 10:43 PM, Justin Johansson <no spam.com> wrote:

 He he.

 Of course "SideKick" itself was some very popular TSR
 utility wasn't it? =A0(But you didn't mean that?)
 For the young people here, TSR is Terminate and Stay Resident,
 an artifact of DOS 640KB days. =A0No doubt see Wikipedia for more.
 Oh dear. =A0:-)

 But Clippy? The only Clippy I know (and hated) it that
 stupid yesteryear Word popup. =A0You meant that thing?

 - Justin


 On 14/09/2010 1:40 AM, Andrej Mitrovic wrote:

 Command Man, and his sidekick, Clippy.

 On Mon, Sep 13, 2010 at 5:29 PM, Justin Johansson<no spam.com> =A0wrote:

 On 14/09/2010 12:55 AM, Justin Johansson wrote:

 meant for understanding by the common man. OTOH, simple
 DOS scripts do oft make for the Fanfare for the Command Man.
 Hey, perhaps Aaron Copland would have preferred to be a
 DOS programmer.



 Seriously, that was just a serendipitous typo.
 I meant the Common Man, not the "Command" Man
 as in say a "command-line" man. =A0Maybe that wasn't
 really a typo but some Freudian slip on my part. :-)

 -- Justin









 Sep 13 2010



prev sibling next sibling parent  Jonathan M Davis <jmdavisprog gmail.com>  writes:


On Sunday 12 September 2010 18:53:06 BCS wrote:

 Hello chmod+x,
 

 Another source of misery are the contents of the dmd zip file. Every
 time you need to set +x flag for the executable. This is so
 ridiculous. Does the Creator accept one bit binary patches to the
 distributions to make the solution a reality? It's open source:
 
 unzip dmdzip.zip
 chmod +x executables
 zip -r dmdzip *


 
 IIRC the .zip is created on a windows box so that doesn't exactly work. :(


That would explain why the permissions are always messed up on dmd and phobos' 
files. There are some things that Windows does better than Linux. However, file 
permissions is _not_ one of them.

- Jonathan M Davis



 Sep 12 2010



prev sibling next sibling parent reply Russel Winder <russel russel.org.uk>  writes:


On Mon, 2010-09-13 at 01:53 +0000, BCS wrote:

 Hello chmod+x,
=20

 Another source of misery are the contents of the dmd zip file. Every
 time you need to set +x flag for the executable. This is so
 ridiculous. Does the Creator accept one bit binary patches to the
 distributions to make the solution a reality? It's open source:
=20
 unzip dmdzip.zip
 chmod +x executables
 zip -r dmdzip *
=20


=20
 IIRC the .zip is created on a windows box so that doesn't exactly work. :=


(

To be honest I don't give a fig about how the zipfile is created, the
scripts and executables for Linux should come with the execute
permission preset.  It is a ridiculous irritation that after unzipping a
supposed binary distribution, I then have to go and work out which files
to make executable.  If Windows cannot hack building a proper zipfile
then a machine with a proper operating system should be used so that the
zipfile is fit for its purpose.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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



 Sep 13 2010



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Russel Winder wrote:

 To be honest I don't give a fig about how the zipfile is created, the
 scripts and executables for Linux should come with the execute
 permission preset.  It is a ridiculous irritation that after unzipping a
 supposed binary distribution, I then have to go and work out which files
 to make executable.  If Windows cannot hack building a proper zipfile
 then a machine with a proper operating system should be used so that the
 zipfile is fit for its purpose.



Of course you're right, and I know it, I've just been lazy. I spent some time
on 
google and cannot find a zip program for Windows that enables one to set (or 
even display) the file attributes in zip files. Go figure. So I'll just write 
one using Phobos' std.zip.



 Sep 13 2010



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 09/13/2010 12:32 PM, Walter Bright wrote:

 Russel Winder wrote:

 To be honest I don't give a fig about how the zipfile is created, the
 scripts and executables for Linux should come with the execute
 permission preset. It is a ridiculous irritation that after unzipping a
 supposed binary distribution, I then have to go and work out which files
 to make executable. If Windows cannot hack building a proper zipfile
 then a machine with a proper operating system should be used so that the
 zipfile is fit for its purpose.



 Of course you're right, and I know it, I've just been lazy. I spent some
 time on google and cannot find a zip program for Windows that enables
 one to set (or even display) the file attributes in zip files. Go
 figure. So I'll just write one using Phobos' std.zip.


s/So I\'ll just write one using Phobos\' std.zip/So I\'ll just use zip 
on Linux and call it a day/

Waste of time doesn't begin to describe this.


Andrei



 Sep 13 2010



 next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Mon, 13 Sep 2010 17:11:30 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 09/13/2010 12:32 PM, Walter Bright wrote:

 Russel Winder wrote:

 To be honest I don't give a fig about how the zipfile is created, the
 scripts and executables for Linux should come with the execute
 permission preset. It is a ridiculous irritation that after unzipping a
 supposed binary distribution, I then have to go and work out which  
 files
 to make executable. If Windows cannot hack building a proper zipfile
 then a machine with a proper operating system should be used so that  
 the
 zipfile is fit for its purpose.



 Of course you're right, and I know it, I've just been lazy. I spent some
 time on google and cannot find a zip program for Windows that enables
 one to set (or even display) the file attributes in zip files. Go
 figure. So I'll just write one using Phobos' std.zip.


 s/So I\'ll just write one using Phobos\' std.zip/So I\'ll just use zip  
 on Linux and call it a day/


Better yet, have downloads for the different OSes.  Downloading all  
executables/compiled libs for all platforms when I'm interested in one  
makes no sense.  The current zipfile is at 10MB, if I trim out all but my  
OS, it is down to 5MB.

I assume you are not building all the compiled binaries and libs on a  
cross-compiler, so at this point, you have to go to each OS *anyways*.   
Then make the OSX and Linux ones tarballs.

Finally, the files that are extracted should be under a directory named  
for the compiler version.  For example, if I extract dmd.2.048.zip, it  
should extract into a dmd2.048 directory, not dmd2.

-Steve



 Sep 13 2010



 next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


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.

On Mon, Sep 13, 2010 at 11:25 PM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:

 Finally, the files that are extracted should be under a directory named f=


or

 the compiler version. =A0For example, if I extract dmd.2.048.zip, it shou=


ld

 extract into a dmd2.048 directory, not dmd2.

 -Steve





 Sep 13 2010



 next sibling parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Mon, 13 Sep 2010 17:44:57 -0400, Andrej Mitrovic  
<andrej.mitrovich gmail.com> 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.


I don't use an "archiver", I just unzip.  Then I have to rename.  I  
typically keep all versions I've extracted intact so I can test older  
versions against code.

I can see why that's not advantageous to simple users.  However, it's  
pretty standard to have source archives extract to a version-specific  
directory, and there's a lot of source code in the archive.  For one  
thing, you don't want to extract over the old one, since files that may be  
deleted in the new archive would not be removed by extracting.

The best way to handle installation for your purposes is to use an  
installer.  That will remove older files and install newer ones.

BTW, this is a non-issue on non-windows systems, because you have the  
universally accepted symlink method of pointing at a different version.

-Steve



 Sep 13 2010



prev sibling  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 09/13/2010 04:44 PM, 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.


What they often do is install the product with the full version in the 
directory name, and then write a link to the latest. So you'd have 
dmd2.048/ and then dmd2 a link to it.

Andrei



 Sep 13 2010



prev sibling  parent  Russel Winder <russel russel.org.uk>  writes:


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/DM=
D1 -> dmd-1.063/
drwx------ 10 russel russel 4096 2010-08-13 16:49 /home/users/russel/lib/dm=
d-1.063/
lrwxrwxrwx  1 russel russel    9 2010-08-13 18:33 /home/users/russel/lib/DM=
D2 -> dmd-2.048/
drwx------  9 russel russel 4096 2010-08-13 16:50 /home/users/russel/lib/dm=
d-2.048/
lrwxrwxrwx  1 russel russel   17 2010-08-13 16:52 /home/users/russel/lib.Li=
nux.ix86/DMD1 -> ../lib/DMD1/linux/
lrwxrwxrwx  1 russel russel   17 2010-08-13 16:52 /home/users/russel/lib.Li=
nux.ix86/DMD2 -> ../lib/DMD2/linux/
lrwxrwxrwx  1 russel russel   17 2010-08-13 16:55 /home/users/russel/lib.Li=
nux.x86_64/DMD1 -> ../lib/DMD1/linux/
lrwxrwxrwx  1 russel russel   17 2010-08-13 16:55 /home/users/russel/lib.Li=
nux.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.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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



 Sep 13 2010



prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com>  writes:


== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article

 On 09/13/2010 12:32 PM, Walter Bright wrote:

 Russel Winder wrote:

 To be honest I don't give a fig about how the zipfile is created, the
 scripts and executables for Linux should come with the execute
 permission preset. It is a ridiculous irritation that after unzipping a
 supposed binary distribution, I then have to go and work out which files
 to make executable. If Windows cannot hack building a proper zipfile
 then a machine with a proper operating system should be used so that the
 zipfile is fit for its purpose.



 Of course you're right, and I know it, I've just been lazy. I spent some
 time on google and cannot find a zip program for Windows that enables
 one to set (or even display) the file attributes in zip files. Go
 figure. So I'll just write one using Phobos' std.zip.


 s/So I\'ll just write one using Phobos\' std.zip/So I\'ll just use zip
 on Linux and call it a day/
 Waste of time doesn't begin to describe this.
 Andrei


Well, some people (like me) just plain prefer Windows over Linux.  That said,
there's always Cygwin.  I love the command line environment of Unix-like OS's,
but
prefer certain things about Windows like having stable ABIs for the basic OS
facilities (meaning that I can just download and unpack a binary and it
**consistently** just works across all modern Windows machines) and having
hardware support that doesn't suck horribly.  Cygwin lets me have it both ways.
Also, Cygwin's zip is probably compiled from the same source as any Linux
distro's, and should probably do what you need.



 Sep 13 2010



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 09/13/2010 04:28 PM, dsimcha wrote:

 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article

 On 09/13/2010 12:32 PM, Walter Bright wrote:

 Russel Winder wrote:

 To be honest I don't give a fig about how the zipfile is created, the
 scripts and executables for Linux should come with the execute
 permission preset. It is a ridiculous irritation that after unzipping a
 supposed binary distribution, I then have to go and work out which files
 to make executable. If Windows cannot hack building a proper zipfile
 then a machine with a proper operating system should be used so that the
 zipfile is fit for its purpose.



 Of course you're right, and I know it, I've just been lazy. I spent some
 time on google and cannot find a zip program for Windows that enables
 one to set (or even display) the file attributes in zip files. Go
 figure. So I'll just write one using Phobos' std.zip.


 s/So I\'ll just write one using Phobos\' std.zip/So I\'ll just use zip
 on Linux and call it a day/
 Waste of time doesn't begin to describe this.
 Andrei


 Well, some people (like me) just plain prefer Windows over Linux.  That said,
 there's always Cygwin.  I love the command line environment of Unix-like OS's,
but
 prefer certain things about Windows like having stable ABIs for the basic OS
 facilities (meaning that I can just download and unpack a binary and it
 **consistently** just works across all modern Windows machines) and having
 hardware support that doesn't suck horribly.  Cygwin lets me have it both ways.
 Also, Cygwin's zip is probably compiled from the same source as any Linux
 distro's, and should probably do what you need.


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.

Andrei



 Sep 13 2010



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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.



 Sep 13 2010



 next sibling parent  Daniel Gibson <metalcaedes gmail.com>  writes:


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



 Sep 13 2010



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 Sep 13 2010



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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.



 Sep 13 2010



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 Sep 13 2010



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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.



 Sep 13 2010



 next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


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



 Sep 14 2010



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 Sep 14 2010



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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.



 Sep 14 2010



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 Sep 14 2010



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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;
}



 Sep 14 2010



 next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


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



 Sep 14 2010



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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!



 Sep 14 2010



 next sibling parent reply chmod+x <zip should.support.it>  writes:


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!



 Sep 14 2010



  parent  Stephan <spam extrawurst.org>  writes:


On 15.09.2010 00:10, chmod+x wrote:

 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!


Btw. the LZMA SDK is public domain and could be integrated into phobos 
just as convenient as std.zip, right ?



 Sep 15 2010



prev sibling  parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


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


I did, seems to work good, thanks!

-Steve



 Sep 15 2010



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 Sep 14 2010



 next sibling parent  Walter Bright <newshound2 digitalmars.com>  writes:


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.



 Sep 14 2010



prev sibling  parent reply "Denis Koroskin" <2korden gmail.com>  writes:


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.



 Sep 14 2010



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 Sep 14 2010



prev sibling  parent reply retard <re tard.com.invalid>  writes:


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.



 Sep 14 2010



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 Sep 14 2010



  parent  "Nick Sabalausky" <a a.a>  writes:


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



 Sep 14 2010



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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.



 Sep 14 2010



 next sibling parent reply retard <re tard.com.invalid>  writes:


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.



 Sep 14 2010



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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.



 Sep 14 2010



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 Sep 14 2010



  parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


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



 Sep 14 2010



prev sibling  parent  BCS <none anon.com>  writes:


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



 Sep 14 2010



prev sibling  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 Sep 14 2010



prev sibling  parent reply Russel Winder <russel russel.org.uk>  writes:


On Mon, 2010-09-13 at 19:57 -0500, Andrei Alexandrescu wrote:
[ . . . ]

 Anyhow, I guess that underlines the necessity to do what everybody does=20
 - assemble the installer on the distribution platform, and have it only=20
 contain the files for that platform. An increasingly large audience is=20


[ . . . ]

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.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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



 Sep 13 2010



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 Sep 14 2010



prev sibling  parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


http://sourceforge.net/projects/getgnuwin32/files/ (it extracts some
files and download & install scripts).

The download takes a while though. There's some 400 packages in there,
or about ~1000 executables in my GNUWin32/bin folder. Crazy. :p

On Tue, Sep 14, 2010 at 12:15 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 On 09/13/2010 04:28 PM, dsimcha wrote:

 =3D=3D Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s
 article

 On 09/13/2010 12:32 PM, Walter Bright wrote:

 Russel Winder wrote:

 To be honest I don't give a fig about how the zipfile is created, the
 scripts and executables for Linux should come with the execute
 permission preset. It is a ridiculous irritation that after unzipping=










 a

 supposed binary distribution, I then have to go and work out which
 files
 to make executable. If Windows cannot hack building a proper zipfile
 then a machine with a proper operating system should be used so that
 the
 zipfile is fit for its purpose.



 Of course you're right, and I know it, I've just been lazy. I spent so=








me

 time on google and cannot find a zip program for Windows that enables
 one to set (or even display) the file attributes in zip files. Go
 figure. So I'll just write one using Phobos' std.zip.


 s/So I\'ll just write one using Phobos\' std.zip/So I\'ll just use zip
 on Linux and call it a day/
 Waste of time doesn't begin to describe this.
 Andrei


 Well, some people (like me) just plain prefer Windows over Linux. =A0Tha=




t

 said,
 there's always Cygwin. =A0I love the command line environment of Unix-li=




ke

 OS's, but
 prefer certain things about Windows like having stable ABIs for the basi=




c

 OS
 facilities (meaning that I can just download and unpack a binary and it
 **consistently** just works across all modern Windows machines) and havi=




ng

 hardware support that doesn't suck horribly. =A0Cygwin lets me have it b=




oth

 ways.
 Also, Cygwin's zip is probably compiled from the same source as any Linu=




x

 distro's, and should probably do what you need.


 There's nothing wrong about preferring Windows over Linux. I'm just sayin=


g

 (much like you) that badly reinventing Unix tools under Windows is not qu=


ite

 productive.

 Andrei





 Sep 13 2010



prev sibling  parent  Brad Roberts <braddr slice-2.puremagic.com>  writes:


On Mon, 13 Sep 2010, Andrei Alexandrescu wrote:


 On 09/13/2010 12:32 PM, Walter Bright wrote:

 Of course you're right, and I know it, I've just been lazy. I spent some
 time on google and cannot find a zip program for Windows that enables
 one to set (or even display) the file attributes in zip files. Go
 figure. So I'll just write one using Phobos' std.zip.


 
 s/So I\'ll just write one using Phobos\' std.zip/So I\'ll just use zip on
 Linux and call it a day/
 
 Waste of time doesn't begin to describe this.


Well, it does begin the description, but it's no where near the full, sad, 
story.



 Sep 13 2010



prev sibling  parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Sun, 12 Sep 2010 21:53:06 -0400, BCS <none anon.com> wrote:


 Hello chmod+x,


 Another source of misery are the contents of the dmd zip file. Every
 time you need to set +x flag for the executable. This is so
 ridiculous. Does the Creator accept one bit binary patches to the
 distributions to make the solution a reality? It's open source:
  unzip dmdzip.zip
 chmod +x executables
 zip -r dmdzip *


 IIRC the .zip is created on a windows box so that doesn't exactly work.  
 :(


I have written this script to aid in my installation of different dmd  
versions, and it's made it much less unpleasant.  Because in addition to  
the chmod+x, it always unpacks into dmd2, which may not be where you want  
to put it.  It installs dmd version X into the directory ~/dmd-X and  
automatically chmods the exes.  It assumes your files all download into  
the ~/Download directory.  It also will list all dmd versions you have  
downloaded if you don't specify a version.



if [ -z "$1" ]
then
     echo Error, must supply dmd version to unpack.
     error=1
else

     filename=~/Download/dmd.$1.zip

     if [ ! -f "$filename" ]
     then
         echo DMD version $1 does not exist.
         error=1
     fi
fi

if [ "$error" = "1" ]
then
     echo here are the valid versions:
     for fname in ~/Download/dmd.*.zip
     do
         basename $fname .zip | sed 's/dmd\.//g'
     done
     exit 1
fi

tmpdir=`mktemp -d /tmp/dmd.XXXXXXXX`
cd $tmpdir
unzip -q $filename
chmod 755 dmd2/linux/bin/*
mv dmd2 ~/dmd-$1
cd ~
rmdir $tmpdir
exit 0

-Steve



 Sep 13 2010



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2010-09-13 02:10, dsimcha wrote:

 == Quote from Jesse Phillips (jessekphillips+D gmail.com)'s article

 Lutger Wrote:

 You need the i686 versions of some packages, probably start with libgcc (yum
 install libgcc.i686) and glibc, I don't remember which exactly are required. I
 have dmd running on 64 bit fedora just fine, it can work. There is also a
64-bit
 dmd in the making which should solve all those problems.


 Based on a previous post by Walter, it sounds like he is working on just the


 code generation for 64bit and does not see a need to make the compiler 64 bit
itself.

 The compiler already has been compilable as a 64-bit binary for months.  IMHO,
 though, Walter should release a 64-bit pre-compiled binary to make life easy
for
 ppl with 64-bit installs.


Yes, I've been compiling dmd as a 64bit binary since I switched to a 
64bit system, Snow Leopard.

-- 
/Jacob Carlborg



 Sep 13 2010



prev sibling next sibling parent  Spacen Jasset <spacenjasset yahoo.co.uk>  writes:


On 11/09/2010 23:52, Vladimir G. Ivanovic wrote:

   I'm running Fedora 13.x86_64 and I've tried various ways of getting a
 D compiler to work. None have succeeded.

 1. a. I can't install dmd 2.048:


          error: Failed dependencies:
             gcc(x86-32)>= 4.2.3 is needed by dmd-2.048-0.i386
     I don't know what package will satisfy this dependency.
     b. dmd is a closed compiler. Not good. I'm really not comfortable
 running a compiler for which I don't have access to the source. The
 risk of undetected malware is too great.
     c. So, I give up on dmd.

 2. I can't run ldc because
     a. The ldc RPM requires Tango, even though this is not an RPM
 dependency for ldc, i.e. you can install ldc without any errors.
     b. The installation instructions for Fedora on the LDC web site are
 incorrect. "yum install ldc" works, but "yum install tango" doesn't.
 "yum install tango-devel" is the correct command. (This is the first
 time I've heard of<pkg>-devel without a corresponding<pkg>.)
     c. After I've gotten everything installed, it still doesn't work. I get
          $ ldc hello.d
          hello.d(5): Error: module stdio cannot read file 'std/stdio.d'
     d. OK, so I link /usr/include/d/tango/stdc to
 /usr/include/d/tango/std, but it still doesn't work. I get:
          $ ldc hello.d
          hello.d(8): Error: undefined identifier writefln
          hello.d(8): Error: function expected before (), not writefln
 of type int
     e. ldc only supports D v1.
     f. All of this is too much for me. I give up on ldc.

 3. I can't get gdc to compile.
     a. First I have to get gcc-4.4.4 to compile, but that requires a 4
 year old version of automake. I have to downgrade.
     b. After that's fixed, I'm still running into errors that prevent a
 build. The errors change from changeset to changeset. So, I'm giving
 up on gdc.

 Getting a D compiler to run on x86_64 Linux is too hard. I'm giving up
 on D.

 I'm posting this message not as a plea for help, but to illustrate how
 hard it is to get D to run on Fedora.x86_64. The success of D depends
 on high quality, open source compilers being available (my belief),
 and so far, D doesn't seem to be mature enough to be considered, at
 least on Fedora.x86_64.

 But, on the plus side, the existence of the book "The D Programming
 Language" is a major step in getting D accepted as a serious system
 programming language. Maybe installation will improve and D will move
 forward.

 --- Vladimir


when installing an rpm package it's usually best to try yum localinstall 
/downloads/dmd-2.048-0.i386.rpm first

and yum will then go off and fetch the dependencies if (a) they are 
available and (b) they have been specified properly in the rpm package



 Sep 12 2010



prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 09/11/2010 05:52 PM, Vladimir G. Ivanovic wrote:

   I'm running Fedora 13.x86_64 and I've tried various ways of getting a
 D compiler to work. None have succeeded.

 1. a. I can't install dmd 2.048:


          error: Failed dependencies:
             gcc(x86-32)>= 4.2.3 is needed by dmd-2.048-0.i386
     I don't know what package will satisfy this dependency.
     b. dmd is a closed compiler. Not good. I'm really not comfortable
 running a compiler for which I don't have access to the source. The
 risk of undetected malware is too great.
     c. So, I give up on dmd.


Apologies for the poor experience. It's because you don't have the 
32-bit portability libraries on your 64-bit system. A 64-bit edition is 
in the works and would certainly make everything smoother.

In the meantime you'd need to run:

sudo apt-get install gcc-multilib libc6-i386 lib6-dev-i386
sudo apt-get install gcc-multilib
sudo apt-get install g++-multilib

We need to add these instructions to the download page.


Andrei



 Sep 12 2010



 next sibling parent  Daniel Gibson <metalcaedes gmail.com>  writes:


Andrei Alexandrescu schrieb:

 On 09/11/2010 05:52 PM, Vladimir G. Ivanovic wrote:

   I'm running Fedora 13.x86_64 and I've tried various ways of getting a
 D compiler to work. None have succeeded.

 1. a. I can't install dmd 2.048:


          error: Failed dependencies:
             gcc(x86-32)>= 4.2.3 is needed by dmd-2.048-0.i386
     I don't know what package will satisfy this dependency.
     b. dmd is a closed compiler. Not good. I'm really not comfortable
 running a compiler for which I don't have access to the source. The
 risk of undetected malware is too great.
     c. So, I give up on dmd.


 
 Apologies for the poor experience. It's because you don't have the 
 32-bit portability libraries on your 64-bit system. A 64-bit edition is 
 in the works and would certainly make everything smoother.
 
 In the meantime you'd need to run:
 
 sudo apt-get install gcc-multilib libc6-i386 lib6-dev-i386
 sudo apt-get install gcc-multilib
 sudo apt-get install g++-multilib
 
 We need to add these instructions to the download page.
 
 
 Andrei


The information is there:
http://www.digitalmars.com/d/2.0/dmd-linux.html#installation

However apt-get is Debian/Ubuntu specific, so these commands are not 
*directly* applicable for fedora.
However equivalent packages should be available on fedora and instead of 
apt-get install it's something like yum install gcc-multilib etc (or 
whatever the packages are called there).

Cheers,
- Daniel



 Sep 12 2010



prev sibling next sibling parent reply Russel Winder <russel russel.org.uk>  writes:


On Sun, 2010-09-12 at 12:12 -0500, Andrei Alexandrescu wrote:

 On 09/11/2010 05:52 PM, Vladimir G. Ivanovic wrote:

   I'm running Fedora 13.x86_64 and I've tried various ways of getting a
 D compiler to work. None have succeeded.

 1. a. I can't install dmd 2.048:


          error: Failed dependencies:
             gcc(x86-32)>=3D 4.2.3 is needed by dmd-2.048-0.i386
     I don't know what package will satisfy this dependency.
     b. dmd is a closed compiler. Not good. I'm really not comfortable
 running a compiler for which I don't have access to the source. The
 risk of undetected malware is too great.
     c. So, I give up on dmd.


=20
 Apologies for the poor experience. It's because you don't have the=20
 32-bit portability libraries on your 64-bit system. A 64-bit edition is=20
 in the works and would certainly make everything smoother.
=20
 In the meantime you'd need to run:
=20
 sudo apt-get install gcc-multilib libc6-i386 lib6-dev-i386
 sudo apt-get install gcc-multilib
 sudo apt-get install g++-multilib
=20
 We need to add these instructions to the download page.


I wonder if part of the problem for OP was using rpm rather than yum?  I
found using aptitude on Ubuntu and Debian on x86_64 it was relatively
easy to get the downloaded D distribution working, all that was needed
was to install the 32-bit libraries and the multilib GCC.  Not a big
deal to be honest.

Of course this only gives a 32-bit D, which isn't really what is needed
these days on a 64-bit platform.  So the sooner the 64-bit version of D
comes out, the better -- preferably last year ;-)


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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



 Sep 12 2010



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


Russel Winder wrote:

 Of course this only gives a 32-bit D, which isn't really what is needed
 these days on a 64-bit platform.  So the sooner the 64-bit version of D
 comes out, the better -- preferably last year ;-)


Don't I know it!



 Sep 12 2010



prev sibling  parent reply Ellery Newcomer <ellery-newcomer utulsa.edu>  writes:


On 09/12/2010 12:12 PM, Andrei Alexandrescu wrote:

 Apologies for the poor experience. It's because you don't have the
 32-bit portability libraries on your 64-bit system. A 64-bit edition is
 in the works and would certainly make everything smoother.

 In the meantime you'd need to run:

 sudo apt-get install gcc-multilib libc6-i386 lib6-dev-i386
 sudo apt-get install gcc-multilib
 sudo apt-get install g++-multilib

 We need to add these instructions to the download page.


 Andrei


Andrei, the only reason he's running into problems is because in the rpm 
script there is the line

Requires:       gcc(x86-32)

which requires gcc to be 32 bit. I've been running dmd with 64 bit gcc 
on fedora for years without problems. Change the line to

Requires:       gcc

and it will work fine.



 Sep 15 2010



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 9/15/10 22:58 CDT, Ellery Newcomer wrote:

 On 09/12/2010 12:12 PM, Andrei Alexandrescu wrote:

 Apologies for the poor experience. It's because you don't have the
 32-bit portability libraries on your 64-bit system. A 64-bit edition is
 in the works and would certainly make everything smoother.

 In the meantime you'd need to run:

 sudo apt-get install gcc-multilib libc6-i386 lib6-dev-i386
 sudo apt-get install gcc-multilib
 sudo apt-get install g++-multilib

 We need to add these instructions to the download page.


 Andrei


 Andrei, the only reason he's running into problems is because in the rpm
 script there is the line

 Requires: gcc(x86-32)

 which requires gcc to be 32 bit. I've been running dmd with 64 bit gcc
 on fedora for years without problems. Change the line to

 Requires: gcc

 and it will work fine.


Ha, good tip. Thanks!

Andrei



 Sep 15 2010



prev sibling next sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se>  writes:


Vladimir G. Ivanovic wrote:

  I'm running Fedora 13.x86_64 and I've tried various ways of getting a
 D compiler to work. None have succeeded.

 1. a. I can't install dmd 2.048:
 

         error: Failed dependencies:
            gcc(x86-32) >= 4.2.3 is needed by dmd-2.048-0.i386
    I don't know what package will satisfy this dependency.
    b. dmd is a closed compiler. Not good. I'm really not comfortable
 running a compiler for which I don't have access to the source. The
 risk of undetected malware is too great.
    c. So, I give up on dmd.


Because DMD is a 32-bit compiler and you have a 64-bit OS install ?
yum whatprovides "gcc(x86-32)" tells (or rpm --aid -Uvh before it).

Currently gcc-4.4.4-10.fc13.i686.rpm provides the dependency, to
use --aid you need rpmdb-fedora and a RPM version that supports it.


 2. I can't run ldc because
    a. The ldc RPM requires Tango, even though this is not an RPM
 dependency for ldc, i.e. you can install ldc without any errors.
    b. The installation instructions for Fedora on the LDC web site are
 incorrect. "yum install ldc" works, but "yum install tango" doesn't.
 "yum install tango-devel" is the correct command. (This is the first
 time I've heard of <pkg>-devel without a corresponding <pkg>.)


This is because Tango (or Phobos) only provides static libraries,
if there had been a shared library it would have been "tango"...

In the previous packaging one of the "runtime" library providers
were required, since the compiler is not very useful without one.


    c. After I've gotten everything installed, it still doesn't work. I get
         $ ldc hello.d
         hello.d(5): Error: module stdio cannot read file 'std/stdio.d'
    d. OK, so I link /usr/include/d/tango/stdc to
 /usr/include/d/tango/std, but it still doesn't work. I get:
         $ ldc hello.d
         hello.d(8): Error: undefined identifier writefln
         hello.d(8): Error: function expected before (), not writefln
 of type int
    e. ldc only supports D v1.
    f. All of this is too much for me. I give up on ldc.


But LDC is the D compiler that Fedora has chosen for inclusion in 14...
See https://fedoraproject.org/wiki/Features/D_Programming for details.


 3. I can't get gdc to compile.
    a. First I have to get gcc-4.4.4 to compile, but that requires a 4
 year old version of automake. I have to downgrade.
    b. After that's fixed, I'm still running into errors that prevent a
 build. The errors change from changeset to changeset. So, I'm giving
 up on gdc.


If you use an older GCC, it is much easier. (GCC 4.1.2 was supported)
There's some GDC packages available at http://gdcgnu.sourceforge.net/


 Getting a D compiler to run on x86_64 Linux is too hard. I'm giving up
 on D.


Seems like you ran into these, all at once:
- 32-bit compiler
- static runtime
- wrong stdlib
- older version
Some of these will be fixed, when/if updated.

--anders



 Sep 12 2010



  parent  =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se>  writes:


 yum whatprovides "gcc(x86-32)" tells (or rpm --aid -Uvh before it).


Make that "yum provides", I was thinking of "rpm --what-provides"...

--anders



 Sep 12 2010



prev sibling  parent reply bearophile <bearophileHUGS lycos.com>  writes:


Andrei Alexandrescu:


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


If you rename a txt file as .exe, if you click on it Windows tries to run it.



 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.


+1, despite there is more than one way to give suffix to C++ files.
There is a bug report on this, not written by me.
Having source code simple, clean, tidy, and readable is important for all open
source projects, because that increases the probability of finding
collaborators. Giving a sensible suffix to files is a starting point for that.

Bye,
bearophile



 Sep 13 2010



  parent reply Justin Johansson <no spam.com>  writes:


On 14/09/2010 11:07 AM, bearophile wrote:

 Andrei Alexandrescu:


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


 If you rename a txt file as .exe, if you click on it Windows tries to run it.



 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.


 +1, despite there is more than one way to give suffix to C++ files.
 There is a bug report on this, not written by me.
 Having source code simple, clean, tidy, and readable is important for all open
source projects, because that increases the probability of finding
collaborators. Giving a sensible suffix to files is a starting point for that.

 Bye,
 bearophile


There is not a lot of use in creating your own "readable" file suffices
(alla file extensions).  Unless your file extension is known on the
platform you are using then there may be no hope of reasonable opening
your file with the requisite application on another platform.

Say if your name was Robin, would you name your text files as .bat ?

Holy Gotham (says Batman), am I to know what application to open that with?

Cheers,
Justin Johansson



 Sep 15 2010



 next sibling parent  Justin Johansson <no spam.com>  writes:


On 15/09/2010 10:38 PM, Justin Johansson wrote:

 There is not a lot of use in creating your own "readable" file suffices
 (alla file extensions). Unless your file extension is known on the
 platform you are using then there may be no hope of reasonable opening
 your file with the requisite application on another platform.

 Say if your name was Robin, would you name your text files as .bat ?

 Holy Gotham (says Batman), am I to know what application to open that with?

 Cheers,
 Justin Johansson


Of course the Penguin always know how to open a file ...
especially for evil purposes :-)



 Sep 15 2010



prev sibling  parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Wednesday, September 15, 2010 06:08:49 Justin Johansson wrote:

 On 14/09/2010 11:07 AM, bearophile wrote:

 Andrei Alexandrescu:

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


 
 If you rename a txt file as .exe, if you click on it Windows tries to run
 it.
 

 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.


 
 +1, despite there is more than one way to give suffix to C++ files.
 There is a bug report on this, not written by me.
 Having source code simple, clean, tidy, and readable is important for all
 open source projects, because that increases the probability of finding
 collaborators. Giving a sensible suffix to files is a starting point for
 that.
 
 Bye,
 bearophile


 
 There is not a lot of use in creating your own "readable" file suffices
 (alla file extensions).  Unless your file extension is known on the
 platform you are using then there may be no hope of reasonable opening
 your file with the requisite application on another platform.
 
 Say if your name was Robin, would you name your text files as .bat ?
 
 Holy Gotham (says Batman), am I to know what application to open that with?
 
 Cheers,
 Justin Johansson


If you're on a non-Windows system, the mime-type becomes far more important
than 
the extension. Most programs in Linux (and I believe MacOS X as well) don't
care 
about the extension. They just look at the mime type. Extensions become almost 
entirely a thing for the user. So, whether your file is useable becomes more of 
an issue of known mime type than known extension. Still, you don't generally 
want to just be making up extensions.

- Jonathan M davis



 Sep 15 2010



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.225.1284568096.858.digitalmars-d puremagic.com...

 If you're on a non-Windows system, the mime-type becomes far more 
 important than
 the extension. Most programs in Linux (and I believe MacOS X as well) 
 don't care
 about the extension. They just look at the mime type. Extensions become 
 almost
 entirely a thing for the user. So, whether your file is useable becomes 
 more of
 an issue of known mime type than known extension. Still, you don't 
 generally
 want to just be making up extensions.


I didn't think unix file systems had a concept of mime type.



 Sep 15 2010



 next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr>  writes:


Nick Sabalausky wrote:

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message=20
 news:mailman.225.1284568096.858.digitalmars-d puremagic.com...

 If you're on a non-Windows system, the mime-type becomes far more=20
 important than
 the extension. Most programs in Linux (and I believe MacOS X as well) =





 don't care
 about the extension. They just look at the mime type. Extensions becom=




e=20

 almost
 entirely a thing for the user. So, whether your file is useable become=




s=20

 more of
 an issue of known mime type than known extension. Still, you don't=20
 generally
 want to just be making up extensions.


=20
 I didn't think unix file systems had a concept of mime type.
=20


	It doesn't, but Unix tools use the file contents to determine the
mime type and then choose the app associated to the mime type.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr



 Sep 15 2010



 next sibling parent  retard <re tard.com.invalid>  writes:


Wed, 15 Sep 2010 22:35:27 +0200, Jérôme M. Berger wrote:


 Nick Sabalausky wrote:

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.225.1284568096.858.digitalmars-d puremagic.com...

 If you're on a non-Windows system, the mime-type becomes far more
 important than
 the extension. Most programs in Linux (and I believe MacOS X as well)
 don't care
 about the extension. They just look at the mime type. Extensions
 become almost
 entirely a thing for the user. So, whether your file is useable
 becomes more of
 an issue of known mime type than known extension. Still, you don't
 generally
 want to just be making up extensions.


 I didn't think unix file systems had a concept of mime type.
 


 	It doesn't, but Unix tools use the file contents to determine the
 mime type and then choose the app associated to the mime type.


Unix tools?



 Sep 15 2010



prev sibling  parent reply KennyTM~ <kennytm gmail.com>  writes:


On Sep 16, 10 04:35, "Jérôme M. Berger" wrote:

 Nick Sabalausky wrote:

 "Jonathan M Davis"<jmdavisProg gmx.com>  wrote in message
 news:mailman.225.1284568096.858.digitalmars-d puremagic.com...

 If you're on a non-Windows system, the mime-type becomes far more
 important than
 the extension. Most programs in Linux (and I believe MacOS X as well)
 don't care
 about the extension. They just look at the mime type. Extensions become
 almost
 entirely a thing for the user. So, whether your file is useable becomes
 more of
 an issue of known mime type than known extension. Still, you don't
 generally
 want to just be making up extensions.


 I didn't think unix file systems had a concept of mime type.


 	It doesn't, but Unix tools use the file contents to determine the
 mime type and then choose the app associated to the mime type.

 		Jerome


Please don't confuse Unix with a distro.



 Sep 15 2010



  parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr>  writes:


KennyTM~ wrote:

 On Sep 16, 10 04:35, "J=C3=A9r=C3=B4me M. Berger" wrote:

 Nick Sabalausky wrote:

 I didn't think unix file systems had a concept of mime type.


     It doesn't, but Unix tools use the file contents to determine the
 mime type and then choose the app associated to the mime type.

         Jerome


=20
 Please don't confuse Unix with a distro.


	Which distro? I used the terms "Unix tools" because it transcends
distributions and Unices. It is as true on Ubuntu as on *BSD or
Solaris...

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr



 Sep 16 2010



  parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr>  writes:


J=C3=A9r=C3=B4me M. Berger wrote:

 KennyTM~ wrote:

 On Sep 16, 10 04:35, "J=C3=A9r=C3=B4me M. Berger" wrote:

 Nick Sabalausky wrote:

 I didn't think unix file systems had a concept of mime type.


     It doesn't, but Unix tools use the file contents to determine the=







 mime type and then choose the app associated to the mime type.

         Jerome


 Please don't confuse Unix with a distro.


=20
 	Which distro? I used the terms "Unix tools" because it transcends
 distributions and Unices. It is as true on Ubuntu as on *BSD or
 Solaris...
=20
 		Jerome


BTW: http://www.darwinsys.com/file/
<quote>
Unlike most GUI systems, command-line UNIX systems - with this
program leading the charge - don't rely on filename extentions to
tell you the type of a file, but look at the file's actual contents.
</quote>

	They say "UNIX systems", they don't say "Ubuntu" (which I don't use
anyway).

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr



 Sep 16 2010



  parent reply KennyTM~ <kennytm gmail.com>  writes:


On Sep 17, 10 02:26, "Jérôme M. Berger" wrote:

 Jérôme M. Berger wrote:

 KennyTM~ wrote:

 On Sep 16, 10 04:35, "Jérôme M. Berger" wrote:

 Nick Sabalausky wrote:

 I didn't think unix file systems had a concept of mime type.


      It doesn't, but Unix tools use the file contents to determine the
 mime type and then choose the app associated to the mime type.

          Jerome


 Please don't confuse Unix with a distro.


 	Which distro? I used the terms "Unix tools" because it transcends
 distributions and Unices. It is as true on Ubuntu as on *BSD or
 Solaris...

 		Jerome


 BTW: http://www.darwinsys.com/file/
 <quote>
 Unlike most GUI systems, command-line UNIX systems - with this
 program leading the charge - don't rely on filename extentions to
 tell you the type of a file, but look at the file's actual contents.
 </quote>

 	They say "UNIX systems", they don't say "Ubuntu" (which I don't use
 anyway).

 		Jerome


This describes the file(1) command, which the job is to inspect the file 
content and conclude what kind of file it actually is.

But this is just one particular UNIX command. The command line interface 
in general does not care about the type of a regular file. This is 
needed in the GUI, but it is outside of the common parts of UNIX. There 
is no rule saying that a file manager must use file(1) or MIME type or 
extensions to determine the file type.



 Sep 16 2010



  parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr>  writes:


KennyTM~ wrote:

 On Sep 17, 10 02:26, "J=C3=A9r=C3=B4me M. Berger" wrote:

 J=C3=A9r=C3=B4me M. Berger wrote:

 KennyTM~ wrote:

 On Sep 16, 10 04:35, "J=C3=A9r=C3=B4me M. Berger" wrote:

 Nick Sabalausky wrote:

 I didn't think unix file systems had a concept of mime type.


      It doesn't, but Unix tools use the file contents to determine =










the

 mime type and then choose the app associated to the mime type.

          Jerome


 Please don't confuse Unix with a distro.


     Which distro? I used the terms "Unix tools" because it transcends=







 distributions and Unices. It is as true on Ubuntu as on *BSD or
 Solaris...

         Jerome


 BTW: http://www.darwinsys.com/file/
 <quote>
 Unlike most GUI systems, command-line UNIX systems - with this
 program leading the charge - don't rely on filename extentions to
 tell you the type of a file, but look at the file's actual contents.
 </quote>

     They say "UNIX systems", they don't say "Ubuntu" (which I don't us=




e

 anyway).

         Jerome


=20
 This describes the file(1) command, which the job is to inspect the fil=


e

 content and conclude what kind of file it actually is.
=20


	I suggest you re-read the paragraph I posted. Although it was taken
from the "file" web site, it states clearly that other apps look at
the file contents instead of the extension. Of course, some apps
don't care about the file type but some do. And most of those that
do care don't use the extension.


 But this is just one particular UNIX command. The command line interfac=


e

 in general does not care about the type of a regular file. This is
 needed in the GUI, but it is outside of the common parts of UNIX. There=



 is no rule saying that a file manager must use file(1) or MIME type or
 extensions to determine the file type.
=20


	True, but then, there is no rule that says that on windows a file
manager must use the extension. However, on Windows, all the file
managers I've tried have used the extension (actually, most of the
time they don't use the extension themselves, they simply ask
Windows to open the file and Windows uses the extension), whereas on
UNIX most file managers use the file contents (usually, they don't
use the file command, but instead rely on libmagic directly) and
most applications will ignore the extension when asked to open a
file (OK, some Windows applications do that too but on *NIX most of
them do).

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr



 Sep 17 2010



 next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Friday 17 September 2010 13:24:36 J=E9r=F4me M. Berger wrote:

 KennyTM~ wrote:

 On Sep 17, 10 02:26, "J=E9r=F4me M. Berger" wrote:

 J=E9r=F4me M. Berger wrote:

 KennyTM~ wrote:

 On Sep 16, 10 04:35, "J=E9r=F4me M. Berger" wrote:

 Nick Sabalausky wrote:

 I didn't think unix file systems had a concept of mime type.
=20


      It doesn't, but Unix tools use the file contents to determine
      the
=20
 mime type and then choose the app associated to the mime type.
=20
          Jerome


=20
 Please don't confuse Unix with a distro.
=20


     Which distro? I used the terms "Unix tools" because it transcends
=20
 distributions and Unices. It is as true on Ubuntu as on *BSD or
 Solaris...
=20
         Jerome


=20
 BTW: http://www.darwinsys.com/file/
 <quote>
 Unlike most GUI systems, command-line UNIX systems - with this
 program leading the charge - don't rely on filename extentions to
 tell you the type of a file, but look at the file's actual contents.
 </quote>
=20
     They say "UNIX systems", they don't say "Ubuntu" (which I don't use
=20
 anyway).
=20
         Jerome


=20
 This describes the file(1) command, which the job is to inspect the file
 content and conclude what kind of file it actually is.


=20
 	I suggest you re-read the paragraph I posted. Although it was taken
 from the "file" web site, it states clearly that other apps look at
 the file contents instead of the extension. Of course, some apps
 don't care about the file type but some do. And most of those that
 do care don't use the extension.
=20

 But this is just one particular UNIX command. The command line interface
 in general does not care about the type of a regular file. This is
 needed in the GUI, but it is outside of the common parts of UNIX. There
 is no rule saying that a file manager must use file(1) or MIME type or
 extensions to determine the file type.


=20
 	True, but then, there is no rule that says that on windows a file
 manager must use the extension. However, on Windows, all the file
 managers I've tried have used the extension (actually, most of the
 time they don't use the extension themselves, they simply ask
 Windows to open the file and Windows uses the extension), whereas on
 UNIX most file managers use the file contents (usually, they don't
 use the file command, but instead rely on libmagic directly) and
 most applications will ignore the extension when asked to open a
 file (OK, some Windows applications do that too but on *NIX most of
 them do).
=20
 		Jerome


It's so ingrained in Unix  that extension isn't what matters that it totall=
y=20
threw me of at one point when I couldn't get my flac files to play in audac=
ious.=20
The file browser clearly indicated that they were flac files, but audacious=
=20
wouldn't put them in its playlist. It turns out that audacious _does_ use t=
he=20
extension, and I had screwed up with the settings on my CD ripper such that=
=20
there was no extension on the files, so audacious didn't think that it coul=
d read=20
them. That's the only time that I've ever seen that sort of problem in Linu=
x.=20
Pretty much everything uses mime type.

=2D Jonathan M Davis



 Sep 17 2010



prev sibling  parent reply KennyTM~ <kennytm gmail.com>  writes:


On Sep 18, 10 04:24, "Jérôme M. Berger" wrote:

 KennyTM~ wrote:

 On Sep 17, 10 02:26, "Jérôme M. Berger" wrote:




[-snip-]

 This describes the file(1) command, which the job is to inspect the file
 content and conclude what kind of file it actually is.


 	I suggest you re-read the paragraph I posted. Although it was taken
 from the "file" web site, it states clearly that other apps look at
 the file contents instead of the extension. Of course, some apps
 don't care about the file type but some do. And most of those that
 do care don't use the extension.


Many apps in Windows doesn't care about the file extension too. You can 
rename a bitmap to 'file.txt' and still can open it in MS Paint. This is 
irrelevant to UNIX.


 But this is just one particular UNIX command. The command line interface
 in general does not care about the type of a regular file. This is
 needed in the GUI, but it is outside of the common parts of UNIX. There
 is no rule saying that a file manager must use file(1) or MIME type or
 extensions to determine the file type.


 	True, but then, there is no rule that says that on windows a file
 manager must use the extension. However, on Windows, all the file
 managers I've tried have used the extension (actually, most of the
 time they don't use the extension themselves, they simply ask
 Windows to open the file and Windows uses the extension), whereas on
 UNIX most file managers use the file contents (usually, they don't
 use the file command, but instead rely on libmagic directly) and
 most applications will ignore the extension when asked to open a
 file (OK, some Windows applications do that too but on *NIX most of
 them do).

 		Jerome


Mac OS X is UNIX. Finder cares about the file extension (besides metadata).



 Sep 18 2010



  parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr>  writes:


KennyTM~ wrote:

     True, but then, there is no rule that says that on windows a file
 manager must use the extension. However, on Windows, all the file
 managers I've tried have used the extension (actually, most of the
 time they don't use the extension themselves, they simply ask
 Windows to open the file and Windows uses the extension), whereas on
 UNIX most file managers use the file contents (usually, they don't
 use the file command, but instead rely on libmagic directly) and
 most applications will ignore the extension when asked to open a
 file (OK, some Windows applications do that too but on *NIX most of
 them do).

         Jerome


=20
 Mac OS X is UNIX. Finder cares about the file extension (besides metada=


ta).

most: You can use *most* to refer to the majority of a group of
things or people or the largest part of something.

One counter example does not invalidate my point. Especially when
the example is invalid: MacOS X is *not* UNIX. True, the low level
parts are UNIX-based, which makes it easy to port UNIX apps, however
that doesn't make the whole into a UNIX. In particular, finder was
ported from older versions of MacOS and inherits a large part of its
behaviour from those older versions.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr



 Sep 20 2010



  parent reply KennyTM~ <kennytm gmail.com>  writes:


On Sep 21, 10 00:04, "Jérôme M. Berger" wrote:

 KennyTM~ wrote:

      True, but then, there is no rule that says that on windows a file
 manager must use the extension. However, on Windows, all the file
 managers I've tried have used the extension (actually, most of the
 time they don't use the extension themselves, they simply ask
 Windows to open the file and Windows uses the extension), whereas on
 UNIX most file managers use the file contents (usually, they don't
 use the file command, but instead rely on libmagic directly) and
 most applications will ignore the extension when asked to open a
 file (OK, some Windows applications do that too but on *NIX most of
 them do).

          Jerome


 Mac OS X is UNIX. Finder cares about the file extension (besides metadata).


 most: You can use *most* to refer to the majority of a group of
 things or people or the largest part of something.

 One counter example does not invalidate my point. Especially when
 the example is invalid: MacOS X is *not* UNIX. True, the low level
 parts are UNIX-based, which makes it easy to port UNIX apps, however
 that doesn't make the whole into a UNIX. In particular, finder was
 ported from older versions of MacOS and inherits a large part of its
 behaviour from those older versions.

 		Jerome


Your definition of Unix is wrong then. Unix *only* specifies the API 
(system interface and headers) and the command-line utilities. You *are* 
confusing Unix and the distro.

Ref: http://www.opengroup.org/onlinepubs/9699919799/



 Sep 20 2010



  parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr>  writes:


KennyTM~ wrote:

 Your definition of Unix is wrong then. Unix *only* specifies the API
 (system interface and headers) and the command-line utilities. You *are=


*

 confusing Unix and the distro.
=20
 Ref: http://www.opengroup.org/onlinepubs/9699919799/


	That's not UNIX, that's POSIX! And by that definition, Windows
would be UNIX too...

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr



 Sep 20 2010



 next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Monday, September 20, 2010 10:43:36 J=E9r=F4me M. Berger wrote:

 KennyTM~ wrote:

 Your definition of Unix is wrong then. Unix *only* specifies the API
 (system interface and headers) and the command-line utilities. You *are*
 confusing Unix and the distro.
=20
 Ref: http://www.opengroup.org/onlinepubs/9699919799/


=20
 	That's not UNIX, that's POSIX! And by that definition, Windows
 would be UNIX too...
=20
 		Jerome


Actually, technically, for an OS to be unix, it not only has to follow the=
=20
appropriate specification, but someone has to foot the bill for it be certi=
fied.=20
So, most OSes which are essentially unix aren't technically unix - Linux be=
ing a=20
prime example. Personally, I think that it's a bit silly, but that's the wa=
y it=20
is (since Unix is trademarked).  Posix is a separate - albeit related - spe=
c.

Most of the stuff which cares about file extensions or mime types is going =
to be=20
GUI-related and that has pretty much nothing to do with either unix or posi=
x.=20
However, it is typical for Linux systems (and I assume BSD systems) to use =
the=20
mime type primarily rather than the file extension. I had thought that Mac =
OS X=20
was the same in that regard, but I guess not. I don't know though, since I =
don't=20
use it.

=2D Jonathan M Davis



 Sep 20 2010



  parent  Michel Fortin <michel.fortin michelf.com>  writes:


On 2010-09-20 13:59:35 -0400, Jonathan M Davis <jmdavisProg gmx.com> said:


 Most of the stuff which cares about file extensions or mime types is going
 to be GUI-related and that has pretty much nothing to do with either 
 unix or posi
 x. However, it is typical for Linux systems (and I assume BSD systems) 
 to use the
 mime type primarily rather than the file extension. I had thought that Mac OS X
 was the same in that regard, but I guess not. I don't know though, since I
 don't use it.


Mac OS X applications mostly use UTIs. For files, the Uniform Type 
Identifier is determined by the file extension primarily, but can also 
be affected the executable bit being present and as a fallback by the 
older OSType metadata legacy from classic Mac OS. The UTI itself isn't 
stored with the file, it is determined on demand.

UTIs are also used to represent various data types in other parts of 
the system, notably for copy-paste and drag and drop, and files 
received from the Internet where the MIME type is mapped to a UTI.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Sep 20 2010



prev sibling  parent reply KennyTM~ <kennytm gmail.com>  writes:


On Sep 21, 10 01:43, "Jérôme M. Berger" wrote:

 KennyTM~ wrote:

 Your definition of Unix is wrong then. Unix *only* specifies the API
 (system interface and headers) and the command-line utilities. You *are*
 confusing Unix and the distro.

 Ref: http://www.opengroup.org/onlinepubs/9699919799/


 	That's not UNIX, that's POSIX! And by that definition, Windows
 would be UNIX too...

 		Jerome


Looks like we have no point keep discussing on this since we have 
different view on what Unix means.

My points are just:
  - in the CLI the type of regular file is usually irrelevant.
  - Unix (i.e. POSIX) doesn't specify how should the desktop component 
of the operating system determine the type of a regular file. Free 
desktop environments (e.g. Gnome, KDE, XFCE) stores the file type as 
MIME type.



 Sep 20 2010



  parent  retard <re tard.com.invalid>  writes:


Tue, 21 Sep 2010 02:40:18 +0800, KennyTM~ wrote:


 On Sep 21, 10 01:43, "Jérôme M. Berger" wrote:

 KennyTM~ wrote:

 Your definition of Unix is wrong then. Unix *only* specifies the API
 (system interface and headers) and the command-line utilities. You
 *are* confusing Unix and the distro.

 Ref: http://www.opengroup.org/onlinepubs/9699919799/


 	That's not UNIX, that's POSIX! And by that definition, Windows
 would be UNIX too...

 		Jerome


 
 Looks like we have no point keep discussing on this since we have
 different view on what Unix means.
 
 My points are just:
   - in the CLI the type of regular file is usually irrelevant. - Unix
   (i.e. POSIX) doesn't specify how should the desktop component
 of the operating system determine the type of a regular file. Free
 desktop environments (e.g. Gnome, KDE, XFCE) stores the file type as
 MIME type.


The post by Jonathan M Davis ( http://www.digitalmars.com/webnews/
newsgroups.php?art_group=digitalmars.D&article_id=117660 ) was the most 
informative post in this thread. You should both study that carefully.



 Sep 20 2010



prev sibling next sibling parent  retard <re tard.com.invalid>  writes:


Wed, 15 Sep 2010 15:48:32 -0400, Nick Sabalausky wrote:


 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.225.1284568096.858.digitalmars-d puremagic.com...

 If you're on a non-Windows system, the mime-type becomes far more
 important than
 the extension. Most programs in Linux (and I believe MacOS X as well)
 don't care
 about the extension. They just look at the mime type. Extensions become
 almost
 entirely a thing for the user. So, whether your file is useable becomes
 more of
 an issue of known mime type than known extension. Still, you don't
 generally
 want to just be making up extensions.


 I didn't think unix file systems had a concept of mime type.


Yep, they don't. The new file systems like reiserfs have support for 
arbitrary metadata fields, IIRC. But for example the standard Linux 
distributions have their mime/extension associations in /etc/mime.types



 Sep 15 2010



prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Wednesday, September 15, 2010 12:48:32 Nick Sabalausky wrote:

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.225.1284568096.858.digitalmars-d puremagic.com...
 

 If you're on a non-Windows system, the mime-type becomes far more
 important than
 the extension. Most programs in Linux (and I believe MacOS X as well)
 don't care
 about the extension. They just look at the mime type. Extensions become
 almost
 entirely a thing for the user. So, whether your file is useable becomes
 more of
 an issue of known mime type than known extension. Still, you don't
 generally
 want to just be making up extensions.


 
 I didn't think unix file systems had a concept of mime type.


They don't have a concept of file extension either. Mime types has to do with
the 
contents of the file and file extensions has to do with the name of the file.
It's 
programs which interpret those, not the file system. Typically, on Windows, the 
extension is used by the OS to determine which program to use to open a file.
In 
unix, it's the mime type that's used to determine that.

The one bit of overlap there is the fact that Windows treats the exe extension 
essentially the way that unix treats the executable file attribute.

Now, I wouldn't advise ditching file extensions in unix, since it not only can 
help the human using them but there are occasionally programs which check the 
extension rather the mime type (so, ultimately, you may end up using both the 
extension and the mime type), but it's primarily the mime type which is used, 
and it's definitely the mime type which is used to determine which program to
use 
to open a file in the desktop environments.

- Jonathan M Davis



 Sep 15 2010



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.227.1284590189.858.digitalmars-d puremagic.com...

 On Wednesday, September 15, 2010 12:48:32 Nick Sabalausky wrote:

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.225.1284568096.858.digitalmars-d puremagic.com...


 If you're on a non-Windows system, the mime-type becomes far more
 important than
 the extension. Most programs in Linux (and I believe MacOS X as well)
 don't care
 about the extension. They just look at the mime type. Extensions become
 almost
 entirely a thing for the user. So, whether your file is useable becomes
 more of
 an issue of known mime type than known extension. Still, you don't
 generally
 want to just be making up extensions.


 I didn't think unix file systems had a concept of mime type.


 They don't have a concept of file extension either. Mime types has to do 
 with the
 contents of the file and file extensions has to do with the name of the 
 file. It's
 programs which interpret those, not the file system. Typically, on 
 Windows, the
 extension is used by the OS to determine which program to use to open a 
 file. In
 unix, it's the mime type that's used to determine that.

 The one bit of overlap there is the fact that Windows treats the exe 
 extension
 essentially the way that unix treats the executable file attribute.

 Now, I wouldn't advise ditching file extensions in unix, since it not only 
 can
 help the human using them but there are occasionally programs which check 
 the
 extension rather the mime type (so, ultimately, you may end up using both 
 the
 extension and the mime type), but it's primarily the mime type which is 
 used,
 and it's definitely the mime type which is used to determine which program 
 to use
 to open a file in the desktop environments.


Yea, but my question was more "how in the hell would it know the mime type 
of a file in the first place?" It's obviously not stored in the filename, 
and 99.9% is the time it's not stored in the file's data either.

Since then, someone mentioned it typically analyses the content of the file 
and infers the mime type based on that. That's news to me. It would seem 
limited and error-prone though, so I have a hard time believing it doesn't 
suppliment that content-analysis with extension-checking in many cases.



 Sep 15 2010



 next sibling parent  Lutger <lutger.blijdestijn gmail.com>  writes:


Nick Sabalausky wrote:


 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.227.1284590189.858.digitalmars-d puremagic.com...

 On Wednesday, September 15, 2010 12:48:32 Nick Sabalausky wrote:

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.225.1284568096.858.digitalmars-d puremagic.com...


 If you're on a non-Windows system, the mime-type becomes far more
 important than
 the extension. Most programs in Linux (and I believe MacOS X as well)
 don't care
 about the extension. They just look at the mime type. Extensions become
 almost
 entirely a thing for the user. So, whether your file is useable becomes
 more of
 an issue of known mime type than known extension. Still, you don't
 generally
 want to just be making up extensions.


 I didn't think unix file systems had a concept of mime type.


 They don't have a concept of file extension either. Mime types has to do
 with the
 contents of the file and file extensions has to do with the name of the
 file. It's
 programs which interpret those, not the file system. Typically, on
 Windows, the
 extension is used by the OS to determine which program to use to open a
 file. In
 unix, it's the mime type that's used to determine that.

 The one bit of overlap there is the fact that Windows treats the exe
 extension
 essentially the way that unix treats the executable file attribute.

 Now, I wouldn't advise ditching file extensions in unix, since it not only
 can
 help the human using them but there are occasionally programs which check
 the
 extension rather the mime type (so, ultimately, you may end up using both
 the
 extension and the mime type), but it's primarily the mime type which is
 used,
 and it's definitely the mime type which is used to determine which program
 to use
 to open a file in the desktop environments.


 
 Yea, but my question was more "how in the hell would it know the mime type
 of a file in the first place?" It's obviously not stored in the filename,
 and 99.9% is the time it's not stored in the file's data either.
 
 Since then, someone mentioned it typically analyses the content of the file
 and infers the mime type based on that. That's news to me. It would seem
 limited and error-prone though, so I have a hard time believing it doesn't
 suppliment that content-analysis with extension-checking in many cases.


Such a combination is sometimes used. Dolphin for example gives precedence to 
some extensions. But you'd be surprised how good content analysis alone works, 
for 99% of files I open from the desktop there is no extension required - it 
just works. Mostly you have either plain text or a well defined binary format.



 Sep 16 2010



prev sibling  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Thu, 16 Sep 2010 01:16:20 -0400, Nick Sabalausky <a a.a> wrote:


 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.227.1284590189.858.digitalmars-d puremagic.com...

 On Wednesday, September 15, 2010 12:48:32 Nick Sabalausky wrote:

 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.225.1284568096.858.digitalmars-d puremagic.com...


 If you're on a non-Windows system, the mime-type becomes far more
 important than
 the extension. Most programs in Linux (and I believe MacOS X as well)
 don't care
 about the extension. They just look at the mime type. Extensions  


 become

 almost
 entirely a thing for the user. So, whether your file is useable  


 becomes

 more of
 an issue of known mime type than known extension. Still, you don't
 generally
 want to just be making up extensions.


 I didn't think unix file systems had a concept of mime type.


 They don't have a concept of file extension either. Mime types has to do
 with the
 contents of the file and file extensions has to do with the name of the
 file. It's
 programs which interpret those, not the file system. Typically, on
 Windows, the
 extension is used by the OS to determine which program to use to open a
 file. In
 unix, it's the mime type that's used to determine that.

 The one bit of overlap there is the fact that Windows treats the exe
 extension
 essentially the way that unix treats the executable file attribute.

 Now, I wouldn't advise ditching file extensions in unix, since it not  
 only
 can
 help the human using them but there are occasionally programs which  
 check
 the
 extension rather the mime type (so, ultimately, you may end up using  
 both
 the
 extension and the mime type), but it's primarily the mime type which is
 used,
 and it's definitely the mime type which is used to determine which  
 program
 to use
 to open a file in the desktop environments.


 Yea, but my question was more "how in the hell would it know the mime  
 type
 of a file in the first place?" It's obviously not stored in the filename,
 and 99.9% is the time it's not stored in the file's data either.


Most binary file formats are designed to be detectable using a "magic  
number" that's found at the front of the file.  This magic number allows  
programs to easily determine the file type.

So yeah, it is stored in the file's data :)


 Since then, someone mentioned it typically analyses the content of the  
 file
 and infers the mime type based on that. That's news to me. It would seem
 limited and error-prone though, so I have a hard time believing it  
 doesn't
 suppliment that content-analysis with extension-checking in many cases.


I think it's a combination of many things.  Try the Linux 'file' command  
to see how it detects all different types of files.

-Steve



 Sep 16 2010



  parent  "Nick Sabalausky" <a a.a>  writes:


"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vi4kyub1eav7ka localhost.localdomain...

 On Thu, 16 Sep 2010 01:16:20 -0400, Nick Sabalausky <a a.a> wrote:

 Yea, but my question was more "how in the hell would it know the mime 
 type
 of a file in the first place?" It's obviously not stored in the filename,
 and 99.9% is the time it's not stored in the file's data either.


 Most binary file formats are designed to be detectable using a "magic 
 number" that's found at the front of the file.  This magic number allows 
 programs to easily determine the file type.

 So yeah, it is stored in the file's data :)


Yea, I know, but I was thinking more about text formats (and the rare binary 
formats that don't have that). A lot of text-based formats out there don't 
use shebang syntax. And a lot of them are just small variations on each 
other (at least from a type-detection standpoint).


 Since then, someone mentioned it typically analyses the content of the 
 file
 and infers the mime type based on that. That's news to me. It would seem
 limited and error-prone though, so I have a hard time believing it 
 doesn't
 suppliment that content-analysis with extension-checking in many cases.


 I think it's a combination of many things.  Try the Linux 'file' command 
 to see how it detects all different types of files.


Yea, that makes sence. Never knew that before though, I just assumed it was 
just extensions and shebang syntax.



 Sep 16 2010



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2010-09-15 21:48, Nick Sabalausky wrote:

 "Jonathan M Davis"<jmdavisProg gmx.com>  wrote in message
 news:mailman.225.1284568096.858.digitalmars-d puremagic.com...

 If you're on a non-Windows system, the mime-type becomes far more
 important than
 the extension. Most programs in Linux (and I believe MacOS X as well)
 don't care
 about the extension. They just look at the mime type. Extensions become
 almost
 entirely a thing for the user. So, whether your file is useable becomes
 more of
 an issue of known mime type than known extension. Still, you don't
 generally
 want to just be making up extensions.


 I didn't think unix file systems had a concept of mime type.


I'm pretty sure HFS+ (Mac OS X) has some type of metadata in the file 
system.

-- 
/Jacob Carlborg



 Sep 16 2010