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






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




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!


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






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


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:
 

 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:


 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:



    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:


 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!


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






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


Agreed. UNIX is just very old and has such a big moment of inertia, that
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