On Apr 16, 6:03 pm, "Aaron Gray" <ang.use...@[EMAIL PROTECTED]
> wrote:
> "BruceMcF" <agil...@[EMAIL PROTECTED]
> wrote in message
>
news:03b6d6f6-f06c-4e53-bd09-ec1af3ed7d1f@[EMAIL PROTECTED]
> > On Apr 15, 9:19 pm, "Aaron Gray" <ang.use...@[EMAIL PROTECTED]
> wrote:
> >> Ah, is there a function that searches the path for an executable and
> >> returns
> >> its path ?
> > Not a C Standard Library function ... that's outside the scope of the
> > standard. As I understand it, this is something that Unixen and
> > Windows handle differently. You may require a wrapper routine and an
> > OS specific definition of that wrapper routine to extract the
> > information.
> > This is, it turns out, a comp.lang.c FAQ:
> >http://www.faqs.org/faqs/C-faq/abridged/
> > QUOTE
> > 19.31: How can my program discover the complete pathname to the
> > executable from which it was invoked?
> > A: argv[0] may contain all or part of the pathname. You may be
> > able to duplicate the command language interpreter's search path
> > logic to locate the executable.
> > UNQUOTE
> > In a system where argv[0] always contains the absolute pathname, the
> > wrapper would just parse argv[0].
> > In a system where argv[0] contains a filespec that might have been
> > used in combination with the path to find the file, then first check
> > if the argv[0] has an absolute path, and if not, try passing that
> > filespec to the path searching function. There normally will be a path
> > searching function in dir.h for, say, a Windows system, which can be
> > pressed into service.
> > ... argv[0] holding the absolute pathname and filename is, of course,
> > more secure, but the MS-DOS legacy includes a lot of stuff that is a
> > bit slapdash.
> Great, what an oversite :(
> Anyone got any code for this ?
I don't ... last time I was doing full on C programming, in the
mid-90's, it was all in PowerC from Mix, in DOS, for my own use, so I
was working in my own filesystem I had specified.
Maybe someone on comp.lang.c does? Follow-up reset to comp.lang.c
|
