Wolfgang Lenerz wrote:
There has been some talk on this list about some form of
"currrent directory" or "home directory" for programs that
are being executed.

As far as I understand it, the purpose of such a directory is to
give the program the name of the directory from which the file was
executed, so that, for example, it can find a configuration or data file
in that directory.


This facility as such doesn't exist in the QL world.

I propose to incorporate it into SMSQE.
I look forward to it, and I don't really care how it's written as long as my little new programs can do something like:

(assumes you provide a function called HOME$ which returns where the current program was EXEC'ed from)
(CHECK is an imaginary extension which checks for the presence of an extension, there's several in PD)


IF CHECK("HOME$") = 1 THEN
configdatafile$ = HOME$ : REMark I was EXEC-ed from home$
ELSE
configdatafile$ = PROGD$ : REMark I'll assume I was started from PROGD$ default directory
END IF


Assuming newly written programs understand the "home directory" concept, it shoud also be possible for that program to run on a non-HOME-knowing OS, even if the fallback is only something like above, or even

IF CHECK("HOME$") = 1 THEN
configdatafile$ = HOME$
ELSE
IF CMD$<>"" THEN
configdatafile$ = CMD$:REMark default was passed as option command string
ELSE
configdatafile$ = PROGD$
END IF
END IF


Somewhat contrived examples but hopefully showing that I foresee the main use as where to load the program's data files from.

HOME$ - would it need to return just the directory or drive+directory from whence the job came?

Add whatever complicated and fancy features you want, I'd ask you to remember to make it simple to use.

As to whether it's a thing or not, again I don't really mind as long as it's available when needed and jobs tidy up after themselves, i.e. if you RJOB a program before I issue a CLEAR_HOME$ or whatever in my program, the thing shouldn't get stuck in memory I can't reclaim!

At a guess, whatever is the code in the OS for the low level equivalent of EXEC would have to extract the directory name and put it somewhere accessible to the job. Probably can't be stored in the job itself as this makes it self modifying code.

---> Finally, progs executed from memory (executable things) would
probably not have a home directory, unless a facility is set up
whereby a default home dir is set up for programs with a certain
name.
Using my HOME$ example, HOME$="" means it didn't come from a directory device, e.g. it was executed from memory where it had been HOT_RESed or whatever.

As to how many commands like EX, EW etc have to be modified, is it feasible to change these down at a lower OS level in some way, so that EXEC, EX, EXECUTE, QX etc etc all do their existing work, the necessary string is placed somewhere by the OS. I don't really see how this could work, program execution probably doesn't happen in a way that would make this feasible. Just a thought.

No doubt everyone will see this in different ways. This is a much needed new facility and I hope it will get added and that people will make good use of your hard work.

--
Dilwyn Jones



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 06/01/2005

_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Reply via email to