PathMan Volume ??
32 messages in this thread
John,
What gives you the impression that a file can be found quicker by
searching through several directories (with PathMan) rather than one. The
AmigaDOS file system was specifically designed to find a file with known
name in one directory VERY quickly.
I hadn't meant to say that the system can find a file faster with PathMan
than by searching individual dirs…. did I say that? 🙂
I was only trying to make the point that some programs require their ARexx
programs/macros to be placed in the REXX: assigned drawer. Well, I don't
want my DH0:rexx drawer full of lots of different stuff…. PathMan allows
me to put the progs/macros in different drawers, and they still work, since
the systems sees ALL the drawers as REXX: (ie. Assign
path:dh0:rexx,dh0:prog1,dh0:prog2 etc)
There's no way to do that (in 1.3) aside from PathMan, is there? (2.0 has
a multiple dir ASSIGN command, I know)
–jp–seattle–
On a related note, has anyone come up with an alternative for managing the
path a bit better than the C:PATH command? For example, I recently helped
rearrange Harriet's hard disk so she could easily switch between compiling
under Manx 3.6 and 5.0
. It would be much nicer to be able to have a CLI command to cut and snip
the path apart, replacing just a single directory instead of being forced
to rase it all, then replace it. Whoops, that's 'erase it all'.
On another tack, I've like to dig up the source to Haynie's 'bindnames' to
have it accept a simple filename as the source of assignments, to allow
comments, and to have it simply de-assign all the entries in a given file,
ignoring the right hand side.
John,
I'd settle for having the PATH command follow "assign names" instead of
binding them all at the time the PATH command is executed. E.g., if I want
to have LC: in my path (and I do), then if I do a new "assign LC:
<wherever>" it ought to pick up files from <wherever>.
Vic, the PathMan PATH: does just that. It follows the assignment of names,
rather than binding specific directories. You might find it useful?
–jp–seattle–
John, I think you CAN do exactly what you want, using PathMan and the
regular ASSIGN command.
PathMan interprets any 'assigns' in its list each time the 'path' is
called. That means that is your PathMan list includes 'lib:' as one of
it's locations, then you can later reassign 'lib:' to another directory and
PathMan will follow it whereever you go. Make sense?
So, think of any ASSIGNed names in the PathMan list as being able to be
'cut and snipped' like you said. Works fine.
Only ding I find is that if you later want to GET RID of an assign
altogether, so you so a 'ASSIGN LIB:', (ie. killing the lib: assignment);
well, each time you access it you will get a requestor asking for that
killed dir. Solution seems to be to just 'ASSIGN LIB: dh0:EMPTY' and
assign it to an empty drawer. Same effect.
–jp–seattle–
Hmmm,
Didn't realize that PathMan follows assignments when they move! Great!
Learn somethin' new every day here!
…BobR
Many thanks to you and Vic and Bob… the thought of an indirection such
as CCBIN: in the middle of the path made lightbulbs flash over my head, but
in reading Vic's message, I would tend to believe that the path gets locked
at the time it's instantiated, meaning a subsequent re-assignment of CCBIN:
would have no effect. We do run a WShell and ARexx environment at Syndesis,
so Bob's trick might work out, too. From your statement, you're saying
that PathMan re-evaluates any logical assignment every time it's accessed,
or is it more like AmigaDOS PATH in that the assignment is "frozen" at the
moment that particular CLI is launched? We don't run PathMan. It always
made me kind of nervous, although I'm sure it shouldn't. Like, if I write
to one of those extended assignments, where does the file get made? Is
that well-defined?
John,
You have hit on the one _real_ problem with the extended assigns —
where does the file get written? From my limited playing around, I've
found that it a file "created" in an extended-logical ends up in the first
directory in the 'list'. Writing to an existing file ends up in the
directory in which the file resides. Unfortunately, most editors that I
have used save an existing file by first renaming the old to xxx.bak, and
then write the new data to a "new" file. Consequently, I only use the
extended assign logical device as a "read-only" device, enforced only by
"gentleman's agreement". When I'm going to be modifying a file, I'll use a
more explicit path.
I do hope you'll look into using PathMan, though. That way you'll have
an incentive to fix the Interchange file-requester, which has problems with
the long "logical names" that end up being associated with the TAO:
pseudo-device. <ducking>
…BobR
Hey, I have nothing to do with that end of the code. 🙂 Check the
credits at the start of the manual; that's Harriet's department. I do all
the translation stuff, not the Intuition nightmare. Give me a well-defined
file format, any day.
Oh. Forgot to ask you exactly what's wrong, so I can pass that bug
along…
John,
The problem occurs if one attempts to "cycle" through the available
devices – once it hits the TAO: device (which is the device added by
PathMan), it attempts to display the logical "name" corresponding in the
'path' gadget, and is surprised by the very long name that corresponds –
firework city. The work-around is to avoid using the cycle gadget, and go
directly to the 'path' string-gadget, and specify the drive/path directly.
While we're on the subject, I personally never did like 'cycle'-type
gadgets, especially for selecting devices. I much prefer being given a
list from which to choose, when requested. I know that CATS has endorsed
the 'cycle' gadget as an approved interface object, but that doesn't mean
that I have to like 'em. 🙂
This isn't a major bug, as long as one uses the program frequently
enough to 'remember' the old "Patient: Doctor, it hurts when I do this.
Doctor: So don't do it!". <grin>
…BobR
Hmm. Yup, I bet that crashes. I'll ask Harriet to reproduce it, which
means we need to install PathMan, of course. We'll be able to get the fix
into the InterChange Plus release in a few weeks.
Actually, you don't need to fix the file requester — Bill has included a
way of fixing PathMan! The trick is that, after you assign a PATH:, you
can give it a filenote as in:
assign foo: path:ram:,dh0:,more_very_long_path_definitions filenote foo:
"my_short_path_name"
PathMan treats the filenote as an alias for the path and inverts the name
with the comment and avoids problems with file requestors that don't check
the length of names.
David – via Whap!
David,
Thanks for the tip — I didn't know that! I'm generally pretty good
about reading manuals for software when I first get it too. Must have
missed that, or installed the package during a "crunch" time.
…BobR
So there is a use for the 'filenote' capability! Now I see the usefullness
of it. Thanks.
Any other interesting uses of the 'filenote' capability in PathMan that you
are aware of? I always wondered what I'd use it for.
–jp–seattle–
Just the usual for 'FILENOTE'. I believe the Tao: object is set up like a
directory with files that have the path definitions in them. Therefore,
FILENOTE can be applied to those files if you want an extra comment. This
is a guess, though. I got that trick from Bill last year when Atalk III
would blow up when its file requester cycled through Tao: and the long
REXX: path I'd set up. It didn't strike me as a solution when I first saw
it in the documentation either.
David – via Whap!
Bob,
Your not the only one who doesn't care much for cycle gadgets. The two
programs I know of with them are BackTalk and ADPro. At least BackTalk has
the gadget! I care even less for the way it is done on ADPro.
I would prefer lists, also, but they also take up more room on the
screen/requestor/what ever. One way cycle gadgets should be inproved is to
have another gadget for cycling the other way, or when you hold down the
shift key the gadget cycles in reverse. I hate it when I cycle right past
my selection!
73, Kelly
Kelly,
The Amiga Style Guide says you CAN cycle backwards if you hold down the
shift key. Isn't everyone doing it that way?
Kelly,
GadTools cycle gadgets DO cycle both ways — if you click on them they go
forward, shift click and they go backwards.
-sja
You do realize that the ADPro cycle gadgets are reverible, don't you?
Hit the right side of the gadget, and it cycles forward.
Hit the left side of the gadget, and it cycles backwards.
I always liked it's method. But it does get tiresome when you are cycling
through the operators, and the list is loooong. I would vote for the
drop-down list, except that it isn't supported under the style guide.
–jp–seattle–
1) yeah, PathMan reevaluates the path each time you use it, so if you
change any assignments in the interim, it will pick them up. The path is
not frozen with absolute dir names, etc; if that's what you mean.
2) Re, where does a write go to, yes it is well defined.
If it is a brand new file, it will be put into the first writable directory
in the path.
If it is a file you had previously opened, PathMan will find the directory
it opened the original file in, and put the write back in the same
directory. (bunch of technical stuff about ACTION_FINDOUTPUT and stuff, I
don't know exactly what it means, but it seems to work) 🙂
All this is on p. 73 of the WShell manual. I'm sure that you'd understand
Bill Hawe's explanation better than mine. 🙂
3) Note that I said 'writable' directory. PathMan allows you to specify
attributes for these assigned direcotories, and to mix them in the path.
So, you can have several 'write protected' dirs mixed with one that is
normal. When deciding where to write the file, the 'write protected' dirs
will be skipped.
There's also path "alias's" and something about switching the file name and
filenote…. I wish someone would explain this to me. I just can't seem to
grab the usefullness (or even USE) of it. 🙂
–jp–seattle–
PathMan normally creates a file in the first writable directory of a path,
but first checks whether a file of that name already exists somewhere on
the path. If it does, PathMan writes it back to the original location.
Paths can be selectively write-protected at the PathMan level to prevent
files from being written into certain directories.
-Bill Hawes
I think you can do 'assign lib: remove' to remove lib: from the assign list
altogether (I guess assuming it isn't currently locked).
David – via Whap!
Yeah, you can do that, but it doesn't solve the problem. PathMan still
keeps the 'LIB:' assign in its internal list. The system will still put up
a requestor asking for the volume (even after you've 'unassigned' it). The
only way I see around it is to change the assignment to something empty
(drawer or such).
–jp–seattle–
Maybe you have to delete it from Tao? Try 'list'ing Tao: and see if you
can delete things from it like any other directory…
David – via Whap!
Well, a 'list' of Tao: does show that it's files can be deleted. Here's
what it looks like: (with date created, etc stripped off)
LIST TAO:
Directory "tao:dh0:wb20/c,dh0:wb20/c2,dh0:wb" on Wednesday 16-Oct-91
dh0:wb20/c,dh0:wb20/c2,dh0:wb/c Dir —-rwed
dh0:wb20/libs,dh0:wb20/libs2,dh0:wb/libs Dir —-rwed
dh0:wb20/l,dh0:wb20/l2,dh0:wb/l Dir —-rwed
dh0:wb20/devs,dh0:wb20/devs2,dh0:wb/devs Dir —-rwed
dh0:wb20/system,dh0:wb20/system2,dh0:wb/system Dir —-rwed wb:fonts
Dir —-rwed 6 directories – 6 blocks used
So, you see, there's really nothing to 'delete'. I'd need to 'rename' the
'dir' in order to get rid of the path contents. If I'm gonna do that, then
I may as well just reASSIGN the whole path. See what I mean?
Just assigning a name to an empty dir isn't a problem, so I think I'll just
live with it.
–jp–seattle–
John,
I've battled that path problem before. My solution ended up being an
ARexx script that basically does the parse, analyze, and re-arrange.
Unfortunately, it is written in such a way that it requires WShell as well
as ARexx. I also maintain my own "path string" in an ARexx CLIP variable,
and access that variable when starting up a new shell (via the
wshell-startup script).
It is doable, but it isn't pretty. <grin>
…BobR
2.0 PATH allows you to remove single path entries…so you don't have to
erase and reset.
andy
John and Vic,
I used PathMan with a Rad:. I assign every thing to the rad
directory and to the DF0 directory. That way when I installed a disk that
used things contained solely within itself, they could be found.
Another applicatipon is DTP with floppies. The Fonts can be spread between
df0 and df1 with rad taking care of every thing else.
-Tom
JP:
I tried using PathAssign for multiple paths but found it was too slow and
had other problems. If PathMan sets up an icon on the WB, I don't want it.
As for 2.0 ASSIGN, only the first assigned directory will be accessed by
everything (list, type, which, execute, etc) the other multiple(s) will
only be used as an executable filename directly on a CLI.
For example:
Assign S: Sys:S Work:S
Will assign the S: to SYS:S and Work:S
If you LIST S:you will only see SYS:S. EXECUTE and WHICH will also only
see SYS:S. If you have a script with the S bit set you can execute it
directly on the CLI. For example:
Test.txt
Will execute the Text.txt script if the S bit is set even if it is in the
Work:S directory.
I would think 2.0 OS would handle this, not the above mentioned programs
but it doesn't.
JohnB 76256,3436 – via Whap!