Application Path 
Author Message
 Application Path

Can anyone tell me how can I find the path that my application is
running from? (in DOS)

Thanks for your help in advance.

:)



Fri, 25 Aug 2000 03:00:00 GMT  
 Application Path

Quote:

> Can anyone tell me how can I find the path that my application is
> running from? (in DOS)

> Thanks for your help in advance.

> :)

Ah! You better ask this in comp.os.ms-dos.programmer

Go quick now! The evil flamers haven't seen you yet but are lurking
around here somewhere ;-)



Fri, 25 Aug 2000 03:00:00 GMT  
 Application Path

Quote:

>Can anyone tell me how can I find the path that my application is
>running from? (in DOS)

I'd visit http://www.eskimo.com/~scs/C-faq/top.html and see

information.

--
Craig

Manchester, NH
Human Salvation lies in the hands of the
creatively maladjusted. -- Martin Luther King, Jr.



Fri, 25 Aug 2000 03:00:00 GMT  
 Application Path

Quote:


>> Can anyone tell me how can I find the path that my application is
>> running from? (in DOS)

>> Thanks for your help in advance.

>> :)
>Ah! You better ask this in comp.os.ms-dos.programmer

>Go quick now! The evil flamers haven't seen you yet but are lurking
>around here somewhere ;-)

An excellent response.  Often, a compiler will have a function to recover the
current working directory.  John may also want to consider the information
found in the C FAQ:

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, or it may
        contain nothing.  You may be able to duplicate the command
        language interpreter's search path logic to locate the
        executable if the name in argv[0] is present but incomplete.
        However, there is no guaranteed solution.

        References: K&R1 Sec. 5.11 p. 111; K&R2 Sec. 5.10 p. 115; ANSI
        Sec. 2.1.2.2.1; ISO Sec. 5.1.2.2.1; H&S Sec. 20.1 p. 416.
--
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ ftp: ftp://rtfm.mit.edu, C-FAQ Book: ISBN 0-201-84519-9
Try "C Programming: A Modern Approach" ISBN 0-393-96945-2
Want Software?  Algorithms?  Pubs? http://www.infoseek.com



Fri, 25 Aug 2000 03:00:00 GMT  
 Application Path


Quote:



>>> Can anyone tell me how can I find the path that my application is
>>> running from? (in DOS)

>>> Thanks for your help in advance.

>>> :)
>>Ah! You better ask this in comp.os.ms-dos.programmer

>>Go quick now! The evil flamers haven't seen you yet but are lurking
>>around here somewhere ;-)
>An excellent response.  Often, a compiler will have a function to recover the
>current working directory.  John may also want to consider the information
>found in the C FAQ:

>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, or it may
>        contain nothing.  You may be able to duplicate the command
>        language interpreter's search path logic to locate the
>        executable if the name in argv[0] is present but incomplete.
>        However, there is no guaranteed solution.

