If I save an application (using deliver) in LispWorks, and move it
somewhere, can I determine where it is run from?
*lispworks-directory* will return the directory where lispworks was
installed, and not the location of the running application.
Thanks,
Kevin
"Kevin Sewell" <········@btopenworld.com> wrote in message
·······································@4ax.com...
> If I save an application (using deliver) in LispWorks, and move it
> somewhere, can I determine where it is run from?
>
> *lispworks-directory* will return the directory where lispworks was
> installed, and not the location of the running application.
>
I've been using (hcl:get-working-directory), though that is obviously not
portable.
--
Coby beck
(remove #\Space "coby 101 @ bigpond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Kevin Sewell" <········@btopenworld.com> wrote in message
> ·······································@4ax.com...
> > If I save an application (using deliver) in LispWorks, and move it
> > somewhere, can I determine where it is run from?
> >
> > *lispworks-directory* will return the directory where lispworks was
> > installed, and not the location of the running application.
> >
>
> I've been using (hcl:get-working-directory), though that is obviously not
> portable.
Download CL-ENVIRONMENT from the CLOCC and voila`
(cl.env:cwd)
Portable and easy.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
I'm trying to get this to work on Windows, using LispWorks 4.1
Professional, but I'll need it portable in the long term.
BTW, I've mistitled this thread. Perhaps I should have written:
"lispworks launch directory (windows)"
Thanks for your replies.
(hcl:get-working-directory) does indeed return the cwd, but this is
set to the user's home directory.
I've downloaded CL-ENVIRONMENT from CLOCC and tested. Neat.
However, (cl.env:cwd) does not exist.
In cl.env:system-info, it reports the current directory as
(truename "."), which again gives the user's home directory.
I plan to distribute my app (using deliver), along with a number of
files I need to read from. These will be sitting next to the
application. I just need the path where they are.
Thanks again,
Kevin
On 15 Feb 2002 17:46:15 -0500, Marco Antoniotti <·······@cs.nyu.edu>
wrote:
>
>"Coby Beck" <·····@mercury.bc.ca> writes:
>
>> "Kevin Sewell" <········@btopenworld.com> wrote in message
>> ·······································@4ax.com...
>> > If I save an application (using deliver) in LispWorks, and move it
>> > somewhere, can I determine where it is run from?
>> >
>> > *lispworks-directory* will return the directory where lispworks was
>> > installed, and not the location of the running application.
>> >
>>
>> I've been using (hcl:get-working-directory), though that is obviously not
>> portable.
>
>Download CL-ENVIRONMENT from the CLOCC and voila`
>
> (cl.env:cwd)
>
>Portable and easy.
>
>Cheers
"Kevin Sewell" <········@btopenworld.com> wrote in message ·······································@4ax.com...
> I'm trying to get this to work on Windows, using LispWorks 4.1
> Professional, but I'll need it portable in the long term.
>
> BTW, I've mistitled this thread. Perhaps I should have written:
> "lispworks launch directory (windows)"
> <SNIP>
There is a LispWorks mailing list that quite a few LispWorks users
seem to be unaware of (not implying you are one of them, but this
email is in case you are). Emails to that group get very fast responses
from Xanalys development staff and I watch most people go away
happy with the responses. It could be worth a try. They're mature
enough Lisp professionals to try to give you a portable answer.
To subscribe send email to ·········@xanalys.com with the
text "subscribe lisp-hug" (double quotes are mine of course) on a
new line in the body of the message. You email to the group by
sending to ········@xanalys.com. When you subscribe you get an
instructional email back that gives you the list server commands to
request an archive of past emails and other stuff.
Hope that maybe helps move you forward. Sorry I can't answer your
question directly.
- Julian.
On Sat, 16 Feb 2002 11:57:03 GMT, "Julian" <······@123lomberg456.net>
wrote:
>"Kevin Sewell" <········@btopenworld.com> wrote in message ·······································@4ax.com...
>> I'm trying to get this to work on Windows, using LispWorks 4.1
>> Professional, but I'll need it portable in the long term.
>>
>> BTW, I've mistitled this thread. Perhaps I should have written:
>> "lispworks launch directory (windows)"
>> <SNIP>
>
>There is a LispWorks mailing list that quite a few LispWorks users
>seem to be unaware of (not implying you are one of them, but this
>email is in case you are). Emails to that group get very fast responses
>from Xanalys development staff and I watch most people go away
>happy with the responses. It could be worth a try. They're mature
>enough Lisp professionals to try to give you a portable answer.
>To subscribe send email to ·········@xanalys.com with the
>text "subscribe lisp-hug" (double quotes are mine of course) on a
>new line in the body of the message. You email to the group by
>sending to ········@xanalys.com. When you subscribe you get an
>instructional email back that gives you the list server commands to
>request an archive of past emails and other stuff.
>
>Hope that maybe helps move you forward. Sorry I can't answer your
>question directly.
>
>- Julian.
>
I didn't know about the list. I'm new to LispWorks. I've subscribed.
Thanks.
I've received a response to this thread via email (thanks Tim), which
agrees with Coby about HCL:GET-WORKING-DIRECTORY.
Now, I did look at that previously, but dismissed it. When run from
the LispWorks development environment, this variable is set to the
user's home directory. As is (truename ".") and (lw:current-pathname).
This is understandable. However, from a saved console application, it
is set to the location of the app. As is (truename ".") and
(lw:current-pathname). This is understandable too, but not expected.
Since I load files sitting next to my application, I'll have to put
the files in the *root* of my home directory when using the
development environment, and next to the app when its saved. That's
fine, but it seems a bit of a hack to me. I would like the path to the
running app, no matter what sort of app it is. Perhaps the LispWorks
mailing list will help, as it is probably a vendor issue. I'll have to
revisit this when porting.
I've come from MCL where I use "ccl:".
Oh, and Corman Lisp seems to set *default-pathname-defaults* as
required.
Anyway, I can carry on now.
Thanks, and regards,
Kevin
From: Tim Bradshaw
Subject: Re: lispworks current directory
Date:
Message-ID: <ey33d013twa.fsf@cley.com>
* Kevin Sewell wrote:
> Now, I did look at that previously, but dismissed it. When run from
> the LispWorks development environment, this variable is set to the
> user's home directory. As is (truename ".") and (lw:current-pathname).
> This is understandable. However, from a saved console application, it
> is set to the location of the app. As is (truename ".") and
> (lw:current-pathname). This is understandable too, but not expected.
I'm assuming that you're doing this on Windows. If that's correct,
then I think the answer is that, on windows, the current directory of
applications is just fucked up in general, and what CURRENT-PATHNAME
is telling you is that current directory.
On Unixoid systems, that directory will be whatever the working
directory of the process that execd the Lisp (typically the shell)
was, but on Windows it can be any of about a million things (for
instance a shortcut can say `run in' some other directory to make your
life more interesting).
I *don't* think it's safe to assume that it is the same as the
directory the application binary came from though: this will almost
never be true on Unix and, though it might more commonly be true on
Windows it certainly does not have to be true. I'm not sure how to
know what that is reliably even on Unix. I think your best bet is to
look at argv[0] and hope it's a full pathname. I think there's an LW
equivalent to argv, and looking at the element corresponding to the
binary might be informative.
--tim
In article <···············@cley.com>, Tim Bradshaw wrote:
> I'm not sure how to know what that is reliably even on Unix. I think
> your best bet is to look at argv[0] and hope it's a full pathname.
That's about what the Unix Programmer's FAQ says:
1.14 How can I find a process' executable file?
=============================================== i
# This would be a good candidate for a list of `Frequently Unanswered
# Questions', because the fact of asking the question usually means
# that the design of the program is flawed. :-)
# You can make a `best guess' by looking at the value of `argv[0]'.
# If this contains a `/', then it is probably the absolute or relative
# (to the current directory at program start) path of the executable.
# If it does not, then you can mimic the shell's search of the `PATH'
# variable, looking for the program. However, success is not guaranteed,
# since it is possible to invoke programs with arbitrary values of
# `argv[0]', and in any case the executable may have been renamed or
# deleted since it was started.
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID 0x42B32FC9
______________________________________________________________________
Posted Via Uncensored-News.Com - Still Only $9.95 - http://www.uncensored-news.com
With NINE Servers In California And Texas - The Worlds Uncensored News Source
Kevin Sewell wrote:
> I plan to distribute my app (using deliver), along with a number of
> files I need to read from. These will be sitting next to the
> application. I just need the path where they are.
I use the function lw:current-pathname for this.
Arthur Lemmens
Kevin Sewell <········@btopenworld.com> writes:
> I'm trying to get this to work on Windows, using LispWorks 4.1
> Professional, but I'll need it portable in the long term.
>
> BTW, I've mistitled this thread. Perhaps I should have written:
> "lispworks launch directory (windows)"
>
> Thanks for your replies.
>
> (hcl:get-working-directory) does indeed return the cwd, but this is
> set to the user's home directory.
>
> I've downloaded CL-ENVIRONMENT from CLOCC and tested. Neat.
> However, (cl.env:cwd) does not exist.
My mistake. I meant the CL-ENVIRONMENT in the CVS. I will make a new
"File Release" ASAP.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> "Coby Beck" <·····@mercury.bc.ca> writes:
>
> > "Kevin Sewell" <········@btopenworld.com> wrote in message
> > ·······································@4ax.com...
> > > If I save an application (using deliver) in LispWorks, and move it
> > > somewhere, can I determine where it is run from?
> > >
> > > *lispworks-directory* will return the directory where lispworks was
> > > installed, and not the location of the running application.
> > >
> >
> > I've been using (hcl:get-working-directory), though that is obviously not
> > portable.
>
> Download CL-ENVIRONMENT from the CLOCC and voila`
>
> (cl.env:cwd)
>
> Portable and easy.
Hmm. Not commenting on this directly, but isn't this what
*default-pathname-defaults* is for? I mean, I know that the CLHS says
"typically", but still... it doesn't seem like too much of a cost for
implementations to follow this idea, which solves quite a lot of
things, yet initial *d-p-d* values in implementations can be, erm,
idiosyncratic.
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Christophe Rhodes <·····@cam.ac.uk> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > "Coby Beck" <·····@mercury.bc.ca> writes:
> >
> > > "Kevin Sewell" <········@btopenworld.com> wrote in message
> > > ·······································@4ax.com...
> > > > If I save an application (using deliver) in LispWorks, and move it
> > > > somewhere, can I determine where it is run from?
> > > >
> > > > *lispworks-directory* will return the directory where lispworks was
> > > > installed, and not the location of the running application.
> > > >
> > >
> > > I've been using (hcl:get-working-directory), though that is obviously not
> > > portable.
> >
> > Download CL-ENVIRONMENT from the CLOCC and voila`
> >
> > (cl.env:cwd)
> >
> > Portable and easy.
>
> Hmm. Not commenting on this directly, but isn't this what
> *default-pathname-defaults* is for? I mean, I know that the CLHS says
> "typically", but still... it doesn't seem like too much of a cost for
> implementations to follow this idea, which solves quite a lot of
> things, yet initial *d-p-d* values in implementations can be, erm,
> idiosyncratic.
(First of all: the function is in the CVS. I will make an updated
"File Release" ASAP)
You are right that *default-pathname-defaults* covers a lot of ground
in this case. But the (sad) reality is that it does not. All the CL
implementations have a peculiar function to get the "cwd". This is one
of those cases that screams for portability.
sds' port library in the CLOCC contains similar code. The one in
CL-ENVIRONMENT is really an exercise to test the capabilities of
CL-ENVIRONMENT itself. CL-ENVIRONMENT is sort of an implementation of
S. Keene's book example about operanting systems and programs. The
main thing that CL-ENVIRONMENT provides is a boiler plate of variables
and functions that allow you to "portably" inquire about the CL
environment you are working in. E.g. using CL-ENVIRONMENT you are
guaranteed to always have the variables (actually symbol macros)
CL.ENV:*OS*, CL.ENV:*CL* and CL.ENV:*MACHINE* bound to instances on
specific classes.
* cl.env:*cl*
#<CL.ENVIRONMENT:CMUCL {48389B0D}>
* cl.env:*os*
#<CL.ENVIRONMENT:LINUX {48389CD5}>
* cl.env:*machine*
#<CL.ENVIRONMENT:INTEL-X86-MACHINE {48389DF5}>
(well, maybe these should be constant looking :) ).
I find this an inprovement over the LISP-IMPLEMENTATION-{TYPE,VERSION}
functions.
I use CL-ENVIRONMENT and the file system to avoid the #+/- jungle you
see in a lot of CL programs (MK:DEFSYSTEM is a sorry example :) ).
As a side effect, CL-ENVIRONMENT provides a "standardized" (quotes
mandatory) set of features tags that allow you conditionalize whatever
you want.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
"Kevin Sewell" <········@btopenworld.com> wrote in message
·······································@4ax.com...
> If I save an application (using deliver) in LispWorks, and move it
> somewhere, can I determine where it is run from?
>
> *lispworks-directory* will return the directory where lispworks was
> installed, and not the location of the running application.
The (currently) internal variable system::*run-file-name* contains the name of
the LispWorks executable.
--
Martin Simmons, Xanalys Software Tools
······@xanalys.com
rot13 to reply