Henry wrote:
> "Put J on your USB drive" is not part of a solution, though.
Can you include even a little bit of custom (bootstrap) code along with the
standard J installation?
This statement makes me think you would like to avoid that:
> A change to cfgread.ijs, if it could be thought
> out & made standard, would be a step forward.
OTOH, if you're willing to create an application icon above-and-beyond the
standard J icons, then I assume you're spending at least a little extra
time at each machine at install time, which would give you an opportunity
to drop a bootstrap script in the J install folder.
Another option is to deliver the bootstrap script as an JAL Addon. That
has the advantage that it's remotely updateable, and if you can train your
teachers to download and install J and use Edit|Configures|Folders, then
they're probably also savvy enough to use Tools|Package Manager. And
obviously if the machine has internet access to download J, it can also
download a JAL Addon [1]. Of course, if you can deliver the *entire app*
as a JAL Addon, this whole USB problem goes away (and it makes upgrading
your app much easier).
But I'm going to take this statement at face value :
> The app MUST be on a shared disk
Which might be a security policy at your school. However, this requirement
is why you must have some way of delivering at least a little bit of
custom code. If you can't, then you have a catch-22. If you can't
include custom code, then by definition all you have is the J standard
library, and my readcfg changes can't help you. Remember that my
suggestion was to replace X: with 2{.BINPATH , but you said:
> J must come from the school computer,
> NOT the USB drive.
So 2{.BINPATH won't work (because BINPATH is where J is running from, and
that's on the HDD, not on the USB where the code is). So what do we use
in lieu? The problem isn't even that you don't know which drive letter
the USB has (the topic of this thread); let's assume you had some magic J
verb named pathToUSBCode to determine that [2]. The question is: where
(not how) would you define this verb? Though some variation of my concept
might be reasonable to include in the standard distribution [3], certainly
the logic in pathToUSBCode is application-specific and belongs in
user-space, not in system-space.
So, bottom line, here are your options:
(1) Install J locally and deliver the entire app as a
JAL Addon (preferred)
(2) Install J on the USB drive and deliver the entire app
on that same USB drive, and have teachers launch it from
there (also good).
(3) Install J locally and deliver a little bit of bootstrap
code that somehow defines and uses a verb pathToUSBCode
(a) Deliver this bootstrap code manually at the time of
install (as a script).
(b) Deliver this bootstrap code as a mini-JAL Addon, as in
(1).
I've listed these options in the order of (my) preference. Unless you're
constrained by school security policy, I see no reason to select (3).
Note that most modern versions of Windows pop up a dialog when a USB key
is inserted, prompting the user to select an action - this action by
default is "explore drive", and if that option is selected, then the
teacher could just double-click the big bright icon named "HEY TEACHER
DOUBLE-CLICK ME". This is fairly "clueless-proof".
-Dan
[1] Modulo proxy obstacles; see:
http://www.jsoftware.com/jwiki/DanBron/WgetAndProxies .
Which is not at all "clueless-proof".
[2] I have a couple of ideas for how to define pathToUSBCode .
First, enumerate all the drives on the machine, then:
(1) Either list their root contents and select the drive
which contains a file named Hey_Im_Henry_Richs_J-USB.drive
or something equally unique, or
(2) Interrogate the drive's properties via the Windows API
(whatever API call gives the information listed when you
right-click the drive in Windows Explorer and select
"Properties") and select the one with the volume name
"Hey Im Henry Rich's J USB Drive" or something equally
unique.
The first option would probably be easier and would allow you
to put extra information in the file (like application version
information, which would allow you to handle backwards/forwards
compatibility issues). Either is likely to increase your app's
startup time by a few seconds.
[3] But instead of naming our placeholder "X:", we should use some
invalid drive name, like "7:", to avoid clashes with legit
drives named "X:".
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
