Re: How to get the application path
- From: development-2006-8ecbb5cc8aREMOVETHIS@xxxxxxxxxxxxxxxxxxxxx (Markus E.L. 2)
- Date: Fri, 03 Aug 2007 00:23:12 +0200
"Randy Brukardt" wrote:
"Markus E.L." <development-2006-8ecbb5cc8aREMOVETHIS@xxxxxxxxxxxxxxxxxxxxx>
wrote in message news:o6vec14g46.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx
<development-2006-8ecbb5cc8aREMOVETHIS@xxxxxxxxxxxxxxxxxxxxx> writes:
Markus E Leypold
executable:
Now, on Unix I'd just put a shell script wrapper in place of the
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
.
- References:
- Re: How to get the application path
- From: Markus E.L.
- Re: How to get the application path
- From: Randy Brukardt
- Re: How to get the application path
- Prev by Date: Re: Byte streams
- Next by Date: Re: AW: To := Grein, Christoph (Fa. ESG)
- Previous by thread: Re: How to get the application path
- Next by thread: Re: Unary operator after binary operator: legal or not?
- Index(es):
Relevant Pages
|
Loading