www.digitalmars.com         C & C++   DMDScript  

D - dmd.conf

reply Helmut Leitner <helmut.leitner chello.at> writes:
I think in the Linux version the configuration file dmd.conf should not go 
with the executable because this isn't the Unix way to do it (there seems 
to be no reliable way to get at the path of the executable) ...

... but be searched at

  /etc/dmd.conf

You can always have the original in the installation directory and put a
symbolic link at /etc, for example:

  cd /etc
  ln -s /home/leitner/d/dmd/bin/dmd.conf

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
May 11 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3EBE0A90.F5EC470A chello.at...
 I think in the Linux version the configuration file dmd.conf should not go
 with the executable because this isn't the Unix way to do it (there seems
 to be no reliable way to get at the path of the executable) ...

argv[0] doesn't do it?
May 11 2003
parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Walter wrote:
 
 "Helmut Leitner" <helmut.leitner chello.at> wrote in message
 news:3EBE0A90.F5EC470A chello.at...
 I think in the Linux version the configuration file dmd.conf should not go
 with the executable because this isn't the Unix way to do it (there seems
 to be no reliable way to get at the path of the executable) ...

argv[0] doesn't do it?

I don't think so: leitner linux:~/d/dmd/samples/d> hello hello world args.length = 1 args[0] = 'hello' This is even the case, when the program is called from a script and the directory is looked up from the PATH. While you can usually rely on args[0] in the DOS/Windows world, I think you usually can't in the Unix world. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
May 11 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3EBEA3FA.CAD63F57 chello.at...
 Walter wrote:
 "Helmut Leitner" <helmut.leitner chello.at> wrote in message
 news:3EBE0A90.F5EC470A chello.at...
 I think in the Linux version the configuration file dmd.conf should



 with the executable because this isn't the Unix way to do it (there



 to be no reliable way to get at the path of the executable) ...


leitner linux:~/d/dmd/samples/d> hello hello world args.length = 1 args[0] = 'hello' This is even the case, when the program is called from a script and the directory is looked up from the PATH. While you can usually rely on args[0] in the DOS/Windows world, I think you usually can't in the Unix world.

<rant> I occaisionally run into these frustrating lacks in linux - frustrating because they'd be so easy to add to the kernel, and are so unreliable to try and work around. One thing I wanted to avoid with linux is having a dmd installation spew files all over the system. It looks like it's going to be very hard avoiding this. </rant> There, I feel better now <g>.
May 11 2003
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Walter wrote:
 <rant>
 I occaisionally run into these frustrating lacks in linux - frustrating
 because they'd be so easy to add to the kernel, and are so unreliable to try
 and work around. One thing I wanted to avoid with linux is having a dmd
 installation spew files all over the system. It looks like it's going to be
 very hard avoiding this.
 </rant>
 
 There, I feel better now <g>.
 

Spewing files all over the system is the Unix way!
May 11 2003
next sibling parent "Walter" <walter digitalmars.com> writes:
"Andy Friesen" <andy ikagames.com> wrote in message
news:b9mka7$8g6$1 digitaldaemon.com...
 Walter wrote:
 <rant>
 I occaisionally run into these frustrating lacks in linux - frustrating
 because they'd be so easy to add to the kernel, and are so unreliable to


 and work around. One thing I wanted to avoid with linux is having a dmd
 installation spew files all over the system. It looks like it's going to


 very hard avoiding this.
 </rant>
 There, I feel better now <g>.


It's the Windows way, too, but I had figured out a way to avoid it!
May 11 2003
prev sibling parent reply Georg Wrede <Georg_member pathlink.com> writes:
In article <b9mka7$8g6$1 digitaldaemon.com>, Andy Friesen says...
Walter wrote:
 <rant>
 I occaisionally run into these frustrating lacks in linux - frustrating
 because they'd be so easy to add to the kernel, and are so unreliable to try
 and work around. One thing I wanted to avoid with linux is having a dmd
 installation spew files all over the system. It looks like it's going to be
 very hard avoiding this.
 </rant>
 
 There, I feel better now <g>.
 

Spewing files all over the system is the Unix way!

There are documets on where the different files of an application should be put in a Linux or Unix system. (Sorry, right now I can't give a pointer. Anybody?) You might also check the Vim editor sources (www.vim.org), Vim does a good job of "knowing where it is", among other things. The volume where the compiler binaries reside might be remotely mounted as read-only, especially in a corporate setup. Also, it is easier for the sysadmin to have all system-wide configurations in the same place, i.e. /etc. Individual users can then override these configurations, e.g. with a $HOME/.dmd file (or even directory, if the configuration is elaborate -- which probably is not needed fof dmd.) One way to resolve the issue is to have the binary look for the config file in /etc and read it, then to update the parameters reading from the first config file found in 1. defined on the command line 2. pointed to by the environment variable $DMD_CONFIG, if it is defined 3. current directory (.) 4. home directory ($HOME) If the user installing DMD is root then this is what sould be set up. On the other hand, if the installing user is non-root (the user himself), then the installation should copy a default .dmd file to his home directory. In this case the .dmd file could contain the path to dmd-home, since the user might have installed the package in any of various places. (It's not even uncommon to install in /tmp, for example for temporary needs or to just check something.) In any case, you probably have to spew a man-file to the man directory, the libraries to /usr/lib, the binary to /usr/bin, and the config file to /etc, at the very least. Sure, it is possible to have the whole DMD-tree in one place. This is OK for a personal install. But when root installs DMD, then every user should be able to use DMD, and then a single-hierarchy-install would confuse normal Unix and Linux people.
May 11 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
Some good ideas here. Thanks!

