dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/24/87)
How about another archive bit: "Do not bother to archive this file because it can easily be regenerated" So disk backup programs can easily tell which files do *not* need to be backed up. Application programs or the user can then set/clear the bit as he wishes. As far as execution goes, why not adopt the UNIX standard: #!C:EXECUTE (as the first line in file) So one can make 'standard' script files which use other interpreters rather than EXECUTE (such as SHELL). -Matt
page@ulowell.cs.ulowell.edu (Bob Page) (12/24/87)
Nice idea (the NOBACKUP bit); I use it a lot on other machines, especially with the networked systems. I'd like FOUR more bits allocated in that protection word: Read, Write, Execute and Delete for a Network user, as opposed to the existing bits for a 'local' user. Also on protection bits, why is the Delete bit needed? The Write bit implies you can zero the file, and Write on the directory implies you can create/delete/write files there. So having Write on the file is about the same as being able to delete it. Lastly, when will AmigaDOS look at those bits? Currently I can read anything, execute anything, etc, regardless of the bit settings. ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.edu ulowell!page "I've never liked reality all that much, but I haven't found a better solution." --Dave Haynie, Commodore-Amiga
cmcmanis%pepper@Sun.COM (Chuck McManis) (12/25/87)
In article <8712240640.AA24010@cory.Berkeley.EDU> (Matt Dillon) writes: > How about another archive bit: > > "Do not bother to archive this file because it can easily > be regenerated" My backup program does this by having a command "Mark as Archived." So that commands that are not rewritten can be set initially to 'archived' so that they won't be backed up, and the selection criteria allows you to exclude directories from the backup set so you can selectively not backup /t or whatever. > As far as execution goes, why not adopt the UNIX standard: > >#!C:EXECUTE (as the first line in file) But Matt even on UNIX the shell does this, not the O/S. You could use the same technique that csh uses, check the file to see if it is a binary file (read the first 'hunk header') and look for non ascii characters. If binary run it as is, if it is text then check the first line for a processor name and prepend that to the arglist and then try to run it again (now executing the shell). A binary/text bit would be nice to speed this up. (This would also make TYPE default to HEX mode.) > So one can make 'standard' script files which use other >interpreters rather than EXECUTE (such as SHELL). Another option might be a 'Batch' bit in the protection word that says this is a batch file. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
grr@cbmvax.UUCP (George Robbins) (12/25/87)
In article <37368@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: > > > As far as execution goes, why not adopt the UNIX standard: > > > >#!C:EXECUTE (as the first line in file) > > But Matt even on UNIX the shell does this, not the O/S. You could use the > same technique that csh uses, check the file to see if it is a binary > file (read the first 'hunk header') and look for non ascii characters. Uh, on Berkeley unix, this *is* handled by the OS. Yet another kludge, but it's useful and works pretty well as long as you don't make naive assumptions about argument passing... -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
david@ms.uky.edu (David Herron -- Resident E-mail Hack) (12/25/87)
In article <37368@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <8712240640.AA24010@cory.Berkeley.EDU> (Matt Dillon) writes: >> As far as execution goes, why not adopt the UNIX standard: >> >>#!C:EXECUTE (as the first line in file) > >But Matt even on UNIX the shell does this, not the O/S. You could use the >same technique that csh uses, check the file to see if it is a binary >file (read the first 'hunk header') and look for non ascii characters. >If binary run it as is, if it is text then check the first line for a >processor name and prepend that to the arglist and then try to run it >again (now executing the shell). A binary/text bit would be nice to >speed this up. (This would also make TYPE default to HEX mode.) er... I suggest you look again. BSD (from 4.2 on) does what Matt suggested. That is ... when exec()'s happens on a script file, the KERNAL reads the first couple of bytes to get the magic number. If the magic number is "#!" then it does the script file processing which includes: 1) read the rest of the line 2) get the first "word" and use that as the file to really exec(). 3) use the rest of the line as the first argument to the program in 2. 4) arrange for the script file to be on the standard input of the exec'd process 5) exec the program named in 2. I forget exactly where this is in the kernal, but it IS in the kernal because I saw it there once :-). -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- <---- Winter health warning: Remember, don't eat the yellow snow!
ewhac@well.UUCP (Leo L. Schwab) (12/25/87)
[ "Oh Mr. Belpert, your legs are so swollen." ]
Well, since everyone wants to add protection bits to the DOS, why
don't we go the whole nine yards?
d: Delete protect (file cannot be deleted)
w: Write protect
r: Read protect
i: Information protect (file will not appear in directory scans
unless a special flag is provided)
n: Name protect (file cannot be renamed)
s: Size protect (file size cannot be changed)
p: Protection bit protect (protection bits cannot be changed)
b: Backup protect (don't bother backing up this file)
Wow! Eight bits exactly!
Believe it or not, except for the 'b', there was an OS that actually
had all these protection bits. It was called PTDOS, for the SOL-20 and
Helios 8" drive. After looking through the PTDOS manual, it struck me that
it would make an ideal BBS operating system: Arcane, and files could be
hyper-protected if you wanted (making it a pain to hack).
My favorite feature was the KILL command, for deleting files. When
you ran the KILL command, it would not only remove the file from the
directory, but write garbage into all the sectors it occupied. When you
KILLed a file, it was *GONE!* Must have been a big winner with the DoD...
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\
\_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac
O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack")
"Although there are technical differences between the quality of images
created on the Amiga and on our system, we feel that viewers could be misled
to believe otherwise, even with your disclaimers to the contrary."
-- Ralph J. Guggenheim, Pixarphil@titan.rice.edu (William LeFebvre) (01/09/88)
In article <37368@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <8712240640.AA24010@cory.Berkeley.EDU> (Matt Dillon) writes: >> As far as execution goes, why not adopt the UNIX standard: >> >>#!C:EXECUTE (as the first line in file) > >But Matt even on UNIX the shell does this, not the O/S. You could use the >same technique that csh uses, check the file to see if it is a binary >file (read the first 'hunk header') and look for non ascii characters. >If binary run it as is, if it is text then check the first line for a >processor name and prepend that to the arglist and then try to run it >again (now executing the shell). A binary/text bit would be nice to >speed this up. (This would also make TYPE default to HEX mode.) Let's set the record straight on this.....the Unix kernel call "exec" DOES check the first two byts of a file to see if they are "#!" and if so, execs the name that follows (while doing some underhanded magic to the arguments). The shell does NOT explicitly check a file to see if it is binary. It first calls some flavor of "exec" with the command name. If the call returns ENOEXEC (not an executable file), then (and only then) it tries to run the file as a shell file. If the first "exec" fails for some reason other than ENOEXEC, the error message is (in most cases) printed on the user's terminal. As far as doing a "#!" equivalent under AmigaOS, at the very least, it would have to be ";!". The letter "#" was not chosen at random---it is the shell's comment character. Since the entire file is handed to the requested executable, this first line must somehow be ignored by that executable. In the case of Unix, this automatically happens because it looks like a comment. Unfortunately for the Amiga, this means that more programs would need to agree on a comment character or some other scheme would have to be employed to insure that the first line was not acted upon by the invoked program. William LeFebvre Department of Computer Science Rice University <phil@Rice.edu>