#How do MakeLink work
10 messages in this thread
I try to keep my "C" library pure, therefore the program muchmore can be
found in a library call "bin". It seems that all "doc_file" info_icons
point to c for muchmore.
WB2 answer is use MAKELINK. Which I do. It appears to user one block for
the pointer. So far so good. Which leads me to these questions.
(1) Does the pointer point to the directory or as it appears to location of
the program? I deleted the "real program" and the link still worked. (2)
What happens if you reorganize your HD? (3) Is there a way to cross
reference what is LINKED?
Allan Baer ( Be part of the solution, not part of the problem. )
Allan, I don't know about 'MakeLink', but know that the new WB2.0 'ASSIGN'
command will do what you want. It now accepts multiple directories, so you
could assign both your regular 'C' dir and your 'BIN' dir to 'C:'…. That
way any program looking for something in 'C:' would check both dirs. Neat.
Is MakeLink a new WB2.0 command? I guess I'd better reread the docs 🙂
–jp–seattle–
John, I just the assign command "assign c: sys:c sys:bin". The icon
info file pointed to :c/muchmore. It could not find the program. So I
went back to makelink and it worked. Did I do something wrong??????
Allan Baer ( Be part of the solution, not part of the problem. )
allan, your ASSIGN command looks correct. I think I see where the problem
is coming in though….
Your icon path is: ':c/muchmore'
What you have here is a very specific path, not the *assigned* c:
directory. The colon as the first character tells the system to start with
the root directory (which varies by how your system is set up), and then it
builds a path from there. So, roughly evaluating the path would lead to:
: start with your root directory, say: dh0:
c/ move to the c directory there: dh0:c
muchmore dh0:c/muchmore
The key is that you never really accessed 'c:'. You build a specific path
from scratch. So unless you have muchmore in this path, you will get a
file not found message.
Solution? Two that I see: 1) change the icon path to read: 'c:muchmore'.
Now you're accessing 'c:' and your ASSIGN statement should take care of it.
2) put 'sys:bin' in your search path. ie. 'PATH sys:c sys:bin'. That
should do it. I think.
–jp–seattle–
I don't know if it's documented, but the 2.0 Workbench will search the path
when loading DefaultTools. So you could change that :c/muchmore to just
plain muchmore and be universally compatible (with other people's 2.0
systems anyway)
Jim,
You have to be carefull and make sure that you've got a reasonable path
set up _before_ you do the LoadWB or do a LoadWB NEWPATH after you DO have
the path the way you want it.
John, What I was trying to do was NOT TO MODIFY the icon. And MAKELINK
for me is the answer. Have you read the docs on makelink? Do you read
answer sent by Don Curtis? Well where is his answer anyway.
" Allan,
All files are essentially linked files. That is, each file has a
header that points to where the actual file data is. MakeLink adds a 2nd
header that also points to the same file, but it also increases the
linkcount of the file.
When you remove one of the linked file, all that's really done is
removal of the one header and a decrement of the link count. The other
header is still there, still pointing to the same data. "
Allan Baer ( Be part of the solution, not part of the problem. )
I understand that. And I can see how MakeLink would solve that particular
problem. Still seems to me, however, that the PATH option is best, because
that puts your SYS:BIN drawer in the search path all the time, so you
wouldn't need to worry about the same thing happening with other progs you
have in SYS:BIN. To each their own. All I was trying to do was explain
why the icon path wasn't working as you expected. Glad that MakeLink works
for you.
–jp–seattle–
Allan,
All files are essentially linked files. That is, each file has a
header that points to where the actual file data is. MakeLink adds a 2nd
header that also points to the same file, but it also increases the
linkcount of the file.
When you remove one of the linked file, all that's really done is
removal of the one header and a decrement of the link count. The other
header is still there, still pointing to the same data.
Don