"Georg Wrede" <Georg_member pathlink.com> wrote in message
news:b9mp6d$d59$1 digitaldaemon.com...
 In article <b9mka7$8g6$1 digitaldaemon.com>, Andy Friesen says...
Walter wrote:
 <rant>
 I occaisionally run into these frustrating lacks in linux - frustrating
 because they'd be so easy to add to the kernel, and are so unreliable



 and work around. One thing I wanted to avoid with linux is having a dmd
 installation spew files all over the system. It looks like it's going



 very hard avoiding this.
 </rant>

 There, I feel better now <g>.

Spewing files all over the system is the Unix way!

There are documets on where the different files of an application should

 in a Linux or Unix system. (Sorry, right now I can't give a pointer.

 You might also check the Vim editor sources (www.vim.org), Vim does a good

 of "knowing where it is", among other things.

 The volume where the compiler binaries reside might be remotely mounted as
 read-only, especially in a corporate setup. Also, it is easier for the

 to have all system-wide configurations in the same place, i.e. /etc.

 Individual users can then override these configurations, e.g. with a

 file (or even directory, if the configuration is elaborate -- which

 not needed fof dmd.)

 One way to resolve the issue is to have the binary look for the config

 /etc and read it, then to update the parameters reading from the first

 file found in

 1. defined on the command line
 2. pointed to by the environment variable $DMD_CONFIG, if it is defined
 3. current directory (.)
 4. home directory ($HOME)

 If the user installing DMD is root then this is what sould be set up. On

 other hand, if the installing user is non-root (the user himself), then

 installation should copy a default .dmd file to his home directory. In

 the .dmd file could contain the path to dmd-home, since the user might

 installed the package in any of various places. (It's not even uncommon to
 install in /tmp, for example for temporary needs or to just check

 In any case, you probably have to spew a man-file to the man directory,

 libraries to /usr/lib, the binary to /usr/bin, and the config file to

 the very least.

 Sure, it is possible to have the whole DMD-tree in one place. This is OK

 personal install. But when root installs DMD, then every user should be

 use DMD, and then a single-hierarchy-install would confuse normal Unix and

 people.

May 11 2003
parent reply Georg Wrede <Georg_member pathlink.com> writes:
The readme.linux (v65) tells me to edit dmd.conf and put it in /etc and to put
libphobos.a in /usr/lib.

This leads to two things:

- Dmd cannot be tried on a machine where the user does
not have root rights. 
- There can be only one version of phobos source files
on a given machine.

I got thinking. Since dmd is currently far from production code (no offence), it
probably will be installed by individuals only. The same individual, or somebody
else on the same machine may want to try another version, right?

Maybe we should go for the single-hierarchy install? 
At least for now? 

Later, when new versions come out more slowly, then we could return to the issue
of "what is the right place to spew all the files". Preferably this could be
together with testing and creating an rpm package.  (Heck, by that time we'll
have enough gurus here to take care of the entire rpm pakaging?)

This would give us time to get the "spewing" done right from the start, too?

---

The variable $HOME is guaranteed to be defined in Unix, and it points to the
home directory. 

Config files in home directory should not be visible when doing a ls or ls -l
and therefore they should have names starting with a dot, like .dmd or .bashrc.

Why not have version specific files (.dmd64, .dmd65, etc.) in home directory?
All they would contain is the path to dmd-home for that version! This way the
old versions would not hinder trying a newer one. 

Switching between versions could be as easy as changing a link in $HOME/bin
directory. Instead of having the dmd/bin directory in your path, you add a
"virtual" path to it.

PATH=$PATH:$HOME/bin/dmdpath

All you have to do is

ln -sf `cat $HOME/.dmd65`/bin $HOME/bin/dmdbin

to switch to v65. (This looks cumbersome to non-unixers, I know.) This way the
user can install any number of different versions, and have them wherever he
wishes.

---

To recap, all the binary has to do is read $HOME/.dmd[myver] to know where
everything is.

This gives the (often pathologically individualistic) linux programmers freedom
to setup everything as they wish, while still being easy on Walter <g>.

Oh, I almost forgot: here's a script for post-unzipping:

#!/bin/sh
MYVER=66
cat $PWD > $HOME/.dmd$MYVER
cd bin
chmod u+x dmd obj2asm dumpobj
May 13 2003
next sibling parent reply Bill Cox <bill viasic.com> writes:
I agree.  I like Olaf's getexecpath function.  Given that, why fool 
around with /etc?

Bill

Georg Wrede wrote:
 The readme.linux (v65) tells me to edit dmd.conf and put it in /etc and to put
 libphobos.a in /usr/lib.
 
 This leads to two things:
 
 - Dmd cannot be tried on a machine where the user does
 not have root rights. 
 - There can be only one version of phobos source files
 on a given machine.
 
 I got thinking. Since dmd is currently far from production code (no offence),
it
 probably will be installed by individuals only. The same individual, or
somebody
 else on the same machine may want to try another version, right?
 
 Maybe we should go for the single-hierarchy install? 
 At least for now? 
 
 Later, when new versions come out more slowly, then we could return to the
issue
 of "what is the right place to spew all the files". Preferably this could be
 together with testing and creating an rpm package.  (Heck, by that time we'll
 have enough gurus here to take care of the entire rpm pakaging?)
 
 This would give us time to get the "spewing" done right from the start, too?
 
 ---
 
 The variable $HOME is guaranteed to be defined in Unix, and it points to the
 home directory. 
 
 Config files in home directory should not be visible when doing a ls or ls -l
 and therefore they should have names starting with a dot, like .dmd or .bashrc.
 
 Why not have version specific files (.dmd64, .dmd65, etc.) in home directory?
 All they would contain is the path to dmd-home for that version! This way the
 old versions would not hinder trying a newer one. 
 
 Switching between versions could be as easy as changing a link in $HOME/bin
 directory. Instead of having the dmd/bin directory in your path, you add a
 "virtual" path to it.
 
 PATH=$PATH:$HOME/bin/dmdpath
 
 All you have to do is
 
 ln -sf `cat $HOME/.dmd65`/bin $HOME/bin/dmdbin
 
 to switch to v65. (This looks cumbersome to non-unixers, I know.) This way the
 user can install any number of different versions, and have them wherever he
 wishes.
 
 ---
 
 To recap, all the binary has to do is read $HOME/.dmd[myver] to know where
 everything is.
 
 This gives the (often pathologically individualistic) linux programmers freedom
 to setup everything as they wish, while still being easy on Walter <g>.
 
 Oh, I almost forgot: here's a script for post-unzipping:
 
 #!/bin/sh
 MYVER=66
 cat $PWD > $HOME/.dmd$MYVER
 cd bin
 chmod u+x dmd obj2asm dumpobj
 
 
 

May 13 2003
parent reply Bill Cox <bill viasic.com> writes:
Sorry about the two replies, but one more comment:

I currently have TWO versions of gcc installed, a stable one, and an 
experimental one.  We test with both.  If we ever ship D-based code, I 
probably will do the same.  My point is that supporting two versions of 
dmd at the same time is an important long-term capability.

Bill

Bill Cox wrote:
 I agree.  I like Olaf's getexecpath function.  Given that, why fool 
 around with /etc?
 
 Bill
 
 Georg Wrede wrote:
 
 The readme.linux (v65) tells me to edit dmd.conf and put it in /etc 
 and to put
 libphobos.a in /usr/lib.

 This leads to two things:

 - Dmd cannot be tried on a machine where the user does
 not have root rights. - There can be only one version of phobos source 
 files
 on a given machine.

 I got thinking. Since dmd is currently far from production code (no 
 offence), it
 probably will be installed by individuals only. The same individual, 
 or somebody
 else on the same machine may want to try another version, right?

 Maybe we should go for the single-hierarchy install? At least for now?
 Later, when new versions come out more slowly, then we could return to 
 the issue
 of "what is the right place to spew all the files". Preferably this 
 could be
 together with testing and creating an rpm package.  (Heck, by that 
 time we'll
 have enough gurus here to take care of the entire rpm pakaging?)

 This would give us time to get the "spewing" done right from the 
 start, too?

 ---

 The variable $HOME is guaranteed to be defined in Unix, and it points 
 to the
 home directory.
 Config files in home directory should not be visible when doing a ls 
 or ls -l
 and therefore they should have names starting with a dot, like .dmd or 
 .bashrc.

 Why not have version specific files (.dmd64, .dmd65, etc.) in home 
 directory?
 All they would contain is the path to dmd-home for that version! This 
 way the
 old versions would not hinder trying a newer one.
 Switching between versions could be as easy as changing a link in 
 $HOME/bin
 directory. Instead of having the dmd/bin directory in your path, you 
 add a
 "virtual" path to it.

 PATH=$PATH:$HOME/bin/dmdpath

 All you have to do is

 ln -sf `cat $HOME/.dmd65`/bin $HOME/bin/dmdbin

 to switch to v65. (This looks cumbersome to non-unixers, I know.) This 
 way the
 user can install any number of different versions, and have them 
 wherever he
 wishes.

 ---

 To recap, all the binary has to do is read $HOME/.dmd[myver] to know 
 where
 everything is.

 This gives the (often pathologically individualistic) linux 
 programmers freedom
 to setup everything as they wish, while still being easy on Walter <g>.

 Oh, I almost forgot: here's a script for post-unzipping:

 #!/bin/sh
 MYVER=66
 cat $PWD > $HOME/.dmd$MYVER
 cd bin
 chmod u+x dmd obj2asm dumpobj


May 13 2003
parent "Walter" <walter digitalmars.com> writes:
I agree.

"Bill Cox" <bill viasic.com> wrote in message
news:3EC0F0D0.3050603 viasic.com...
 Sorry about the two replies, but one more comment:

 I currently have TWO versions of gcc installed, a stable one, and an
 experimental one.  We test with both.  If we ever ship D-based code, I
 probably will do the same.  My point is that supporting two versions of
 dmd at the same time is an important long-term capability.

 Bill

May 13 2003
prev sibling parent reply Georg Wrede <Georg_member pathlink.com> writes:
I'm sorry, the obligatory bug fixes:

In article <b9qpgf$1bu8$1 digitaldaemon.com>, Georg Wrede says...
PATH=$PATH:$HOME/bin/dmdpath

should be PATH=$PATH:$HOME/bin/dmdbin
ln -sf `cat $HOME/.dmd65`/bin $HOME/bin/dmdbin

should be ln -sf `echo $HOME/.dmd65`/bin $HOME/bin/dmdbin
May 13 2003
parent Georg Wrede <Georg_member pathlink.com> writes:
Correcting correcting correcting... maybe I should go to sleep.

In article <b9qqth$1d5d$1 digitaldaemon.com>, Georg Wrede says...
I'm sorry, the obligatory bug fixes:

In article <b9qpgf$1bu8$1 digitaldaemon.com>, Georg Wrede says...

ln -sf `cat $HOME/.dmd65`/bin $HOME/bin/dmdbin

should be ln -sf `echo $HOME/.dmd65`/bin $HOME/bin/dmdbin

No, it was right, so have cat there. But cat was wrong in another place:
    #!/bin/sh
    MYVER=66
    cat $PWD > $HOME/.dmd$MYVER
    cd bin
    chmod u+x dmd obj2asm dumpobj

here the echo, thus: echo $PWD > $HOME/.dmd$MYVER
May 13 2003
prev sibling parent reply Ilya Minkov <midiclub 8ung.at> writes:
Georg Wrede wrote:
 There are documets on where the different files of an application should be put
 in a Linux or Unix system. (Sorry, right now I can't give a pointer. Anybody?)

http://www.pathname.com/fhs/ Have you meant this? -i.
May 12 2003
parent Georg Wrede <Georg_member pathlink.com> writes:
In article <b9opk2$2gf4$1 digitaldaemon.com>, Ilya Minkov says...
Georg Wrede wrote:
 There are documets on where the different files of an application should be put
 in a Linux or Unix system. (Sorry, right now I can't give a pointer. Anybody?)

http://www.pathname.com/fhs/ Have you meant this?

Yes, thank you! Also, another document I found helpful: http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/pdf/HighQuality-Apps-HOWTO.pdf which has good content, unfortunately the English is barely satisfactory. http://www.rpm.org/RPM-HOWTO/ is also required reading. An authoritative and practical text can be read at http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/ch-filesystem.html which also illuminates the differences between FHS and how RedHat (and "everyone else") implements the file hierarchy.
May 12 2003
prev sibling parent Richard Krehbiel <rich kastle.com> writes:
Walter wrote:
 "Helmut Leitner" <helmut.leitner chello.at> wrote in message
 news:3EBEA3FA.CAD63F57 chello.at...
 
Walter wrote:

"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3EBE0A90.F5EC470A chello.at...

I think in the Linux version the configuration file dmd.conf should



not go
with the executable because this isn't the Unix way to do it (there



seems
to be no reliable way to get at the path of the executable) ...

argv[0] doesn't do it?

I don't think so: leitner linux:~/d/dmd/samples/d> hello hello world args.length = 1 args[0] = 'hello' This is even the case, when the program is called from a script and the directory is looked up from the PATH. While you can usually rely on args[0] in the DOS/Windows world, I think you usually can't in the Unix world.

<rant> I occaisionally run into these frustrating lacks in linux - frustrating because they'd be so easy to add to the kernel, and are so unreliable to try and work around. One thing I wanted to avoid with linux is having a dmd installation spew files all over the system. It looks like it's going to be very hard avoiding this. </rant> There, I feel better now <g>.

There's a semantic disconnect in Unix systems (which Linux is like) and the concept of "the path to the executable." The file system makes a distinction between the data, and some "path name" by which the data can be found. The data is uniquely identified by it's "inode", which is just an integer value, but there can be many file names that refer that inode (hard links). When a program exec's some other program, it's free to put whatever it wishes into all the argv[] variables, argv[0] included. The argv[0] thing has been just a convention begun by the Unix shell. These shells simply put the exec'ed name there because it's a way to give the same executable different functions, distinguished by the command line verb. For instance, in Unix "gzip" and "gunzip" are both links to the very same data set. This was important back when Unix systems didn't have dynamic linking or command line aliases. Now, I'm not trying to defend the system; I'm just explaining that it's there for historical reasons.
May 12 2003
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3EBE0A90.F5EC470A chello.at...
 I think in the Linux version the configuration file dmd.conf should not go
 with the executable because this isn't the Unix way to do it (there seems
 to be no reliable way to get at the path of the executable) ...

 ... but be searched at

   /etc/dmd.conf

Why /etc instead of, say, /usr/local/etc? (Pardon my ignorance of linux conventions.0
May 11 2003
parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Walter wrote:
 
 "Helmut Leitner" <helmut.leitner chello.at> wrote in message
 news:3EBE0A90.F5EC470A chello.at...
 I think in the Linux version the configuration file dmd.conf should not go
 with the executable because this isn't the Unix way to do it (there seems
 to be no reliable way to get at the path of the executable) ...

 ... but be searched at

   /etc/dmd.conf

Why /etc instead of, say, /usr/local/etc? (Pardon my ignorance of linux conventions.0

Sorry, I can't answer the question. I'm still a 90% Windows developer. I only notice that all applications that I installed (apache, exim, ...) put their config files into /etc. It's the place where people look first. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
May 11 2003
next sibling parent Arjan Knepper <ask me.to> writes:
Helmut Leitner wrote:
 
 Walter wrote:
 
"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3EBE0A90.F5EC470A chello.at...

I think in the Linux version the configuration file dmd.conf should not go
with the executable because this isn't the Unix way to do it (there seems
to be no reliable way to get at the path of the executable) ...

... but be searched at

  /etc/dmd.conf

Why /etc instead of, say, /usr/local/etc? (Pardon my ignorance of linux conventions.0


On BSD systems (and Debian Linuxas far as I know), /etc is for system conf files. /usr/local/etc is for userland conf files. So that is where you would expect dmd.conf. Or when it is really big and has several config files in /usr/local/dm/dmd.conf. As for the executable path. I once used a libc function or api-call on FreeBSD to get the full filepath of the current executable. But I can't remember the name of it. I don't know whether or not this function is available on Linux.
May 11 2003
prev sibling next sibling parent John Reimer <jjreimer telus.net> writes:
Helmut Leitner wrote:
 
 Walter wrote:
 
"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3EBE0A90.F5EC470A chello.at...

I think in the Linux version the configuration file dmd.conf should not go
with the executable because this isn't the Unix way to do it (there seems
to be no reliable way to get at the path of the executable) ...

... but be searched at

  /etc/dmd.conf

Why /etc instead of, say, /usr/local/etc? (Pardon my ignorance of linux conventions.0

Sorry, I can't answer the question. I'm still a 90% Windows developer. I only notice that all applications that I installed (apache, exim, ...) put their config files into /etc. It's the place where people look first. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com

Helmut's right. It's just convention. That's why :-). /etc is used typically for system wide configuration files. If this machine is a network server (gateway, firewall, or shared system to some other degree -- something Linux is often used for), than it likely is managing distributed machines on the network or serving software. So programs designed to be shared or served network wide will likely use /etc for configuration. Examples: XFree86, NFS, consoles, web services, etc. I imagine that's more the original reason. Now it's just the place to use when most software is installed. It's nice, at least, to know where to look when you need to setup your software. The system startup scripts (rc.d) also reside in /etc and will usually set the compiler environment variables (cc) = gcc and default compiler options. Like someone else said, users usually have a specific config file in their home directory also that's created when they first run the program (something like .dmd-config). This reflects their personalized setting for when they use the software. It overrides the defaults system wide configuration in /etc so that they can control the software to their liking. I don't think /usr/local/etc is very often used. If it is, I imagine it would be more used for programs that are designed for trully local consumption only, ie NON-server/NON-shared software (eg. computer games like unreal tournament). It may also be retained as a result of maintaining compatibility across various other UNIX conventions. Of course, like windows, you really can do whatever you want... it's just often easier for the Linux crowd to understand/use software that follows the crazy system they're familiar with. I think that's why dependency packaging systems like RPM and ebuilds (and BSD ports) surfaced. They present a single package to the user that includes all the configuration files. Everything is automatically moved to the standard locations behind the scenes during installation... Well just like windows, I guess :-). I still maintain that the Gentoo Linux ebuild/emerge system is the all round best I've see yet... and it's fun too! Later, John
May 12 2003
prev sibling next sibling parent John Reimer <jjreimer telus.net> writes:
It's probably better for to actually refer to documents that explain it, 
just so that I don't trip over myself :-).

http://www.tuxfiles.org/linuxhelp/linuxdir.html

"< /etc >

The configuration files for the Linux system. Most of these files are 
text files and can be edited by hand. Some interesting stuff in this 
directory:

< /usr/local >

This is where you install apps and other files for use on the local 
machine. If your machine is a part of a network, the /usr directory may 
physically be on another machine and can be shared by many networked 
Linux workstations. On this kind of a network, the /usr/local directory 
contains only stuff that is not supposed to be used on many machines and 
is intended for use at the local machine only.

Most likely your machine isn't a part of a network like this, but it 
doesn't mean that /usr/local is useless. If you find interesting apps 
that aren't officially a part of your distro, you should install them in 
/usr/local. For example, if the app would normally go to /usr/bin but it 
isn't a part of your distro, you should install it in /usr/local/bin 
instead. When you keep your own programs away from the programs that are 
included in your distro, you'll avoid confusion and keep things nice and 
clean."

< back to me >

So I guess you could say /etc should be used for config files that are 
more linux distro oriented.  To tell you the truth, I don't think people 
follow these rules perfectly.  In the case of DMD, it probably would do 
fine in the /usr/local path, as Arjan said.  But, you never know, it may 
become part of a distro someday, like gcc, and then would be just as at 
home with config files in /etc!

Later,

John
May 12 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Helmut Leitner" <helmut.leitner chello.at> wrote in message
news:3EBF325B.792E5A5E chello.at...
 Sorry, I can't answer the question. I'm still a 90% Windows developer.
 I only notice that all applications that I installed (apache, exim, ...)
 put their config files into /etc. It's the place where people look first.

Sounds ok. I'll put it there.
May 11 2003
prev sibling parent reply Bill Cox <bill viasic.com> writes:
I hate stuffing files in places like /usr/etc.  For one thing, not 
everyone has write permission to that directory.

We put our conf files in a directory relative to the executable, with 
user configurations in their home directory.  This also works well on 
Windows.  The Windows version was easy to write, the Linux one harder.

The problem with the Linux version was that there is no good function to 
find the path of the executable that I know of, so we had to write one.

This code is still fairly untested... It works on our systems, but we 
haven't had a Linux release of our software yet.

Bill

/*--------------------------------------------------------------------------------------------------
   Return the path name which an executable resides.
--------------------------------------------------------------------------------------------------*/
char *utExecPath(
     const char *program)
{
     char *path, *p;
     char *fullPath;

     if(strchr(program, UTDIRSEP) != NULL) {
         return utFullPath(program);
     } else {
         path = getenv ("PATH");
         if(path != NULL) {
             p = path;
             do {
                 path = p;
                 p = strchr(path, UTPATHSEP);
                 if(p == NULL) {
                     p = strchr(path, '\0');
                 }
                 if(p == path) {
                     fullPath = utCopyString(program);
                 } else {
                     fullPath = utMakeString((p - path) + 1);
                     utStrncpy(fullPath, path, p - path);
                     fullPath = utSprintf("%s%c%s", fullPath, UTDIRSEP,
                         program);
                 }
                 fullPath = utGlob(fullPath);
                 if(fullPath != NULL) {
                     return fullPath;
                 }
                 fullPath = utGlob(utSprintf("%s.exe", fullPath));
                 if(fullPath != NULL) {
                     return fullPath;
                 }
             } while(*p++ != '\0');
         }
     }
     utError("could not find executable %s", program);
     return NULL;
}

/*--------------------------------------------------------------------------------------------------
   Set directories used in the system.  Take the name passed to main as 
argv[0].
--------------------------------------------------------------------------------------------------*/
static bool setDirectories(
     const char *executableName)
{
     char *execDirectory, *configDirectory;

     execDirectory = utDirName(utExecPath(executableName));
     if(execDirectory == NULL) {
         fprintf(stderr, "cannot find executable path");
         return true;
     }
     utSetExeDirectory(execDirectory);
     configDirectory = utSprintf("%s%c..%cconfig", execDirectory, 
UTDIRSEP, UTDIRSEP);
     configDirectory = utFullPath(configDirectory);
     utSetConfigDirectory(configDirectory);
     return false;
}

================================  Unix versions of subroutines...

/*--------------------------------------------------------------------------------------------------
   Take the relative path, and return the full path.
--------------------------------------------------------------------------------------------------*/
char *utFullPath(
     const char *relativePath)
{
     char *fileName = utGlob(relativePath);
     char *dirName = utGetcwd();

     if(*relativePath == UTDIRSEP) {
         return utCopyString(relativePath);
     }
     if(fileName == NULL) {
         return utSprintf("%s%c%s", dirName, UTDIRSEP, relativePath);
     }
     while(!strncmp(fileName, ".." szUTDIRSEP, 3)) {
         fileName = fileName + 3;
         dirName = utDirName(dirName);
         if(dirName == NULL) {
             return utSprintf("%s%c%s", dirName, UTDIRSEP, relativePath);
         }
     }
     return utSprintf("%s%c%s", dirName, UTDIRSEP, fileName);
}


/*--------------------------------------------------------------------------------------------------
   Match the string to a file and return the matched file name.
--------------------------------------------------------------------------------------------------*/
char *utGlob(
     const char *fileName)
{
     glob_t globbuf;
     char *buffer = NULL;

     globbuf.gl_offs = 0;
     glob(fileName, 0, NULL, &globbuf);
     if(globbuf.gl_pathc >= 1) {
         buffer = utCopyString(*globbuf.gl_pathv);
     }
     globfree(&globbuf);
     return buffer;
}

================================  Windows versions of subroutines...

/*--------------------------------------------------------------------------------------------------
   Take the relative path, and return the full path.
--------------------------------------------------------------------------------------------------*/
char *utFullPath(
     const char *relativePath)
{
     char fullPath[UTSTRLEN];

     _fullpath(fullPath, relativePath, UTSTRLEN);
     return utCopyString(fullPath);
}

/*--------------------------------------------------------------------------------------------------
   Match the string to a file and return the matched file name.
--------------------------------------------------------------------------------------------------*/
char *utGlob(
     const char *fileName)
{
     if(utAccess(fileName, 0) == 0) {
         return utCopyString(fileName);
     }
     return NULL;
}



Helmut Leitner wrote:
 I think in the Linux version the configuration file dmd.conf should not go 
 with the executable because this isn't the Unix way to do it (there seems 
 to be no reliable way to get at the path of the executable) ...
 
 ... but be searched at
 
   /etc/dmd.conf
 
 You can always have the original in the installation directory and put a
 symbolic link at /etc, for example:
 
   cd /etc
   ln -s /home/leitner/d/dmd/bin/dmd.conf
 
 --
 Helmut Leitner    leitner hls.via.at   
 Graz, Austria   www.hls-software.com

May 12 2003
next sibling parent Georg Wrede <Georg_member pathlink.com> writes:
In article <3EBF8FC4.3050700 viasic.com>, Bill Cox says...
I hate stuffing files in places like /usr/etc.  For one thing, not 
everyone has write permission to that directory.

There's a difference between installing as a user and installing as root. A user installs for his own usage, root installs only for "all users" or for "the system itself". (Oh, and incidentally, ROOT NEVER COMPILES software.) A personal install and a system-wide install should be considered two entirely separate cases. Root only installs known-good software for "all" users to use, and individuals for themselves only. (Ok, I know this isn't as clear cut as I state here, but this is a reasonable starting point here.) ..
The problem with the Linux version was that there is no good function to 
find the path of the executable that I know of, so we had to write one.

Things like this bothered me for many years. Why is this or that done in an idiotic way in Unix, and later in Linux. This lead to work-arounds, kludges, and generally solutions that I regretted later. Finally I became enlightened: - The Unix system is older than many who write comments here. - The Unix system has always been primarily a Development system. - The Unix system has been used by legions of top talents in programming. This leads to a surprising conclusion: ANY problem at all one might encounter has already been encountered by people more experienced, more talented, or more industrious than we. Therefore, if "something is missing" in Unix, or especially Linux, then there is a good reason for it not to be there! And if something is done in a particular way, there is bound to be a good reason for it, too. One can either do the same, or search for the reason -- and then still do the same, this time with conviction.
May 12 2003
prev sibling parent reply Olaf Rogalsky <olaf.rogalsky theorie1.physik.uni-erlangen.de> writes:
Bill Cox wrote:
The problem with your approach is, that argv[0] may be totally unrelated
to the executable filename, try:
 exec -a foo bash           # starts a new bash with argv[0]=foo
 ps -u

If you have the proc filesystem, you can get the path with: char buf[30], execpath[2048]; sprintf(buf,"/proc/%d/exe", getpid()); memset(execpath, 0, sizeof(execpath)) readlink(buf, execpath); Unfortunately, in UNIX there is no reliable and protable way to get the execpath. -- +----------------------------------------------------------------------+ I Dr. Olaf Rogalsky Institut f. Theo. Physik I I I Tel.: 09131 8528440 Univ. Erlangen-Nuernberg I I Fax.: 09131 8528444 Staudtstrasse 7 B3 I I rogalsky theorie1.physik.uni-erlangen.de D-91058 Erlangen I +----------------------------------------------------------------------+
May 12 2003
parent reply Olaf Rogalsky <olaf.rogalsky theorie1.physik.uni-erlangen.de> writes:
Ok, I hate to reply to myself, but I disobeyed the rule never to
post untested code ... here is a working snipped:

char buf[30], execpath[2048];
sprintf(buf,"/proc/%d/exe", getpid());
memset(execpath, 0, sizeof(execpath));
readlink(buf, execpath, sizeof(execpath));

Further, I like to comment on Georg Wrede:
 Therefore, if "something is missing" in Unix, or especially Linux, then there
 is a good reason for it not to be there!

the UNIX API is bad designed (e.g. job control). But in this particular example there IS a good reason, that there is no function to get the path to the executable: Not every process has a member in the directory hierarchy: #include <stdio.h> #include <unistd.h> char* getexecpath() { static char buf[30], execpath[2048]; sprintf(buf,"/proc/%d/exe", getpid()); memset(execpath, 0, sizeof(execpath)); readlink(buf, execpath, sizeof(execpath)); return execpath; } int main(int argc, char *argv[]) { printf("execpath: %s\n", getexecpath()); remove(getexecpath()); printf("execpath: %s\n", getexecpath()); return 0; } Pathological? Yes! But remember Murphy's law. Olaf
May 12 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Olaf Rogalsky" <olaf.rogalsky theorie1.physik.uni-erlangen.de> wrote in
message news:3EBFABD4.D95BA618 theorie1.physik.uni-erlangen.de...
 Pathological? Yes! But remember Murphy's law.

On windows, you cannot delete an exe file that is currently running. One of the reasons for that is the exe file is loaded as a memory mapped file.
May 12 2003
parent Olaf Rogalsky <olaf.rogalsky theorie1.physik.uni-erlangen.de> writes:
Walter wrote:
 On windows, you cannot delete an exe file that is currently running. One of
 the reasons for that is the exe file is loaded as a memory mapped file.

Same in linux, but there is a distinction between an entry in the filesystem hierarchy and the reserved storage on disk. The disk storage only gets freed after the last file descriptor is closed. The filename vanishes immediatly. The linux kernel keeps an open file descriptor for every running process (IIRC). Olaf -- +----------------------------------------------------------------------+ I Dr. Olaf Rogalsky Institut f. Theo. Physik I I I Tel.: 09131 8528440 Univ. Erlangen-Nuernberg I I Fax.: 09131 8528444 Staudtstrasse 7 B3 I I rogalsky theorie1.physik.uni-erlangen.de D-91058 Erlangen I +----------------------------------------------------------------------+
May 12 2003
prev sibling next sibling parent reply Bill Cox <bill viasic.com> writes:
Thanks!  I've upgraded my unix utility to use this.

Bill

Olaf Rogalsky wrote:
 Ok, I hate to reply to myself, but I disobeyed the rule never to
 post untested code ... here is a working snipped:
 
 char buf[30], execpath[2048];
 sprintf(buf,"/proc/%d/exe", getpid());
 memset(execpath, 0, sizeof(execpath));
 readlink(buf, execpath, sizeof(execpath));
 
 Further, I like to comment on Georg Wrede:
 
Therefore, if "something is missing" in Unix, or especially Linux, then there
is a good reason for it not to be there!

There is truth in this statement, but I don't wholeheartedly agree. Often enough the UNIX API is bad designed (e.g. job control). But in this particular example there IS a good reason, that there is no function to get the path to the executable: Not every process has a member in the directory hierarchy: #include <stdio.h> #include <unistd.h> char* getexecpath() { static char buf[30], execpath[2048]; sprintf(buf,"/proc/%d/exe", getpid()); memset(execpath, 0, sizeof(execpath)); readlink(buf, execpath, sizeof(execpath)); return execpath; } int main(int argc, char *argv[]) { printf("execpath: %s\n", getexecpath()); remove(getexecpath()); printf("execpath: %s\n", getexecpath()); return 0; } Pathological? Yes! But remember Murphy's law. Olaf

May 12 2003
parent Helmut Leitner <helmut.leitner chello.at> writes:
Bill Cox wrote:
 
 Thanks!  I've upgraded my unix utility to use this.
 
 Bill
 
 Olaf Rogalsky wrote:
 Ok, I hate to reply to myself, but I disobeyed the rule never to
 post untested code ... here is a working snipped:

 char buf[30], execpath[2048];
 sprintf(buf,"/proc/%d/exe", getpid());
 memset(execpath, 0, sizeof(execpath));
 readlink(buf, execpath, sizeof(execpath));


Works with my Linux, thanks for sharing. FreeBSD 4.4: sprintf(buf,"/proc/%d/file", getpid()); -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
May 12 2003
prev sibling parent reply Scott Wood <scott buserror.net> writes:
On Mon, 12 May 2003 16:12:36 +0200, Olaf Rogalsky wrote:
 Further, I like to comment on Georg Wrede:
 Therefore, if "something is missing" in Unix, or especially Linux, then there
 is a good reason for it not to be there!


Unfortunately, that "good reason" often seems to be that each person who encountered the problem felt it would be less effort to work around it than fix it. :-(
 There is truth in this statement, but I don't wholeheartedly agree. Often
enough
 the UNIX API is bad designed (e.g. job control). But in this particular example
 there IS a good reason, that there is no function to get the path to the
 executable: Not every process has a member in the directory hierarchy:
 
 #include <stdio.h>
 #include <unistd.h>
 
 char* getexecpath() {
   static char buf[30], execpath[2048];
 
   sprintf(buf,"/proc/%d/exe", getpid());
   memset(execpath, 0, sizeof(execpath));
   readlink(buf, execpath, sizeof(execpath));
   return execpath;
 }
                                                                               
 int main(int argc, char *argv[]) {  
   printf("execpath: %s\n", getexecpath());
   remove(getexecpath());
   printf("execpath: %s\n", getexecpath());
   return 0;
 }
 
 Pathological? Yes! But remember Murphy's law.

That's not really a good reason to omit such a feature, though. If the directory entry has been removed, it could return an error, or better yet, return a path into some special portion of the namespace where one can look up files by inode. Though, if I were designing it, I'd just have it return a file descriptor, and provide a descriptor-to-name mapping function for that, as well as functions to get the file descriptor of the parent directory, etc. In that case, the "inode fs" is unnecessary, and the descriptor-to-name function would just return an error if no name exists. -Scott
May 12 2003
next sibling parent "Walter" <walter digitalmars.com> writes:
"Scott Wood" <scott buserror.net> wrote in message
news:slrnbc0e2l.c9.scott ti.buserror.net...
 On Mon, 12 May 2003 16:12:36 +0200, Olaf Rogalsky wrote:
 Further, I like to comment on Georg Wrede:
 Therefore, if "something is missing" in Unix, or especially Linux, then



 is a good reason for it not to be there!


who encountered the problem felt it would be less effort to work around it than fix it. :-(

There's another effect. People can get so used to working around a shortcoming that they don't realize it even exists. One example is having nested functions.
May 12 2003
prev sibling parent reply Olaf Rogalsky <olaf.rogalsky theorie1.physik.uni-erlangen.de> writes:
Scott Wood wrote:
 Though, if I were designing it, I'd just have it return a file
 descriptor, and provide a descriptor-to-name mapping function for
 that, as well as functions to get the file descriptor of the parent
 directory, etc.
 
 In that case, the "inode fs" is unnecessary, and the
 descriptor-to-name function would just return an error if no name
 exists.

it simply can't change its direction arbitrarily anymore. -- +----------------------------------------------------------------------+ I Dr. Olaf Rogalsky Institut f. Theo. Physik I I I Tel.: 09131 8528440 Univ. Erlangen-Nuernberg I I Fax.: 09131 8528444 Staudtstrasse 7 B3 I I rogalsky theorie1.physik.uni-erlangen.de D-91058 Erlangen I +----------------------------------------------------------------------+
May 13 2003
parent John Reimer <jjreimer telus.net> writes:
On Tue, 13 May 2003 13:32:18 +0200, Olaf Rogalsky wrote:


 Agreed. UNIX is just very old and has such a big moment of inertia, that
 it simply can't change its direction arbitrarily anymore.

Spoken like a true physicist ;-D.
May 13 2003