cs163wcr@sdcc10.ucsd.edu (I support the U.N.) (01/26/91)
I have been hacking at these questions for a while, using various reference books, with no real progress. Could someone please tell me: [1] Can you access a file by its i-node number? Something like (for C code) FILE *iopen (int inode, char *mode) ? [2] With Internet sockets, how does a machine accept()ing a socket connection know what machine is calling it? Does it rely on the calling program to tell it? [3] I have a server program that reads my mail and does various functions. One thing I would like it to do is send a "write" message to other users when it gets a letter with subject "WRITE user", sending the letter body as the message, but I can't get write to work unless the output is a tty. How do I fool write into thinking my pipe is a tty? I'm on 4.3 BSD Tahoe & the Internet, if that helps. And here's a parting question: [4] How did you become a Unix Wizard? I'm learning various features as I go, as I think of a use for them and/or learn about them. Is there a more organized/better way? Steve Boswell whatis@ucsd.edu
rickert@mp.cs.niu.edu (Neil Rickert) (01/26/91)
In article <16048@sdcc6.ucsd.edu> cs163wcr@sdcc10.ucsd.edu (I support the U.N.) writes: >[1] Can you access a file by its i-node number? Something like > (for C code) FILE *iopen (int inode, char *mode) ? I hope not. Otherwise permissions on directories wouldn't do much. I do think the system design would have been cleaner if you only accessed by i-node number, and mapping filename to inode was done outside the kernel. But I doubt that I have many supporters in this "keep the kernel small" view. >[2] With Internet sockets, how does a machine accept()ing a > socket connection know what machine is calling it? Does > it rely on the calling program to tell it? getpeername() should get you the internet address and port number of the calling machine, and then gethostbyaddr() will attempt to map the Internet address into a domain name. There are added complexities due to the byte order on the network being possibly different from that of your machine, but there are standard library routines such as ntohl(3) to take care of this problem too. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
rbj@uunet.UU.NET (Root Boy Jim) (01/27/91)
>In article <16048@sdcc6.ucsd.edu> cs163wcr@sdcc10.ucsd.edu (I support the U.N.) writes: I support the I.X. > [4] How did you become a Unix Wizard? I sent $49.95 to the Famous Wizards School :-) My advice to wannabes is to RTFM. All of it. Several times. The secret is knowing which parts to skip. The answer is: everything you find confusing. Just remember that it exists. The next time thru you'll understand more. Forget 90% of the books out there. They're trying to beat around the bush for people who like to be led by the hand. Talk to and emulate those that you consider to be more wizardly. Ask questions if you get stuck. Don't worry if they are stupid ones. We like them, they're easier to answer. We asked them too. Read source code. Unfortunately, less system source is available, altho more public domain source is. Another advantage is history. Those of you who have never seen Version 6 or 7, or anything else other than UNIX, who have never programmed extensibly in assembly will find it harder to view the present in perspective. On the other hand, we all view it differently and some of it was a waste of time. Learn LISP. Learn why I said this. -- Root Boy Jim Cottrell <rbj@uunet.uu.net> Close the gap of the dark year in between
jet@karazm.math.uh.edu ("J. Eric Townsend") (01/28/91)
In article <19001@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >might be wrong, who knows, I've actually learned to appreciate >VM/HPO in my old age. I'm considering proposing a REXX news >group if my REXX skills get any better ;-) ] comp.lang.rexx already exists, thanks in part to the large number of Amiga programmers who use it extensively... -- J. Eric Townsend - jet@uh.edu - bitnet: jet@UHOU - vox: (713) 749-2120 "It is the cunning of form to veil itself continually in the evidence of content. It is the cunning of the code to veil itself and to produce itself in the obviousness of value." -- Baudrillard
lm@slovax.Eng.Sun.COM (Larry McVoy) (01/28/91)
In article <16048@sdcc6.ucsd.edu> cs163wcr@sdcc10.ucsd.edu (I support the U.N.) writes: >[1] Can you access a file by its i-node number? Something like > (for C code) FILE *iopen (int inode, char *mode) ? Program included below. This program does an internal file tree walk to find the inode. Slow, but quite portable, contrary to a supposed wizard's opinion. >[2] With Internet sockets, how does a machine accept()ing a > socket connection know what machine is calling it? Does > it rely on the calling program to tell it? Go look at ethernet packets. They have both a sender and a destination. The sender field, after going through a few protocol layers, gets jammed into one of the accept(2) args. >[3] I have a server program that reads my mail and does various > functions. One thing I would like it to do is send a "write" > message to other users when it gets a letter with subject > "WRITE user", sending the letter body as the message, but I > can't get write to work unless the output is a tty. How do > I fool write into thinking my pipe is a tty? Oh, I suspect a little perl script will do it. That's included below as well. Yes, I was bored this evening. :-) >[4] How did you become a Unix Wizard? I'm learning various > features as I go, as I think of a use for them and/or > learn about them. Is there a more organized/better way? Use the force, read the source. # This is a shell archive. Remove anything before this line, then # unpack it by saving it in a file and typing "sh file". (Files # unpacked will be owned by you and have default permissions.) # # This archive contains: # iopen.c wruser echo x - iopen.c cat > "iopen.c" << '//E*O*F iopen.c//' #include <ftw.h> #include <sys/stat.h> static int _inum; /* XXX - won't work when multi threaded */ /* could be a function */ #ifdef MAIN static char *_path; /* just so we can print it out */ #endif iopen(mnt, inum) char *mnt; { char *mine(); char *path; int fd; _inum = inum; path = (char*)ftw(mnt, mine, 32); /* XXX - 32 */ if (path == (char*)0) return (-1); if ((fd = open(path, 2)) == -1) fd = open(path, 0); #ifdef MAIN _path = path; #endif return (fd); } static char* mine(p, sp, flags) char *p; struct stat *sp; { if (sp->st_ino == _inum) { return (p); } return (0); } #ifdef MAIN main(ac, av) char **av; { int fd; if (ac != 3) { printf("usage: %s mntpoint inum\n", av[0]); exit(1); } fd = iopen(av[1], atoi(av[2])); if (fd == -1) { printf("%s: can't find ino %d\n", atoi(av[2])); exit(2); } printf("open of %s, ino %d, returns %d\n", _path, atoi(av[2]), fd); } #endif //E*O*F iopen.c// echo x - wruser cat > "wruser" << '//E*O*F wruser//' #!/bin/perl # stolen from vacation.pl @lines = <>; # schlep 'em in foreach $_ (@lines) { last if /^\n/; next unless /^Subject: WRITE /; $buf = $_; $buf =~ s/Subject: WRITE //; split(/[ \t\n]+/, $buf); foreach $u (@_) { $user{$u} = 1; } $found++; last; } if (!defined $found) { # # Do whatever you would normally do in the case that # this is normal mail. # I just copy it to stdout. foreach $_ (@lines) { print; } exit 0; } # # OK, let's find the user[s] we want. # open(WHO, "/usr/bin/who|") || die "No who?"; while (<WHO>) { split; if ($user{$_[0]} == 1) { open(W, "|/bin/write $_[0] $_[1]") || die "write $_[0] $_[1]"; foreach $_ (@lines) { print W; } close(W); } } close(WHO); exit 0; //E*O*F wruser// echo Possible errors detected by \'wc\' [hopefully none]: temp=/tmp/shar$$ trap "rm -f $temp; exit" 0 1 2 3 15 cat > $temp <<\!!! 57 159 925 iopen.c 45 130 727 wruser 102 289 1652 total !!! wc iopen.c wruser | sed 's=[^ ]*/==' | diff -b $temp - exit 0 --- Larry McVoy, Sun Microsystems (415) 336-7627 ...!sun!lm or lm@sun.com
lucio@proxima.UUCP (Lucio de Re) (01/29/91)
[ follow-ups directed to alt.flame ] In article <1991Jan26.142403.22812@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <16048@sdcc6.ucsd.edu> cs163wcr@sdcc10.ucsd.edu (I support the U.N.) writes: >>[1] Can you access a file by its i-node number? Something like >> (for C code) FILE *iopen (int inode, char *mode) ? > > I hope not. Otherwise permissions on directories wouldn't do much. I >do think the system design would have been cleaner if you only accessed >by i-node number, and mapping filename to inode was done outside the kernel. >But I doubt that I have many supporters in this "keep the kernel small" view. Hmmm, how about 10000 comp.os.minix readers? > >-- >=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= > Neil W. Rickert, Computer Science <rickert@cs.niu.edu> > Northern Illinois Univ. > DeKalb, IL 60115 +1-815-753-6940 -- Lucio de Re. Internet: lucio%proxima@ddsw1.mcs.com usenet: ...!uunet!ddsw1!proxima!lucio
ronald@robobar.co.uk (Ronald S H Khoo) (01/29/91)
rbj@uunet.UU.NET (Root Boy Jim) writes: > My advice to wannabes is to ... [ much good advice deleted ] > Ask questions if you get stuck. Don't worry if they are stupid > ones. We like them, they're easier to answer. We asked them too. But, may I add, probably ask them in the appropriate newsgroup. Not unix.wizards... Try unix.questions, to which followups are redirected. [ more good advice deleted ] Just another non-wizard news admin, in wishing for a more wizardly comp.unix.wizards, breaking his normal rule of not posting here.... (and for which, apologies to all....) -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
mike@vlsivie.tuwien.ac.at (Michael K. Gschwind) (01/29/91)
In article <1991Jan26.142403.22812@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <16048@sdcc6.ucsd.edu> cs163wcr@sdcc10.ucsd.edu (I support the U.N.) writes: >>[1] Can you access a file by its i-node number? Something like >> (for C code) FILE *iopen (int inode, char *mode) ? > > I hope not. Otherwise permissions on directories wouldn't do much. I >do think the system design would have been cleaner if you only accessed >by i-node number, and mapping filename to inode was done outside the kernel. This is what is done on Apollo's DomainOS UNIX-clone. It is however a security nightmare. Things like chroot don't work, so you can't support anonymous ftp et al. Neat idea, but isn't fully UNIX compatible. >But I doubt that I have many supporters in this "keep the kernel small" view. I guess there are _lots_ of supporters of this view. The only problem is that you must strive to keep the security stuff (e.g., filename translation) INSIDE the kernel, or else you must find a way to write trusted servers, libraries etc. bye, mike Michael K. Gschwind, Institute for VLSI-Design, Vienna University of Technology mike@vlsivie.tuwien.ac.at 1-2-3-4 kick the lawsuits out the door mike@vlsivie.uucp 5-6-7-8 innovate don't litigate e182202@awituw01.bitnet 9-A-B-C interfaces should be free Voice: (++43).1.58801 8144 D-E-F-O look and feel has got to go! Fax: (++43).1.569697
gertjan@west.nl (Gertjan van Oosten) (01/29/91)
jfh@rpp386.cactus.org (John F Haugh II) writes: > "Operating Systems: Design and Implementation", Andrew S. > Tannenbaum, Prentice Hall, 1987. ISBN 0-13-637406-9, LoC > QA76.76.063T36 sef@kithrup.COM (Sean Eric Fagan) writes: > Hint: if the book is by Kernighan, Ritchie, Thompson, Bach, Tannenbaum, [...] > In that respect, if you want to get into the system hacking side of wizardry, > get Tannenbaum's _Operatings Systems: Design and Implementation_, which is Please, please, PLEASE! The man's name is "Tanenbaum", not "Tannenbaum"; he's not a Christmas tree (that was Baghdad, remember?). Regards, -- -- Gertjan van Oosten, gertjan@west.nl OR gertjan@westc.uucp -- West Consulting bv, Phoenixstraat 49, 2611 AL Delft, The Netherlands -- P.O. Box 3318, 2601 DH Delft -- Tel: +31-15-123190, Fax: +31-15-147889 Blackadder: "I'll be back before you can say 'antidisestablishmentarianism'..."
rbj@uunet.UU.NET (Root Boy Jim) (01/30/91)
In article <1991Jan26.142403.22812@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <16048@sdcc6.ucsd.edu> cs163wcr@sdcc10.ucsd.edu (I support the U.N.) writes: >>[1] Can you access a file by its i-node number? Something like >> (for C code) FILE *iopen (int inode, char *mode) ? > > I hope not. Otherwise permissions on directories wouldn't do much. How about treating the block device as magic directory where all the "files" are really direct links to inodes. Subject to device permission. For further information see the paper "Devices as Directorys" in the Winter 2017 Usenix Conference Procedings. > I do think the system design would have been cleaner if you only accessed >by i-node number, and mapping filename to inode was done outside the kernel. >But I doubt that I have many supporters in this "keep the kernel small" view. But that would make the kernel smaller. I have often wanted to mknode a directory into a file, edit it, and then mknod it back to a directory again. What do you mean fsck won't reconnect my file? I'll just make a directory entry and... >>[2] With Internet sockets, how does a machine accept()ing a >> socket connection know what machine is calling it? Does >> it rely on the calling program to tell it? Besides getpeername, there is the concept of privileged ports in UNIX. They can be allocated only by root, and presumably root writes only trusted programs. Like sendmail, ftp, and finger :-) -- Root Boy Jim Cottrell <rbj@uunet.uu.net> Close the gap of the dark year in between
greywolf@unisoft.UUCP (The Grey Wolf) (01/30/91)
In article <1991Jan26.142403.22812@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <16048@sdcc6.ucsd.edu> cs163wcr@sdcc10.ucsd.edu (I support the U.N.) writes: >>[1] Can you access a file by its i-node number? Something like >> (for C code) FILE *iopen (int inode, char *mode) ? > > I hope not. Otherwise permissions on directories wouldn't do much. I >do think the system design would have been cleaner if you only accessed >by i-node number, and mapping filename to inode was done outside the kernel. >But I doubt that I have many supporters in this "keep the kernel small" view. Perhaps iopen is, indeed, something of a farce (this is a thinly disguised understatement!). But one I've been wondering about is, why not an istat(dev, ino, statbuf) call? It's been argued that getting statistics about a certain inode would be insecure, but I fail to see the logic on this one. Of course, it might not be too useful, but I bet there are some times where it might be. Also, I think there might be some usefulness in having an iname(dev,ino) system call (restricted to the super-user). The idea of dealing with inode numbers outside the kernel might not be such a horrible idea. I believe this is partly the philosophy behind the inode_pagedaemon in MACH (I vaguely recall seeing something like this on a Mach machine we have here -- the term might be wrong). >=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= > Neil W. Rickert, Computer Science <rickert@cs.niu.edu> > Northern Illinois Univ. > DeKalb, IL 60115 +1-815-753-6940 -- thought: I ain't so damb dumn! war: Invalid argument ...!{ucbvax,acad,uunet,amdahl,pyramid}!unisoft!greywolf
bzs@world.std.com (Barry Shein) (01/31/91)
From: greywolf@unisoft.UUCP (The Grey Wolf) >But one I've been wondering about is, why not an istat(dev, ino, statbuf) >call? > >It's been argued that getting statistics about a certain inode would be >insecure, but I fail to see the logic on this one. Of course, it might >not be too useful, but I bet there are some times where it might be. That's your answer, it's insecure, it violates the model that you need access to the intervening directories to get to a file in any way. Simple models like that tend to be reasonably secure, models based on speculating on what possible mischief could such a feature be put to tend not to be. You find out what was missed in the speculation the hard way. You might want to read up on "covert channels" for starters, the information that a particular file is changing can be interesting (e.g. whether a particular type of logging has been enabled.) >Also, I think there might be some usefulness in having an iname(dev,ino) >system call (restricted to the super-user). What is this supposed to return? Being as file names are not unique and can require a search of the entire file system to find, I assume that's not what you had in mind. The kernel has no magic to find out this information, try the "find" command, nothing less will work (w/o complete re-work of the file system, that is, one can always propose total redesigns to unix which solves any problem at hand.) >The idea of dealing with inode numbers outside the kernel might not be >such a horrible idea. I believe this is partly the philosophy behind >the inode_pagedaemon in MACH (I vaguely recall seeing something like this >on a Mach machine we have here -- the term might be wrong). There's not much you can't do with inodes, as far as information querying goes, right now. Looking at a directory gives you inode to file name mapping, you can do stat's for more info, etc. I think you're presuming some sort of magic on the part of the kernel that basically doesn't exist. I doubt the features in Mach you allude to answer any of these interests. Last I checked enabling that user-level pagedaemon stuff mostly resulted in the kernel panicking all the time and sites generally left it off. The whole thing is rather strange, IMHO. -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
shore@mtxinu.COM (Melinda Shore) (01/31/91)
In article <BZS.91Jan30133640@world.std.com> bzs@world.std.com (Barry Shein) writes: |From: greywolf@unisoft.UUCP (The Grey Wolf) |>The idea of dealing with inode numbers outside the kernel might not be |>such a horrible idea. I believe this is partly the philosophy behind |>the inode_pagedaemon in MACH (I vaguely recall seeing something like this |>on a Mach machine we have here -- the term might be wrong). It would be more interesting if it really were in user space. The inode pager is a kernel process and basically allows paging to anonymous files. Access to inodes is done within the kernel, not in user space. (This is in Mach 2.5.) |I doubt the features in Mach you allude to answer any of these |interests. Last I checked enabling that user-level pagedaemon stuff |mostly resulted in the kernel panicking all the time and sites |generally left it off. The whole thing is rather strange, IMHO. It works well now. The one thing that might bother some is that after you shut down it leaves unreferenced files in the filesystem. Fsck gets rid of them, natch. -- Software longa, hardware brevis Melinda Shore shore@mtxinu.com mt Xinu ..!uunet!mtxinu.com!shore
guy@auspex.auspex.com (Guy Harris) (02/02/91)
>Besides getpeername, there is the concept of privileged ports in UNIX. >They can be allocated only by root, and presumably root writes only >trusted programs. Like sendmail, ftp, and finger :-) In addition, that concept doesn't exist on other OSes, so if you have a program that expects only privileged programs to be coming in from privileged ports, may I attach a PC running DOS and some TCP/IP software to your network? I'm sure it'd be lots of fun....
rbj@uunet.UU.NET (Root Boy Jim) (02/02/91)
In article <5653@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>Besides getpeername, there is the concept of privileged ports in UNIX. >>They can be allocated only by root, and presumably root writes only >>trusted programs. Like sendmail, ftp, and finger :-) > >In addition, that concept doesn't exist on other OSes, so if you have a >program that expects only privileged programs to be coming in from >privileged ports, may I attach a PC running DOS and some TCP/IP software >to your network? I'm sure it'd be lots of fun.... OK, since Guy opened up this line of discussion I may as well persue it. All the network really guarantees you is the identity of the IP address, and port number. It is your decision to trust a given host, and you delegate trust over what its users do, to its administrators and its operating system. Actually, only the network part of the info is truly reliable. Someone with a PC could wait until a well known trusted host is down for backups or maintenance or whatever, claim to be it, and the only way the rest of the net would know is if they cared about the ARP mapping between ethernet address and IP address. -- Root Boy Jim Cottrell <rbj@uunet.uu.net> Close the gap of the dark year in between
barmar@think.com (Barry Margolin) (02/03/91)
In article <120840@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes: >All the network really guarantees you is the identity of the IP address, >and port number. ... >Actually, only the network part of the info is truly reliable. Actually, none of it is *truly* reliable. The sending host can put anything in its source address field of the packet. However, if a host on a different network says that it's a host on your network it won't be able to receive any replies, because you'll send your replies to the real host. For TCP-based protocols this is generally good enough, because they require an initial two-way handshake before they do anything (it's possible to put data in the initial SYN packet, but I know of no protocols that make use of this). However, UDP-based protocols often work without requiring responses (e.g. an NFS DeleteFile operation will be obeyed and then the response will be attempted). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
scott@nbc1.ge.com (Scott Barman) (02/06/91)
In article <1991Jan27.093615.3231@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >Hint: if the book is by Kernighan, Ritchie, Thompson, Bach, Tannenbaum, >McKusick et al, and a few others, then it's worthwhile. One of the most >useful books I had, back when all I knew was some C, was _Advanced UNIX >Programming_, by someone whose name I sadly forget. But it was a good text, >and, after reading it, I went on to the more advanced books. (It was what I >would actually consider an advanced beginner's book. Still useful.) _Advanced UNIX Programming_, by Mark J. Rochkind, (c) 1985, Prentice-Hall ISBN 0-13-011818-4 ISBN 0-13-011800-1 (paperback) It is writen on System V Release 2 with some commentary on Xenix and BSD. HOWEVER, it does present interesting problems and solutions using those available tools that are portable to today's systems. Of the list above, Comer was missing. The original poster asked something about networking. A text I have found invaluable is: Internetworking with TCP/IP: Principles, Protocols, and Architecture by Douglas Comer, (c) 1988, Prentice-Hall, ISBN 0-13-470154-2 It is well written and has answered the vast majority of my questions on networking. -- scott barman | There comes a time in everyone's existance scott@nbc1.ge.com | when actions speak louder than words. (This does not represent any | Just make sure your actions are louder opinions of NBC or affiliates) | than the next guy's! - Anonymous
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (02/07/91)
In article <19029@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > In article <395@appserv.Eng.Sun.COM> lm@slovax.Eng.Sun.COM (Larry McVoy) writes: > >In article <16048@sdcc6.ucsd.edu> cs163wcr@sdcc10.ucsd.edu (I support the U.N.) writes: > >>[1] Can you access a file by its i-node number? Something like > >> (for C code) FILE *iopen (int inode, char *mode) ? > >Program included below. This program does an internal file tree walk > >to find the inode. Slow, but quite portable, contrary to a supposed > >wizard's opinion. I'm still wondering who you were trying to insult, Larry... Can we ask that you make sure your code satisfies the spec given before posting it? > Dan incorrectly > stated that it was a security whole if it could be executed > by mortal users - no, it is only a security whole if it is made > to work for mortal users. I stand corrected. Thanks. > Furthermore, it does not appear to address mount > points at all. Oops, another problem I missed. Good point. ---Dan
mjp@cel.co.uk (matthew pidd) (02/09/91)
jfh@rpp386.cactus.org (John F Haugh II) did verily bash:
[ .. mucho deleted .. ]
>FORTH LOVE IF HONK THEN
' HONK ' FORGET >CFA !
I used FORTH for about 3 years (groan). I don't claim to be a UNIX wizard
- tho I've done a fair bit of C and have read "The Design of the UNIX
Operating System" from front 2 back and back 2 front. A FORTH interface to
UNIX might'nt be a bad idea - at least you can test what things like
socketpair(2) do interactively instead of recompiling (thrash .. thrash ..
NFS groan ... ).
I've been tempted to write a FORTH compiler in C (as in build interactive
versions and loadable binaries with preprocessing etc) but just haven't had
the inclination. Does anyone know of such a creature ... and would it be
worth crafting?
(I'm in love with UNIX, but sometimes she won't talk to me
perhaps I'll just have to accept(2) my fate .. sigh).
Matt.
--
mjp@crosfield.co.uk | "Nil letti servicae-softus quietulus ukeepimae."
--------------------+ < UNIX - Live free or die >
"Poop poop", |==========================================================
Toad of toad hall | Opinions, herein, mine, expressed, are.jfh@rpp386.cactus.org (John F Haugh II) (02/09/91)
In article <8433@suns5.cel.co.uk> mjp@cel.co.uk (matthew pidd) writes: > I've been tempted to write a FORTH compiler in C (as in build interactive >versions and loadable binaries with preprocessing etc) but just haven't had >the inclination. Does anyone know of such a creature ... and would it be >worth crafting? Yes, there is a "cforth" in some archive or another. I have the source stashed away here, but don't recall which newsgroup I picked it out of. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "I've never written a device driver, but I have written a device driver manual" -- Robert Hartman, IDE Corp.
DAVID@penndrls.upenn.edu (02/15/91)
For FORTH written in C, try Mitch Bradley of Bradley ForthWorks (wmb@MITCH.ENG.SUN.COM), who also has a SUN FORTH (by the way, he is also responsible for the FORTH in the Sparcstation boot proms) as well as FORTHs for a number of other platforms. Prices are very reasonable (circa $50, I think). If you can't afford anything but freeware, try Mikael Patel (eru!hagbard!sunic!liuida!mip@BLOOM-BEACON.MIT.EDU is the only address I have for him and I've never tried to use it) who has constructued TILE FORTH to run on Sun's and other Unix platforms. Actually, I don't know for sure that Mikael is giving away the current version, but there was at least one version that he posted to ForthNet. (ForthNet, by the way, is a virtual network of Forth mailing lists, BBSs, and other stuff with connections to the BITNET FIGI-L, usenet comp.language.forth (I think that is the right group) and to the Forth roundtable on Genie. If you like FORTH, it is worth getting connected to; right now the hot topic is the upcomming ANS FORTH dpANS.) -- R. David Murray (DAVID@PENNDRLS.UPENN.EDU) P.S.: I tried to mail this before I posted it, but the mail bounced. Hope you wizards assembled don't mind too much, this not being a unix-wizardly subject . . .
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (02/16/91)
As quoted from <19041@rpp386.cactus.org> by jfh@rpp386.cactus.org (John F Haugh II): +--------------- | In article <8433@suns5.cel.co.uk> mjp@cel.co.uk (matthew pidd) writes: | > I've been tempted to write a FORTH compiler in C (as in build interactive | >versions and loadable binaries with preprocessing etc) but just haven't had | >the inclination. Does anyone know of such a creature ... and would it be | >worth crafting? | | Yes, there is a "cforth" in some archive or another. I have the | source stashed away here, but don't recall which newsgroup I picked | it out of. +--------------- TILE was posted to comp.lang.forth,alt.sources (and might have been sent to comp.sources.unix; I don't rememeber it having been in .misc, but since I don't have the index any more I can't check :-) at least twice (different versions). ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
rbj@uunet.UU.NET (Root Boy Jim) (02/20/91)
In article <26014@adm.brl.mil> DAVID@penndrls.upenn.edu writes:
?For FORTH written in C, try Mitch Bradley of Bradley ForthWorks
?(wmb@MITCH.ENG.SUN.COM), who also has a SUN FORTH (by the way, he is
?also responsible for the FORTH in the Sparcstation boot proms)
I was amused when I learned of Sun's Forth Generation Workstations :-)
My only question is: Why Not NeWS? Or a subset?
--
[rbj@uunet 1] stty sane
unknown mode: saneemv@ox.com (Ed Vielmetti) (02/28/91)
In article <2285@tuvie.UUCP> mike@vlsivie.tuwien.ac.at (Michael K. Gschwind) writes: > I hope not. Otherwise permissions on directories wouldn't do much. I >do think the system design would have been cleaner if you only accessed >by i-node number, and mapping filename to inode was done outside the kernel. This is what is done on Apollo's DomainOS UNIX-clone. It is however a security nightmare. Things like chroot don't work, so you can't support anonymous ftp et al. Neat idea, but isn't fully UNIX compatible. There's no particular reason that anonymous ftp requires the chroot() system call. Granted, it makes it handy, but an alternative implementation could simply inspect every filename to be sure that the user didn't try to ../.. themself out of the protected area. See dabo.ifs.umich.edu for an ftpd that does secure anonymous ftp for the Apollo. -- Msen Edward Vielmetti /|--- moderator, comp.archives emv@msen.com