From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b97aa4480eccc494 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: How to get the application path References: <46a456aa$0$25908$426a34cc@news.free.fr> <1185204459.328520.240930@z24g2000prh.googlegroups.com> <46a5e4e1$0$27850$39db0f71@news.song.fi> <0kbqe1zcrk.fsf@hod.lan.m-e-leypold.de> From: development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de (Markus E.L. 2) Date: Fri, 03 Aug 2007 00:23:12 +0200 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:Fh8f3yPzjtYVb9RZbiMQa6ANBsw= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.74.57.165 X-Trace: news.arcor-ip.de 1186092717 88.74.57.165 (3 Aug 2007 00:11:57 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news1.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!news.mixmin.net!news2.arglkargh.de!noris.net!newsfeed.hanau.net!news-fra1.dfn.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:1334 Date: 2007-08-03T00:23:12+02:00 List-Id: "Randy Brukardt" wrote: > "Markus E.L." > wrote in message news:o6vec14g46.fsf@hod.lan.m-e-leypold.de... >> >> > Markus E Leypold > writes: >> > >> >> Now, on Unix I'd just put a shell script wrapper in place of the > executable: >> > >> > Why do you limit this to "Unix"? Any operating system that supports >> > shells can do the same thing. >> >> Yes+No. In Unix I can just exec the real binary, so I don't have a >> shell process waiting until the the binary proper returns. In Windows >> the shell process will (AFAI understand it) exist until the >> application terminates and AFAIS (worse) it will even have a command >> line window open to the absolute irritation of the lay user. > That doesn't have to be the case, although getting rid of it requires yet > another program. (Essentially, you redirect the output to null, although > doing that specifically doesn't work. It took me several days of > trial-and-error to get that to work, and it's not certain to me what I did > specifically that made it work. A pity. :-). I think I have some glimmering how that could be done, but never actually tried it out (Hint: Openssh in Cygwin must do a similar redirection, because one can run a CMD.exe in a Cygwin session). > So I have my doubts that it would work with > another compiler, so I'm not going to share the details [Janus/Ada users can > ask, of course].) > >> I find the Unix way more palatable. >> >> >> MYPATH="$0" >> >> MYAPP="$(which $MYPATH.bin)" # locate the executable proper >> >> >> >> export EXE_PATH="$MYPATH" >> >> >> >> exec $MYAPP "$@" >> >> >> >> (untested, mind you). >> >> >> >> That would even put the full path in argv[0]. The power of shell >> >> script wrappers in Unix is usually underestimated. >> > >> > Scratch the "in Unix", and I agree. >> >> Could you tell me the equivalent of my script in CMD.exe? (Seriously, >> that's a real question: What I got until now I consider kludgy). > > Application paths in Windows are supposed to be set in the registry; "Path" > is supposedly obsolete. As I understand it, the application is started with the application path in the registry as current directory. That's how I store the installation location in the registry (during installation) and how I retrieve it: I can be sure the application "wakes up" in its own directory and the rest is there in application specific configuration files (I could use the registry more, but in most cases I like the option to edit text based config files). But my question wasn't this: My questions was: Instead of the application I want to run a shell script wrpper (e.g. from the start menu) and the start the application. Now I have 2 problems (a) Need to get rid of the command line window, can't have that. (b) Need to find out where the script is located from within the script (because that is also the place where the application binary will be). It seems, you can't do that in Windows as easily as you can in Unix. > (Yes, hardly anybody actually follows that > documentation.) As such, you're supposed to put the path into the icon or > (as we do) directly into the script [we have the installer create the > appropriate scripts for the user's machine]. Meaning there is no need for > such fancy scripts. Yes, there is something in this. Actually I also resorted to that solution at another time (but never really solved (a)). > If I actually had to do this, I'd simply write a Janus/Ada program to do it > (remember that all opens search the path in Janus/Ada, so getting the path > is just a matter of text processing the name). Not really. The binary application I'm talking about is not in the path (it should not, since I don't want to touch PATH) [Hm, I just know begin to understand what you mean by ApplicationPath: Application specific path variable?] > Ada is usually better than silly scripts anyway. Admitted. But you can't generate them at installation time. And at the very beginning (when the application starts) I can't find where the application is, so can't read it from the configuration files. > [Although these days I'd put the path into the registry and use the > Claw interface I mentioned last week to retrieve it.] Another solution :-). I originally tried to avoid it for various reasons (specifically avoiding platform specific parts in the program and wanting to make backup and restore of the software installation simple). > Moral: trying to make Windows work like Unix necessarily makes tasks harder > than they need to be. I never doubted that. :-). Indeed I already admitted that. I quoted the shell script because SL wrote: | > > Why do you limit this to "Unix"? Any operating system that | > > supports shells can do the same thing. and I had my doubts about that (which you basically confirmed). > (The converse is also true, of course.) Very much like > using Ada as if it is C. Regards -- Markus