waggoner@berlioz (Mark Waggoner) (08/26/89)
Number 579 in the 1.4 wish series.
I really want a 'toolpath' for workbench. I really hate it when
workbench can't find a project's tool just because the tool either
isn't installed in some specially named place or it is in a different
place on machine A than it is on machine B. One of the nice things
about the Mac is that it will find a tool for you if it is available
anywhere.
What I propose:
1. Workbench would first look for the tool using the name in the
default tool field of the project WITH DISK REQUESTERS TURNED OFF.
2. If not found, Workbench searches for the tool in the 'toolpath'
(perhaps an environment variable? )
3. If still not found - and the default tool specifies an absolute
path, turn on the disk requesters and look for it again.
4. If STILL not found - put up a REQUESTER to the effect:
'Could not find the tool XXXX for project XXXX'
NOT a silly error message in the title bar. Maybe even
CENTER IT ON THE SCREEN!
So... is it 'in there'?
--
,------------------------------------------------------------------.
| Mark Waggoner (408) 721-6306 waggoner@icebox.nsc.com |
| mail troubles? try: waggoner@logic.nsc.com |
`------------------------------------------------------------------'rtczegledi@crocus.waterloo.edu (Richard Czegledi) (08/26/89)
In article <688@berlioz.nsc.com> waggoner@berlioz (Mark Waggoner) writes: > > >Number 579 in the 1.4 wish series. > >I really want a 'toolpath' for workbench. I really hate it when >workbench can't find a project's tool just because the tool either >isn't installed in some specially named place or it is in a different >place on machine A than it is on machine B. One of the nice things >about the Mac is that it will find a tool for you if it is available >anywhere. > >What I propose: > 1. Workbench would first look for the tool using the name in the > default tool field of the project WITH DISK REQUESTERS TURNED OFF. > 2. If not found, Workbench searches for the tool in the 'toolpath' > (perhaps an environment variable? ) > 3. If still not found - and the default tool specifies an absolute > path, turn on the disk requesters and look for it again. > 4. If STILL not found - put up a REQUESTER to the effect: > 'Could not find the tool XXXX for project XXXX' > NOT a silly error message in the title bar. Maybe even > CENTER IT ON THE SCREEN! > Number 2017 of the 1.4 wish series (remember email): Neat idea. It would be great if we could have icons in directories, and have the program exist in some other directory. Then we could have the convenience of having a preferences icon in several drawers on a hard drive, but have only one preferences program on disk. Have it so you can also specify other volumes or devices where the program can exist. Then we could really run programs over a network or something. Something else that would be pretty gosh darn teriffic (and I'm not asking for much here guys) is to have directories with multiple enterances. I mean, you have 2 icons named utilities, in 2 diferent directories, that both take you into the same directory. It saves hunting through 3 or 4 windows all cluttered with icons just to find the path. It could also make for nice and short path names if you plan it right. A less than ideal but nearly there soluiton could be something like an assign. You assign utilities: to be sys:utilities, and then you can create an icon to open utilities: and it will look where it is. Now, that doesn't seem like much to ask for. And it is neat, eh Mr. Commodore developers?
usenet@cps3xx.UUCP (Usenet file owner) (08/28/89)
In article <16131@watdragon.waterloo.edu> rtczegledi@crocus.waterloo.edu (Richard Czegledi) writes: >In article <688@berlioz.nsc.com> waggoner@berlioz (Mark Waggoner) writes: > >Neat idea. It would be great if we could have icons in directories, and >have the program exist in some other directory. Then we could have the >convenience of having a preferences icon in several drawers on a hard drive, You can do this with 1.3 WB. Thats how the Prefs drawer works. It has 3 icons which point to the same executable. You could just move them elsewhere, all they would (if the you change the path from INFO) >Something else that would be pretty gosh darn teriffic (and I'm not asking >for much here guys) is to have directories with multiple enterances. I mean, >you have 2 icons named utilities, in 2 diferent directories, that both take This is known as 'links'. Hard or soft would do this. If I had to pick which kind of links to have, I would prefer soft (symbolic) links. They are generally more useful/flexible, but then they can't replace the functionality of hard links. Heres another wish list: NUMBER ONE! THIS should have been there since pre 1.0. When something fails in the workbench, I don't want to see Something failed, Error 217 In the title bar. What the h*ck is "Error ###"!!!!! Neat idea: Make PATH work for all "NAME:" things. Then if a program tries to open "tools:preferences", DOS would automagically look in places specified by the PATH command. I think that this could be transparent to existing stuff, and I doubt it would cause much trouble. It would make things MUCH nicer. There would of course need to be a way to extract the path that dos used to get at the file, but this needs to be done for the executable PATH anyways. One more little nit, when the computer get turnedon/restarted place the mouse in the *middle* of the display. Its a little thing, but its nicer and trivial to do. Same thing goes for "System Requests". Put 'em in the center of the display. They are much more vizible, and on average would be closer to the mouse. If multiple Requests come up, offset the later ones so they do not completely cover up existing ones. And PLEASE PLEASE PLEASE PLEASE PLEASE give more info in most of those requests. REAL NAME: Joe Porkka jap@frith.cl.msu.edu
charles@hpcvca.CV.HP.COM (Charles Brown) (08/29/89)
>> I really want a 'toolpath' for workbench. I really hate it when >> workbench can't find a project's tool just because the tool either >> isn't installed in some specially named place or it is in a different >> place on machine A than it is on machine B. ... > Neat idea. It would be great if we could have icons in directories, and > have the program exist in some other directory. Then we could have the > convenience of having a preferences icon in several drawers on a hard drive, > but have only one preferences program on disk. File system links gives you this and more. With links, the preferences program would actually exist in one place. The links would point to the real preferences. To the causal user, a link looks just like a regular file, or in this case, a regular program. It just doesn't take up nearly as much disk space as the real file. So giving us links would allow you this solution for the Workbench as well as for the CLI. > Something else that would be pretty gosh darn teriffic (and I'm not asking > for much here guys) is to have directories with multiple enterances. I mean, > you have 2 icons named utilities, in 2 diferent directories, that both take > you into the same directory. It saves hunting through 3 or 4 windows all > cluttered with icons just to find the path. It could also make for nice > and short path names if you plan it right. If links are provided for directories as well as files, this is also easy to do. Again, to the causal user, it looks like a regular directory. But in fact, you are in another directory. -- Charles Brown charles@cv.hp.com or charles%hpcvca@hplabs.hp.com or hplabs!hpcvca!charles or "Hey you!" Not representing my employer.
pl@etana.tut.fi (Lehtinen Pertti) (08/29/89)
From article <1410027@hpcvca.CV.HP.COM>, by charles@hpcvca.CV.HP.COM (Charles Brown): > > If links are provided for directories as well as files, this is also > easy to do. Again, to the causal user, it looks like a regular > directory. But in fact, you are in another directory. > There are also some pitfalls if you happen to build some nice little circular paths. Guess why Unix doesn't allow you make hard links to directories. -- pl@tut.fi ! All opinions expressed above are Pertti Lehtinen ! purely offending and in subject Tampere University of Technology ! to change without any further Software Systems Laboratory ! notice
charles@hpcvca.CV.HP.COM (Charles Brown) (08/31/89)
>> If links are provided for directories as well as files, this is also >> easy to do. Again, to the causal user, it looks like a regular >> directory. But in fact, you are in another directory. > There are also some pitfalls if you happen to build some > nice little circular paths. > Guess why Unix doesn't allow you make hard links to directories. >Pertti Lehtinen True but irrelevant. The probability of Amiga getting hard links is nil. And with soft links there is no problem. -- Charles Brown charles@cv.hp.com or charles%hpcvca@hplabs.hp.com or hplabs!hpcvca!charles or "Hey you!" Not representing my employer. "The guy sure looks like plant food to me." Little Shop of Horrors
peter@sugar.hackercorp.com (Peter da Silva) (08/31/89)
In article <8382@etana.tut.fi>, pl@etana.tut.fi (Lehtinen Pertti) writes: > Guess why Unix doesn't allow you make hard links to directories. But it does. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U` "before making up your mind, please read the book." -- sherry.mann "This is contrary to the spirit of rec.arts.sf-lovers" -- Jim Winer
rminnich@super.ORG (Ronald G Minnich) (09/01/89)
In article <4147@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <8382@etana.tut.fi>, pl@etana.tut.fi (Lehtinen Pertti) writes: >> Guess why Unix doesn't allow you make hard links to directories. >But it does. huh? The last version of Unix that allowed you to was long ago. I just tried it here on my sun and it won't let me. What kinda Unix you got out there, peter? Or do you know some good trick i don't know. Bypassing link(2) is not kosher as a good trick, btw. ron p.s. transcript follows: lois> ln bin binxx bin is a directory
fnf@estinc.UUCP (Fred Fish) (09/04/89)
In article <13757@super.ORG> rminnich@super.UUCP (Ronald G Minnich) writes: >In article <4147@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>In article <8382@etana.tut.fi>, pl@etana.tut.fi (Lehtinen Pertti) writes: >>> Guess why Unix doesn't allow you make hard links to directories. >>But it does. >huh? The last version of Unix that allowed you to was long ago. I just >tried it here on my sun and it won't let me. >What kinda Unix you got out there, peter? This is not exactly related to the Amiga but here goes anyway. This is on SCO Xenix 2.3.1, and should work on probably any Unix, including a Sun... Script started [typescript] at Sun Sep 3 20:41:31 1989 # cat junk.c main () { system ("mkdir junk"); link ("junk", "junk2"); } # cc junk.c # ./a.out # ls -lid junk* 1805 drwxr-xr-x 3 root root 32 Sep 3 20:41 junk 1998 -rw-r--r-- 1 root root 61 Sep 3 20:38 junk.c 1805 drwxr-xr-x 3 root root 32 Sep 3 20:41 junk2 (note inode numbers of 1805 show that junk and junk2 are links to the same directory) # date >junk/file # ls -li junk junk2 junk: total 2 1949 -rw-r--r-- 1 root root 29 Sep 3 20:42 file junk2: total 2 1949 -rw-r--r-- 1 root root 29 Sep 3 20:42 file # rm junk/* # ls junk # ls junk2 # rmdir junk junk2 # exit Script ended [typescript] at Sun Sep 3 20:42:31 1989 -- # Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA # 1-602-491-0048 asuvax!{nud,mcdphx}!estinc!fnf
ddave@pnet02.gryphon.com (David Donley) (09/05/89)
fnf@estinc.UUCP (Fred Fish) writes: >In article <13757@super.ORG> rminnich@super.UUCP (Ronald G Minnich) writes: >>In article <4147@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>>In article <8382@etana.tut.fi>, pl@etana.tut.fi (Lehtinen Pertti) writes: >>>> Guess why Unix doesn't allow you make hard links to directories. >>>But it does. >>huh? The last version of Unix that allowed you to was long ago. I just >>tried it here on my sun and it won't let me. >>What kinda Unix you got out there, peter? > >This is not exactly related to the Amiga but here goes anyway. This >is on SCO Xenix 2.3.1, and should work on probably any Unix, including >a Sun... > <Example of how to link a dir> ># Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA ># 1-602-491-0048 asuvax!{nud,mcdphx}!estinc!fnf On HP-UX systems you have to be superuser to link directories.
rminnich@super.ORG (Ronald G Minnich) (09/05/89)
In article <19465@gryphon.COM> ddave@pnet02.gryphon.com (David Donley) writes: >fnf@estinc.UUCP (Fred Fish) writes: >>This is not exactly related to the Amiga but here goes anyway. This >>is on SCO Xenix 2.3.1, and should work on probably any Unix, including >>a Sun... >On HP-UX systems you have to be superuser to link directories. Well, i know the manual says you can as root, my memory is that v6 kernel code and later forbode (forbade?) it, so you got me. My memory is clearly missing some bits. Anyway, on a sunos system, here is a transcript: super# ln bin binxxx bin is a directory super# note that i was running as root. HP-UX, depending on the machine, is not a real unix derivative (i.e. the 500 series). Boy, unix is really losing it fast as a standard ... Sorry for the digression from Unix too. But it should now be clear that we don't want hard links in Amigados???? Personally, i think hard links to directorys are Evil. Read the BSTJ on Unix (1978) for a comment on such things. ron
usenet@cps3xx.UUCP (Usenet file owner) (09/06/89)
In article <13842@super.ORG> rminnich@super.UUCP (Ronald G Minnich) writes: _>In article <19465@gryphon.COM> ddave@pnet02.gryphon.com (David Donley) writes: _>>fnf@estinc.UUCP (Fred Fish) writes: _[ interesting things deleted] _>Personally, i think hard links to directorys are Evil. _>Read the BSTJ on Unix (1978) for a comment on such things. Hmmm...Now if we put hard links into AmigaOS, and allowed them to work with directories then we would end up with a filesystem network as opposed to a filesystem tree :-) What is the "root" of a filesystem then? or a parent directory? I bet there are lots of neat trick you could play on programs that expect a simple filesystem tree, heh heh heh .... Backup programs in particular whould go crazy! On a more serious note, something I would like to see, and would effectivly add paths to anything are directory continues, as opposed to links. "continue sys:libs with someotherdisk:libs" Then when you "DIR SYS:LIBS", the extires in someotherdisk:libs would also appear. I would not want to be the one to write the error checking (loop detection) and other eveil things for this though :-) REAL NAME: Joe Porkka jap@frith.cl.msu.edu
ddave@pnet02.gryphon.com (David Donley) (09/06/89)
rminnich@super.ORG (Ronald G Minnich) writes: >In article <19465@gryphon.COM> ddave@pnet02.gryphon.com (David Donley) writes: >>fnf@estinc.UUCP (Fred Fish) writes: >>>This is not exactly related to the Amiga but here goes anyway. This >>>is on SCO Xenix 2.3.1, and should work on probably any Unix, including >>>a Sun... >>On HP-UX systems you have to be superuser to link directories. >note that i was running as root. HP-UX, depending on the machine, is >not a real unix derivative (i.e. the 500 series). >Personally, i think hard links to directorys are Evil. >ron I think hard links stink too- they are just a slow crummy way of doing alias... HOWEVER, some nice thing in workbench to let you cluster tools in an icon and such... (It's in there, right?) Well, I was talking about a 9000 series 800- I don't know about anything else... Never seen a "Real" AT&T unix box in my life... I've called a VAX, but that's not UN*X, that's slow. Anyhow, I didn't write this, as I'd never say anything about UN*X in an AMiga conference... :-)
shadow@pawl.rpi.edu (Deven T. Corzine) (09/06/89)
On 5 Sep 89 21:00:21 GMT, ddave@pnet02.gryphon.com (David Donley) said: ddave> I think hard links stink too- they are just a slow crummy way ddave> of doing alias... Excuse me? Hard links have other uses than to multiname executables. "alias" is shell-specific anyhow, and using a hard link is guaranteed to be faster. Hard links have their uses, but won't easily fit into AmigaDOS as it is. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
esker@abaa.uucp (Lawrence Esker) (09/06/89)
In article <4466@cps3xx.UUCP> porkka@frith.UUCP (Joe Porkka) writes: >On a more serious note, something I would like to see, and would >effectivly add paths to anything are directory continues, as >opposed to links. >"continue sys:libs with someotherdisk:libs" > >Then when you "DIR SYS:LIBS", the extires in someotherdisk:libs >would also appear. >REAL NAME: Joe Porkka jap@frith.cl.msu.edu There is a program (PD or Shareware?) that does something similar. It is called PathAsn for path assignment. It allows multiple directories (or files) to be assigned to the same name. When you do a dir in that name, all directories assigned to it are listed. Email me if you need it. I don't have much call to use it; don't remember who did it; got it from CompuServe. I'll send to Bob Page if enough interest. BTW. I don't see whats wrong with providing links to directories. If a person is too novice to comprehend the consequences, don't use it. But at least allow those who can the capability. -- ---------- Lawrence W. Esker ---------- Modern Amish: Thou shalt not need any computer that is not IBM compatible. UseNet Path: __!mailrus!sharkey!itivax!abaa!esker == esker@abaa.UUCP
ericb@athertn.Atherton.COM (Eric Black) (09/07/89)
Enough, already!
[for those who aren't aware of it, there is a difference between the
system call `link()', described in section 2 of the Unix Programmer's Manual,
and the `ln' command, described in section 1 of the manual.
The `ln' command "protects" users from themselves by not even calling the
`link()' system call if the target is a directory.
This is why Fred's example works, and why attempts to do it with `ln' don't.
Please stop the "Gee...it doesn't work on *my* Un*x box!" messages!
----
Eric Black "Garbage in, Gospel out"
Atherton Technology, 1333 Bordeaux Dr., Sunnyvale, CA, 94089
E-mail: ericb@Atherton.COM
UUCP: {decwrl,hpda,pyramid,coherent,sun}!athertn!ericb
Voice: +1 408 734 9822rminnich@super.ORG (Ronald G Minnich) (09/08/89)
In article <12350@mango.athertn.Atherton.COM> ericb@Atherton.COM (Eric Black) writes: >[for those who aren't aware of it, there is a difference between the >system call `link()', described in section 2 of the Unix Programmer's Manual, >and the `ln' command, described in section 1 of the manual. ah, yes, but i am allowed to say stupid things. It is right there in my job description. Geez, can't believe i got this so screwed up.... Guess i got to hand in my keys to the kernel. sorry. ron
ddave@pnet02.gryphon.com (David Donley) (09/08/89)
shadow@pawl.rpi.edu (Deven T. Corzine) writes: > >On 5 Sep 89 21:00:21 GMT, ddave@pnet02.gryphon.com (David Donley) said: > >ddave> I think hard links stink too- they are just a slow crummy way >ddave> of doing alias... > >Excuse me? Hard links have other uses than to multiname executables. >"alias" is shell-specific anyhow, and using a hard link is guaranteed >to be faster. Hard links have their uses, but won't easily fit into >AmigaDOS as it is. > >Deven >-- >Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu >Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 >Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven >Simple things should be simple and complex things should be possible. If hard links are faster than aliases, you will get a package with $1000 in it. C.O.D. :-)
shadow@pawl.rpi.edu (Deven T. Corzine) (09/09/89)
On 8 Sep 89 03:40:25 GMT, ddave@pnet02.gryphon.com (David Donley) said: ddave> If hard links are faster than aliases, you will get a package ddave> with $1000 in it. Your original statements and replies to followups are a convincing testimony that you don't understand the purposes of hard links, soft links, and the relation to aliases. (which is slim.) Aliases are a command substitution, links make multiple pathnames refer to the same file. The functions are completely different, performed at a different level, and have different, only somewhat overlapping, uses. For example, normally compress and uncompress are the same executable file, linked. But they are, as someone else mentioned, universal. Aliases are part of a user's environment. Moreover, using an alias for uncompress to point to compress would not WORK. When compress/uncompress runs, it checks it's executable name, and if it was done with an alias, the name would be "compress". If a link, "uncompress". See a difference? Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (---) --none-- Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
ddave@pnet02.gryphon.com (David Donley) (09/14/89)
shadow@pawl.rpi.edu (Deven T. Corzine) writes: > >On 8 Sep 89 03:40:25 GMT, ddave@pnet02.gryphon.com (David Donley) said: > >ddave> If hard links are faster than aliases, you will get a package >ddave> with $1000 in it. > >Your original statements and replies to followups are a convincing >testimony that you don't understand the purposes of hard links, soft >links, and the relation to aliases. (which is slim.) Aliases are a >command substitution, links make multiple pathnames refer to the same >file. The functions are completely different, performed at a >different level, and have different, only somewhat overlapping, uses. >For example, normally compress and uncompress are the same executable >file, linked. But they are, as someone else mentioned, universal. >Aliases are part of a user's environment. Moreover, using an alias >for uncompress to point to compress would not WORK. When >compress/uncompress runs, it checks it's executable name, and if it >was done with an alias, the name would be "compress". If a link, >"uncompress". See a difference? > >Deven >-- >Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu >Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (---) --none-- >Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven >Simple things should be simple and complex things should be possible. As I said before, I KNOW what aliases and soft links and hard links are. If you don't think I'm telling the truth, perhaps you arn't reading my messages. Further comments on this subject should be directed to private mail at ddave@pnet02.gryphon.com.
ddave@pnet02.gryphon.com (David Donley) (09/14/89)
shadow@pawl.rpi.edu (Deven T. Corzine) writes: > >On 8 Sep 89 03:40:25 GMT, ddave@pnet02.gryphon.com (David Donley) said: > >ddave> If hard links are faster than aliases, you will get a package >ddave> with $1000 in it. > >Your original statements and replies to followups are a convincing >testimony that you don't understand the purposes of hard links, soft >links, and the relation to aliases. (which is slim.) Aliases are a >command substitution, links make multiple pathnames refer to the same >file. The functions are completely different, performed at a >different level, and have different, only somewhat overlapping, uses. >For example, normally compress and uncompress are the same executable >file, linked. But they are, as someone else mentioned, universal. >Aliases are part of a user's environment. Moreover, using an alias >for uncompress to point to compress would not WORK. When >compress/uncompress runs, it checks it's executable name, and if it >was done with an alias, the name would be "compress". If a link, >"uncompress". See a difference? > >Deven >-- >Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu >Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (---) --none-- >Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven >Simple things should be simple and complex things should be possible. If I don't understand links, that's my problem not yours. You have a serious problem. When you don't understand somebody's ideas, you tell them things they already know. If you REALLY are trying to be informative, don't be nasty, or send mail. This is the .tech conference, not an neantherthal yell-out. ----- Mail to ddave@pnet02.gryphon.com
shadow@pawl.rpi.edu (Deven T. Corzine) (09/15/89)
On 14 Sep 89 04:40:28 GMT, ddave@pnet02.gryphon.com (David Donley) said: ddave> If I don't understand links, that's my problem not yours. You ddave> have a serious problem. When you don't understand somebody's ddave> ideas, you tell them things they already know. If you REALLY ddave> are trying to be informative, don't be nasty, or send mail. ddave> This is the .tech conference, not an neantherthal yell-out. Saying that hard links are useless because aliases are faster is simple misinformation. Not only is it untrue, but links and aliases serve different purposes. If you wish to be confused by this point, that is your business, but I contest redistribution of misinformation. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (---) --none-- Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.