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

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

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.

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

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.

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

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

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

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.

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