On Tue, 22 Aug 2006 12:59:07 -0500 (CDT)
Sergey Babkin <[EMAIL PROTECTED]> mentioned:
> If we get back to the question of why we need the file,
> we might not need it at all. As far as I understand,
> the problem is that the Watcom compiler works by
> sticking a set of messages into the executable
- Original Message -
From: "Oliver Fromme" <[EMAIL PROTECTED]>
To: ; <[EMAIL PROTECTED]>
Sent: Wednesday, August 23, 2006 2:40 PM
Subject: Re: Aqcuiring full path to running process from outside the
?kernel
Oliver Fromme wrote:
Another way would be to use /pro
Reko Turja wrote:
> But as said in earlier post of mine, I managed to achieve what I was
> trying with the following code - using the sysctl seems to achieve
> what was needed reliably enough, at least for now.
>
> int mib[4];
> size_t len;
> mib[0] = CTL_KERN;
> mib[1] = KERN_PROC;
> m
- Original Message -
From: "Sergey Babkin" <[EMAIL PROTECTED]>
To: "Lutz Boehne" <[EMAIL PROTECTED]>;
Sent: Tuesday, August 22, 2006 8:59 PM
Subject: Re: Re: Aqcuiring full path to running process from outside
thekernel
So why not just change the compiler to put the contents of
this
In message: <[EMAIL PROTECTED]>
Sergey Babkin <[EMAIL PROTECTED]> writes:
: >From: Lutz Boehne <[EMAIL PROTECTED]>
: >
: >> but argv[0] is either an absolute path or a path relative to pwd,
: >> unless your shell is broken.
: >
: >One should also consider users breaking argv[0] intentio
>From: Lutz Boehne <[EMAIL PROTECTED]>
>
>> but argv[0] is either an absolute path or a path relative to pwd,
>> unless your shell is broken.
>
>One should also consider users breaking argv[0] intentionally, e.g.
>pointing it to other files which could lead to undesired/unpredictable
>behaviour.
but argv[0] is either an absolute path or a path relative to pwd,
unless your shell is broken.
One should also consider users breaking argv[0] intentionally, e.g.
pointing it to other files which could lead to undesired/unpredictable
behaviour. Even as a fallback it's probably not wise to tr
In <[EMAIL PROTECTED]>, Dag-Erling Smørgrav <[EMAIL PROTECTED]> typed:
> Mike Meyer <[EMAIL PROTECTED]> writes:
> > In <[EMAIL PROTECTED]>, Dag-Erling Smørgrav <[EMAIL PROTECTED]> typed:
> > > You got it the wrong way around. First pass argv[0] to realpath(3),
> > > fall back to using $PATH only i
Mike Meyer <[EMAIL PROTECTED]> writes:
> In <[EMAIL PROTECTED]>, Dag-Erling Smørgrav <[EMAIL PROTECTED]> typed:
> > You got it the wrong way around. First pass argv[0] to realpath(3),
> > fall back to using $PATH only if realpath(3) fails (which it shouldn't
> > unless you've called chdir(2), chro
In <[EMAIL PROTECTED]>, Dag-Erling Smørgrav <[EMAIL PROTECTED]> typed:
> Mike Meyer <[EMAIL PROTECTED]> writes:
> > However, you can also make a best effort. Check argv[0] to see if you
> > have an absolute path. If not, do what the shell would do to find the
> > executable - look for it on $PATH.
Mike Meyer <[EMAIL PROTECTED]> writes:
> However, you can also make a best effort. Check argv[0] to see if you
> have an absolute path. If not, do what the shell would do to find the
> executable - look for it on $PATH. Once you've found it, call
> realpath(3) to canonicalize the path.
You got it
Of course I did find about the CTL_KERN.KERN_PROC.KERN_PROC_PATHNAME
sysctl method of grabbing the path just about the same time Mike
replied to my query... Seems that either of the ways suggested by Mike
could be used as fallback.
Sorry about the noise.
-Reko
_
In <[EMAIL PROTECTED]>, Reko Turja <[EMAIL PROTECTED]> typed:
> I've been playing with Open Watcom for a bit in FreeBSD and for a
> while there's been one stumblim block for further advancement. Watcom
> uses a method for storing program messages etc. where these messages
> are stored as a "reso
13 matches
Mail list logo