Corollary: only poorly designed programs need to know their own pathname
anyway. A program should not keep files in a directory that is relative
to where the executable is located. The executable should work correctly
no matter where in the filesystem it is located. The location of configuration
files should be determined from the command line arguments, the environment
list, or some other mechanism, such as text files in the user's home
directory, files in the /etc directory of a UNIX system, X Window resources,
the Registry in a Windows system (gack, I can't believe I said that!), a
database table, etc.

- Show quoted text -

Quote:
>        References: K&R1 Sec. 5.11 p. 111; K&R2 Sec. 5.10 p. 115; ANSI
>        Sec. 2.1.2.2.1; ISO Sec. 5.1.2.2.1; H&S Sec. 20.1 p. 416.
>--
>Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
>C-FAQ ftp: ftp://rtfm.mit.edu, C-FAQ Book: ISBN 0-201-84519-9
>Try "C Programming: A Modern Approach" ISBN 0-393-96945-2
>Want Software?  Algorithms?  Pubs? http://www.infoseek.com



Fri, 25 Aug 2000 03:00:00 GMT  
 Application Path


Quote:
> Ah! You better ask this in comp.os.ms-dos.programmer

Or, if you actually wanted a reply, you'd post in

        comp.os.msdos.programmer

firewind, nitpicker extraordinare

--
(initiator of the campaign for grumpiness where grumpiness is due in c.l.c)

Attempting to write in a hybrid which can be compiled by either a C compiler
or a C++ compiler produces a compromise language which combines the drawbacks
of both with the advantages of neither.



Fri, 25 Aug 2000 03:00:00 GMT  
 Application Path

Quote:

> Corollary: only poorly designed programs need to know their own
> pathname anyway. A program should not keep files in a directory that
> is relative to where the executable is located. The executable should
> work correctly no matter where in the filesystem it is located. The
> location of configuration files should be determined from the command
> line arguments, the environment list, or some other mechanism, such as
> text files in the user's home directory, files in the /etc directory
> of a UNIX system, X Window resources, the Registry in a Windows system
> (gack, I can't believe I said that!), a database table, etc.

Counterargument: to the extent possible, a well-written program
should be self-installing.  It should be able to find its
configuration files, build its work files or temporary
directories, etc., automatically the first time it is run.
It should be possible to plop the program down somewhere and
run it, without having to first run any installation programs
or configuration scripts, or fuss with any arcane command line
arguments, environment variables, configuration files in the
user's home directory or /etc, X Window resources, Windows
registries, database tables, etc.

Therefore, if a platform does make it possible to reliably
discover the directory of a running executable, having that
directory be one of the default locations for ancillary files
is an excellent strategy.  It may even be the preferred strategy
in certain environments, especially those where it simply is the
preferred strategy by fiat: all programs work that way; users
expect them to work that way.  In such an environment, nobody
expects that an executable should work correctly no matter where
in the filesystem it is located, because nobody moves executables
around by themselves.  But everybody *does* expect that a
"program" should work correctly no matter where in the filesystem
it is located, where by "program" we mean an executable plus its
ancillary files and subdirectories.  (That is, whenever anyone
plops a program in some random directory somewhere, they
typically plop its ancillary files there, too, and it works just
fine.)  And, in fact, it's precisely because this is common
behavior on some platforms that programmers are always asking
how to implement it, thus the frequency of question 19.31.

Don't get me wrong: on a Unix system, I'd expect a program to
work anywhere and to seek its ancillary files in /lib or /usr/lib
or /usr/local/lib, and I'd be annoyed if it weren't configurable
enough to allow me to select an alternate location.  But when in
Rome, do as the Romans do: on a Mac, I'd expect a program and its
ancillary files to live together, and for the program to be able
to find them easily.  (As far as I know, a Mac program can do
this without any special programming at all.  Since the Mac has
nothing like the shell or any kind of command-line interface,
it doesn't have any kind of per-user or per-session "current
directory".  When a program is invoked, I'm pretty sure that
its "current directory" essentially is the folder where its
executable lives, so it finds its ancillary files by opening
them by their simple names, with no fancy pathnames at all.)

Notice, too, that the ancillary-files-live-in-the-same-directory-
as-the-executable scheme automatically handles the case (which is
not really so infrequent) where you're experimenting with two
versions of a program simultaneously, and the ancillary files for
the different versions are different, too.  If, on the other
hand, the ancillary files are supposed to reside in some central
directory, rigging things up so that there are two sets of them
and that each executable finds the correct set can be a real
nuisance.

I could even argue (but I won't, because it's doubly off-topic
for comp/lang/c) that having a program's ancillary files live
along with it in the same directory is a considerably more
"object oriented" way of doing it; that having one central
directory where every unrelated program stuffs its ancillary
files can be a nuisance to maintain and suffers the analogous
kinds of problems that object-oriented paradigms are supposed
to solve.

The fact does remain, though: no matter how nice it might be for
a program to be able to "find itself" in the filesystem, there's
no general, portable, reliable way for it to do so.  Any solution
to this problem is going to be more or less platform-specific.

                                        Steve Summit



Wed, 30 Aug 2000 03:00:00 GMT  
 Application Path

[...]
: I could even argue (but I won't, because it's doubly off-topic
: for comp/lang/c) that having a program's ancillary files live
: along with it in the same directory is a considerably more
: "object oriented" way of doing it; that having one central
: directory where every unrelated program stuffs its ancillary
: files can be a nuisance to maintain and suffers the analogous
: kinds of problems that object-oriented paradigms are supposed
: to solve.

It's also a major source of problems in several current desktop systems,
where programs sometimes put stuff not just into a central directory,
but into a central file.  The file rapidly gets choked with garbage,
reducing OS performance, and the directory is sometimes destroyed by
an OS re-install.

: The fact does remain, though: no matter how nice it might be for
: a program to be able to "find itself" in the filesystem, there's
: no general, portable, reliable way for it to do so.  Any solution
: to this problem is going to be more or less platform-specific.

Which is probably why a central directory is so often used.

Will



Wed, 30 Aug 2000 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. equivalent to app.path (return applications path) ?!??

2. Get application path from Windows Service Application

3. Getting Application Path in C#?

4. Application path - newbie

5. Application path and fopen()

6. Get calling application path

7. How do I get my applications path?

8. finding application path?

9. How do I get application path name

10. Application Path

11. Application path

12. How do I get the Application Path?

 

 
Powered by phpBB® Forum Software