dac@prolix.pub.uu.oz.au (Andrew Clayton) (02/12/91)
In article <1991Feb11.113601.1338@sugar.hackercorp.com>, Peter da Silva writes: > In article <18a97a8b.ARN2a78@prolix.ccadfa.cc.adfa.oz.au> dac@prolix.pub.uu.oz.au writes: > > In article <1991Feb9.045752.2018@sugar.hackercorp.com>, Peter da Silva writes: > > > In any case, adding a special bit for *each* separate command language is a > > > bad idea. I think the script bit is a mistake already. > > > Explain the last sentence in that statement, Peter, and make it a > > good explanation as well! Or Else. > > There's already an "execute" bit. A file with the execute bit set but not in > Amiga load format should be treated as a script. Having eight bits is kinda useful, Peter. The 'Script' bit is great. Whilst having the machine check to see if a file is a script, is plain dumb. There is no reason why a binary should start with any particular sequence of characters, right? Therefore, there is no reason why some unlucky binary file could start with the text '.key', and then the script interpreter would be called instead of the program loader - which would try to 'execute' a binary. Not clever at all. Adding the overhead of having to parse any executable to see if it's a script is not clever, and I agree with CBM's decision to make a script-bit. Messydos can get away with their strict filename regulations, to be able to have a script file automagically execute when called, but who wants to be limited to a brain dead filename limitation? > No reason to blow another > bit on the same thing. Too late *now*, of course, but why compound the mistake? There was a reason. There isn't when it comes to AREXX, if WB 2.0 already determines that the Script bit can mean Arexx or Execute Script. (Funnily enough, the S bit doesn't work on AREXX scripts under 1.3! :-) > Peter da Silva. `-_-' Dac -- _l _ _ // Andrew Clayton. Canberra, Australia. I Post . (_](_l(_ \X/ Send mail to dac@prolix.pub.uu.oz.au . . I am.
peter@sugar.hackercorp.com (Peter da Silva) (02/13/91)
In article <18ac1a05.ARN2ae4@prolix.pub.uu.oz.au> dac@prolix.pub.uu.oz.au writes: > > There's already an "execute" bit. A file with the execute bit set but not in > > Amiga load format should be treated as a script. > Having eight bits is kinda useful, Peter. UNIX has 16 and they've run out long ago. Sure it uses 9 instead of 4 on protection, but that leaves them an extra 3 bits... and they don't even have an archive bit! > The 'Script' bit is great. Whilst > having the machine check to see if a file is a script, is plain dumb. Why? > There is > no reason why a binary should start with any particular sequence of > characters, right? Sure there is. Observe: 1.System2.0:S> list dterm.init Directory "System2.0:S" on Tuesday 12-Feb-91 dterm.init 5421 ----rwed 25-Dec-90 09:07:26 1 file - 12 blocks used 1.System2.0:S> dterm.init dterm.init: file is not executable 1.System2.0:S> The exact same trick the UNIX shell does would serve: try to execute it as an executable, and if that fails it's a script: segList = LoadSeg(...); if(segList == INVALID) load_script(...); -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
rjc@geech.ai.mit.edu (Ray Cromwell) (02/13/91)
In article <1991Feb13.013917.22130@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <18ac1a05.ARN2ae4@prolix.pub.uu.oz.au> dac@prolix.pub.uu.oz.au writes: >> > There's already an "execute" bit. A file with the execute bit set but not in >> > Amiga load format should be treated as a script. > >> Having eight bits is kinda useful, Peter. > >UNIX has 16 and they've run out long ago. Sure it uses 9 instead of 4 on >protection, but that leaves them an extra 3 bits... and they don't even have >an archive bit! I can think of one reason for the script bit. A directly list. It's neat if I can type ls -F, and the listing will show which files are executable, links, directories, data, and script. I'm afriad open()ing or LoadSeg()ing every file in a tree will be quite slow. >Sure there is. Observe: > >1.System2.0:S> list dterm.init >Directory "System2.0:S" on Tuesday 12-Feb-91 >dterm.init 5421 ----rwed 25-Dec-90 09:07:26 >1 file - 12 blocks used >1.System2.0:S> dterm.init >dterm.init: file is not executable >1.System2.0:S> Hey, you use dterm? I think matt dillion stopped working on that a long time ago? My version is buggy! (GURUs often) >The exact same trick the UNIX shell does would serve: try to execute it as an >executable, and if that fails it's a script: > > segList = LoadSeg(...); > if(segList == INVALID) > load_script(...); if(not_a_script) WhatIsIt(); How do we tell the difference between Arexx scripts, shell scripts, CSH scripts, TCL scripts, etc? What we really need is a new hunk, or recognition sequence that defines that type the file is. (IFF, Text, arexx, ect) Simular to what Commodore did with $VER:. Why? I think it would be neat if the shell could help the user more like 'File is Text, not a script, want to read it? <execute more>' Either that, or provide .info files for text and script files. The shell could try to look at the tool (Amigabasic, execute, rx, TCL, Csh, WSH, etc) and execute the the appropriate interpreter that way. I agree that adding bits for every new script language is not the answer. I kind of like the .info scheme since it doesn't require any change to the OS, just the shell. One problem is people don't supply <>.info files for every file on the disk. Editors and Applications have to be smarter and start to save icon files out too. Now that Workbench is actually USUABLE, I hope more 2.0 programs do this. It's a pain to use Iconedit, or duplicate an icon everytime you want to use it from workbench. So what do you think? Should shells check the .info file of a file and look at the default tool so it knows which interpreter to use? >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>.
peterk@cbmger.UUCP (Peter Kittel GERMANY) (02/13/91)
In article <18ac1a05.ARN2ae4@prolix.pub.uu.oz.au> dac@prolix.pub.uu.oz.au writes: > [about the 'script bit'] > >Having eight bits is kinda useful, Peter. The 'Script' bit is great. Whilst >having the machine check to see if a file is a script, is plain dumb. There is >no reason why a binary should start with any particular sequence of >characters, right? There IS. Binaries on the Amiga come in "hunks" (at least the executable binaries, and I think we talk about them), and these hunks indeed start with some binary header that is never supposed to occur as the start of a plain text file. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
h112706@lehtori.tut.fi (Herranen Henrik) (02/13/91)
In article <18ac1a05.ARN2ae4@prolix.pub.uu.oz.au> dac@prolix.pub.uu.oz.au (Andrew Clayton) writes:
Having eight bits is kinda useful, Peter. The 'Script' bit is great. Whilst
having the machine check to see if a file is a script, is plain dumb. There is
no reason why a binary should start with any particular sequence of
characters, right? Therefore, there is no reason why some unlucky binary file
could start with the text '.key', and then the script interpreter would be
called instead of the program loader - which would try to 'execute' a binary.
Not clever at all.
From that comment I notice that you don't have the faintest idea of how
the executables are stored on disk. An executable file can NEVER begin
with the text .key. Executables are recognized by AmigaDOS by the fact
that the first 4 bytes (or was it 8) is always the same. So, really,
the script bit is unneeded. If a file is executable and does NOT start
with the standard executable longword, it could have been assumed that
the file is a script.
--
Henrik 'Leopold' Herranen Internet: h112706@cc.tut.fi
Snail Mail: TTKK/Paarakennuksen neuvonta/PL527/33101 Tampere/Finland
"I don't need no arms around me, I don't need no drugs to calm me" - PF 1979barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (02/14/91)
In article <18ac1a05.ARN2ae4@prolix.pub.uu.oz.au> dac@prolix.pub.uu.oz.au writes: >Having eight bits is kinda useful, Peter. The 'Script' bit is great. Whilst >having the machine check to see if a file is a script, is plain dumb. There is >no reason why a binary should start with any particular sequence of >characters, right? Are you aware that all Amiga executable files start with the same bytes? That's how the Amiga can tell it is indeed a program, and not just data. >Therefore, there is no reason why some unlucky binary file could start with >the text '.key', and then the script interpreter would be >called instead of the program loader - which would try to 'execute' a binary. >Not clever at all. UNIX does this. The interpreter just fails on the file, as if it had a syntax error. Not a problem, really. Of course, the file would have to have its execute bit (incorrectly) turned on in the first place. A person might just as easily set the script bit on a non-script file as set the execute bit on a non-executable. But you are right -- the method isn't perfect. But neither is having a different bit for each of 52 different interpreters (Shell, AREXX, AmigaBasic, csh, sksh, etc etc), or the inability to run scripts for "unsupported" interpreters. Dan //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ | Dan Barrett, Department of Computer Science Johns Hopkins University | | INTERNET: barrett@cs.jhu.edu | | | COMPUSERVE: >internet:barrett@cs.jhu.edu | UUCP: barrett@jhunix.UUCP | \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////
peter@sugar.hackercorp.com (Peter da Silva) (02/14/91)
In article <1991Feb13.053854.12419@mintaka.lcs.mit.edu> rjc@geech.ai.mit.edu (Ray Cromwell) writes: > It's neat if I can type ls -F, and the listing will show which files > are executable, links, directories, data, and script. I'm afriad open()ing or > LoadSeg()ing every file in a tree will be quite slow. True, but you could see which ones are "executable or script". And, really, you probably don't care which is which. That's the whole point of the script bit, after all... > Hey, you use dterm? I think matt dillion stopped working on that a > long time ago? My version is buggy! (GURUs often) Yep, I use Dterm. It's still the best plain-jane terminal program (no fancy emulations... just a solid window on the WB). I have V 1.11 and it doesn't GURU on me... Wish I could talk Matt into supporting DTERM again. It's a good program. > How do we tell the difference between Arexx scripts, shell scripts, > CSH scripts, TCL scripts, etc? That's a Small Matter of Programming in "load_script()". Personally, I like the idea of using the Filenote for this (that'd satisfy your "ls" needs)... Actually, do this: fp = fopen(filename, "r"); fgets(firstline, sizeof firstline, fp); fclose(fp); hashbang = strstr(firstline, "#!"); if(!hashbang) shell_script(filename); else { sprintf(cmd, "%s %s", hashbang+2, filename); System(cmd, ...); } You could also have the #! string in the filenote (check that first, for speed). > I kind of like the .info scheme Also a good idea... -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
dac@prolix.pub.uu.oz.au (Andrew Clayton) (02/14/91)
In article <H112706.91Feb13112820@lehtori.tut.fi>, Herranen Henrik writes: > > In article <18ac1a05.ARN2ae4@prolix.pub.uu.oz.au> dac@prolix.pub.uu.oz.au (Andrew Clayton) writes: > > There is > no reason why a binary should start with any particular sequence of > characters, right? > From that comment I notice that you don't have the faintest idea of how > the executables are stored on disk. An executable file can NEVER begin > with the text .key. Executables are recognized by AmigaDOS by the fact > that the first 4 bytes (or was it 8) is always the same. So, really, > the script bit is unneeded. I sit/stand corrected. Thanks heaps. :-(. > Henrik 'Leopold' Herranen Internet: h112706@cc.tut.fi Dac -- Ob. defense, I did put a '?' after my assumption. 1/2:-) _l _ _ // Andrew Clayton. Canberra, Australia. I Post . (_](_l(_ \X/ Send mail to dac@prolix.pub.uu.oz.au . . I am.
dac@prolix.pub.uu.oz.au (Andrew Clayton) (02/14/91)
In article <1991Feb13.013917.22130@sugar.hackercorp.com>, Peter da Silva writes: > In article <18ac1a05.ARN2ae4@prolix.pub.uu.oz.au> dac@prolix.pub.uu.oz.au writes: > > > There's already an "execute" bit. A file with the execute bit set but not in > > > Amiga load format should be treated as a script. > > > Having eight bits is kinda useful, Peter. > > UNIX has 16 and they've run out long ago. Sure it uses 9 instead of 4 on > protection, but that leaves them an extra 3 bits... and they don't even have > an archive bit! Having already been toasted, I'll bow out, singed, shaken, but not totally dejected. *I* am not the proud owner of a 'V8 mind'. :-) > Peter da Silva. `-_-' Dac --
peter@sugar.hackercorp.com (Peter da Silva) (02/15/91)
In article <11221.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > Count up how many accesses are required on the file to determine > whether it's a script, using either method. One. Remember, in FFS the first block of the file tends to be contiguous with the header, and for a floppy (the only place this makes a difference) the whole track gets loaded in a unit so the first block is right there. With OFS you'd have a single extra access, but since you presumably need to load the script in to memory to run it that access would be made in any case, whether it's a script or not. All you're doing is preloading the disk's buffer pool. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
jbickers@templar.actrix.gen.nz (John Bickers) (02/15/91)
Quoted from <1991Feb13.013917.22130@sugar.hackercorp.com> by peter@sugar.hackercorp.com (Peter da Silva): > In article <18ac1a05.ARN2ae4@prolix.pub.uu.oz.au> dac@prolix.pub.uu.oz.au writes: > > having the machine check to see if a file is a script, is plain dumb. > > Why? Count up how many accesses are required on the file to determine whether it's a script, using either method. In the worst case, running a script frequently as part of another script on a floppy, you'd want something a bit more efficient than "if LoadSeg fails LoadScript". > <peter@sugar.hackercorp.com>. -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (02/15/91)
Quoted from <1991Feb13.053854.12419@mintaka.lcs.mit.edu> by rjc@geech.ai.mit.edu (Ray Cromwell): > In article <1991Feb13.013917.22130@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > > segList = LoadSeg(...); > > if(segList == INVALID) > > load_script(...); > if(not_a_script) WhatIsIt(); > How do we tell the difference between Arexx scripts, shell scripts, > CSH scripts, TCL scripts, etc? Let the shell figure it out, like WShell does. The OS should only really have one script language (if that), though the reality is that the 1st one proved insufficient, and now we have a 2nd, it's too late to throw away the 1st. > did with $VER:. Why? I think it would be neat if the shell could help the > user more like 'File is Text, not a script, want to read it? <execute more>' Programs do exist that do this job, to some extent. Programs have the hunk format, IFF files have the various IFF headers, ARexx scripts have /*, AmigaDOS scripts have the script bit. It isn't that hard to type two characters before a filename to do something with it, though (and in terms of file completion it's faster to scan an argument word than it is a command word, eg: on my machine "lh<Esc>" expands to "lharc" much slower than "m x<Esc>" expands to "m xmas.pic"). So a simple "whatis" sort of program could be a practical solution to any filetype problems. Some problems with scanning .info files are: x Some of us use shells to avoid a proliferation of .infos. x Current software could require messing with arguments. -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
dac@prolix.pub.uu.oz.au (Andrew Clayton) (02/16/91)
In article <7564@jhunix.HCF.JHU.EDU>, Dan Barrett writes: [and joins the throngs pointing out my glaring error. Oh the pain] > But you are right -- the method isn't perfect. But neither is > having a different bit for each of 52 different interpreters (Shell, > AREXX, AmigaBasic, csh, sksh, etc etc), or the inability to run scripts > for "unsupported" interpreters. Well, no, having a *different* bit for each script interpreter is plainly ridiculous. I saw Peter make, what appeared to me, to be a wild accusation. My execution of my reply could have been, ah, cleverer. :-/ If a file has the SCRIPT bit set, then Amigados should know how to cope with it, if it is a dos script, or an Arexx script. There isn't any need for an 'Arexx' script, which is was the nice gentleman from C= said in the first place. > | Dan Barrett, Department of Computer Science Johns Hopkins University | Dac -- _l _ _ // Andrew Clayton. Canberra, Australia. I Post . (_](_l(_ \X/ Send mail to dac@prolix.pub.uu.oz.au . . I am.
bartonr@eecs.cs.pdx.edu (None Of The Above) (02/17/91)
In article <1991Feb13.013917.22130@sugar.hackercorp.com>, Peter da Silva writes: > UNIX has 16 and they've run out long ago. Sure it uses 9 instead of 4 on > protection, but that leaves them an extra 3 bits... and they don't even have > an archive bit! AmigaDOS has 32 bits available, so I don't think we're in danger of running out anytime soon. ================================================================================
david@twg.com (David S. Herron) (02/19/91)
In article <18ac1a05.ARN2ae4@prolix.pub.uu.oz.au> dac@prolix.pub.uu.oz.au writes: >In article <1991Feb11.113601.1338@sugar.hackercorp.com>, Peter da Silva writes: > >> > In article <1991Feb9.045752.2018@sugar.hackercorp.com>, Peter da Silva writes: >> > > In any case, adding a special bit for *each* separate command language is a >> > > bad idea. I think the script bit is a mistake already. ... >> There's already an "execute" bit. A file with the execute bit set but not in >> Amiga load format should be treated as a script. > >Having eight bits is kinda useful, Peter. The 'Script' bit is great. Whilst >having the machine check to see if a file is a script, is plain dumb. There is >no reason why a binary should start with any particular sequence of >characters, right? Therefore, there is no reason why some unlucky binary file >could start with the text '.key', and then the script interpreter would be >called instead of the program loader - which would try to 'execute' a binary. >Not clever at all. > >Adding the overhead of having to parse any executable to see if it's a script >is not clever, and I agree with CBM's decision to make a script-bit. Oops.. just realized my post earlier was incomplete. There is very little "parsing" to do to recognize what kind of executable you have there. At least on Unix what is done is make the first 2 (4?) bytes be a "magic number". For an executable script the magic number is "#!" and for normal object files the magic number is something that cannot appear in normal text. Hmm.. this assumption will likely break soon since Unix is being internationalized, part of which is support for 8-bit text. Sigh.. Yeah, sure, I'm being inflamatory by saying "Unix does this already" .. but, really, the capabilities are there and would be a useful addition to AmigaDOS. For instance Unix has different sorts of "object files" with different capabilities -- simply by using different Magic Numbers. Using a Unix-y magic number scheme the "pure" bit in the protection is not necessary, it would just be a different magic number. After all, what does the purity of the program have to do with file protections? Methinks it was just a handy place to stuff a bit without having to change too many things. (quick hack) If you wanna do a one-up-manship with Unix then I suggest putting the Magic Number some other place besides the beginning of the file. David -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- MS-DOS ... The ultimate computer virus.
davewt@NCoast.ORG (David Wright) (02/19/91)
In article <1991Feb13.210019.3896@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >That's a Small Matter of Programming in "load_script()". Personally, I like >the idea of using the Filenote for this (that'd satisfy your "ls" needs)... >You could also have the #! string in the filenote (check that first, for >speed). I can tell you that I would refuse to use any program that put/changed anything in the filenotes field, and I don't think I am alone. I use the filenotes for my own use, primarily to indicate versions and brief descriptions of what the program does (so you don't have to dig through a ton of files in your DOCS: direcory to find out what some obscure utility does), which is what they were intended for. I will resist to the DEATH anything that tries to steal them from me for a much uglier and IMHO kludgier use. Filenotes are one of the things that truely sets the Amiga OS apart from other systems, by allowing the USER to store USER DECIDED info with each file. About the only thing I would accept for this is the use of filenotes on directories to indicate the users and security level needed to access the files in the directory, as is done in some Amiga multi-user software. >> I kind of like the .info scheme >Also a good idea... This I agree on. Since icons are supposed to be "black box" objects anyway, if there was a system call that stuck in/retrieved something else from the icon, that would seem the best method. Dave
GHGAQZ4@cc1.kuleuven.ac.be (02/20/91)
>Oops.. just realized my post earlier was incomplete. > >There is very little "parsing" to do to recognize what kind of >executable you have there. At least on Unix what is done is make >the first 2 (4?) bytes be a "magic number". For an executable >script the magic number is "#!" and for normal object files the >magic number is something that cannot appear in normal text. Hmm.. >this assumption will likely break soon since Unix is being >internationalized, part of which is support for 8-bit text. Sigh.. > >Yeah, sure, I'm being inflamatory by saying "Unix does this already" >.. but, really, the capabilities are there and would be a useful >addition to AmigaDOS. > >For instance Unix has different sorts of "object files" with >different capabilities -- simply by using different Magic Numbers. >Using a Unix-y magic number scheme the "pure" bit in the protection >is not necessary, it would just be a different magic number. After >all, what does the purity of the program have to do with file >protections? Methinks it was just a handy place to stuff a bit >without having to change too many things. (quick hack) > >If you wanna do a one-up-manship with Unix then I suggest putting >the Magic Number some other place besides the beginning of the file. > > > David You obviously don't know the Amiga well. Amiga executables are very well recognizable by the first 4 bytes of the file. These 4 bytes are always equal to 0x000003F8 (or something like that). This is a highly unlikely longword for ascii files. I think I'd rather have a pure bit than another keyword in the file to indicate it is pure. With the pure bit you do not have to open the file to see if it is pure. A simple Lock will suffice. Opening a file has much more overhead than locking the file. Having a pure bit means that you can include this bit in the directory listing. If there was a Magic Number IN the file, the directory utility would have to open the file, read some bytes from it and close the file again, and this for EACH file in the directory. Jorrit Tyberghein
peter@sugar.hackercorp.com (Peter da Silva) (02/20/91)
In article <1991Feb19.015136.696@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: > In article <1991Feb13.210019.3896@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >That's a Small Matter of Programming in "load_script()". Personally, I like > >the idea of using the Filenote for this (that'd satisfy your "ls" needs)... > >You could also have the #! string in the filenote (check that first, for > >speed). > I can tell you that I would refuse to use any program that put/changed > anything in the filenotes field, and I don't think I am alone. That's why I said "also". You could continue to use the filenotes if you left the #! out. If there was no #! (or whatever the magic string was) in the note then it'd look in the file. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
gblock@csd4.csd.uwm.edu (Gregory R Block) (02/20/91)
From article <1991Feb20.013503.15087@sugar.hackercorp.com>, by peter@sugar.hackercorp.com (Peter da Silva): > > That's why I said "also". You could continue to use the filenotes if you left > the #! out. If there was no #! (or whatever the magic string was) in the note > then it'd look in the file. > -- > Peter da Silva. `-_-' > <peter@sugar.hackercorp.com>. I think not. I tend to use that, believe it or not. Sorry, find another. This in itself is a dead end... what happens when _I_ use it??? :) No, it's a little too restrictive for me, thank you. I like what we have. No, it's not unix. If I wanted unix, I'd run it. But I like how it's done now. L8r -- ------------------------------------------------------------------------------ gblock@csd4.csd.uwm.edu | Amigas, Amigas everywhere, but not a one can think. ----Gregory R Block---- | Where's an AI when you need one? ________________________| A Mac, by any other name, would smell like a lawsuit.
bartonr@eecs.cs.pdx.edu (RTFM) (02/21/91)
In article <1991Feb19.015136.696@NCoast.ORG> (David Wright) writes: > I can tell you that I would refuse to use any program that put/changed > anything in the filenotes field, and I don't think I am alone. No, you're certainly not alone. Just as some things are reserved for the system, the comment field is left for the user to play with as he sees fit. Besides, there are still unused, reserved fields in the header block that could be used for this purpose instead of using the comment. ================================================================================
peter@sugar.hackercorp.com (Peter da Silva) (02/23/91)
In article <9653@uwm.edu> gblock@csd4.csd.uwm.edu writes: > From article <1991Feb20.013503.15087@sugar.hackercorp.com>, by peter@sugar.hackercorp.com (Peter da Silva): > > That's why I said "also". You could continue to use the filenotes > > if you left the #! out. If there was no #! (or whatever the magic > > string was) in the note then it'd look in the file. > I think not. I tend to use that, believe it or not. Sorry, find another. [etc] Rhetorical question: did you read what I wrote? (rhetorical, because the answer is obviously "no") -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.