staff@cadlab.sublink.ORG (Alex Martelli) (12/24/90)
There are problems with the large, interesting abc package. Some have already been identified (i.e. the getwd() business), although the suggested patch as posted does not seem to clear them up yet - a minor point, though. Another one is the way program brand, inside Setup, goes about identifying the kind of Unix one has. It FIRST sees if SIGCHLD is #defined, and if so, it EXCLUDES that one may have an AT&T System-V variant. But I have tried it on both Interactive System V/386 3.2 version 2.2, and HP/UX 7.0, two Sys/V flavors, and BOTH *do* define SIGCHLD *as well as* SIGCLD; so it seems Setup has it upside-down. I have changed it to FIRST test for SIGCLD (as identification of Sys/III or Sys/V), and only if that is not set if SIGCHLD then tested. This way, both of my systems are correctly identified as S/V. With this change, all the compilations in the make go flawlessly. Unfortunately, there seems to be LOTS of pieces missing; the linking step collapses in flames. Here are the unsolved references, from ld error message reformatted to save several lines: _main _ptnsyze _setintrhandler _resetintrhandler _help _slowterminal _hushbaby _int_mod _int_ldiv _int_quot _nodetype _node5 _node2 _node3 _node1 _node4 _node6 _node8 _node9 _mk_ref _wsp_arg _is_gr_reccall _bws_arg _stripped _split _upper _lower _choice _mk_fun _mk_prd _initsig _use_bed _ins_range _mk_rbounds _mk_trimloc _mk_tbseloc _mk_simploc _mk_how _mk_indirect _ask_for _mkchar _getwd I have the same, identical set of unsolved externals, both on HP/UX and on Interactive 2.2. Some appear to be minor problems related to above-mentioned glitches, e.g. getwd; others look a mite more FUNDAMENTAL - eg. main!; but there are just SO many of them, that I can't think of any simple explanation for them all, unless it be a missing piece! What gives? Awaiting with interest... this one seemed like a nice Christmas gift to start teaching programming to my son - pity! -- Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 45, Bologna, Italia Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).
jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) (12/27/90)
In article <565@cadlab.sublink.ORG> staff@cadlab.sublink.ORG (Alex Martelli) writes: >There are problems with the large, interesting abc package. >Some have already been identified (i.e. the getwd() business), >although the suggested patch as posted does not seem to clear >them up yet - a minor point, though. Oops. Minor flaw in my patch. If you've already applied it, just change #ifdef GETCWD to #ifdef HAS_GETCWD both places it appears in unix/u1file.c, and it'll work OK. If you haven't applied it yet, the corrected patch is at the end of this article. As another poster noted, there are several files missing from the version posted to comp.unix.sources. I finally gave up on that one, FTPd the whole thing from uunet.uu.net (it's in languages/abc/abc.unix.tar.Z, if memory serves), and built it (after applying my corrected patch). Unfortunately, it blows up when I try any of the examples. The problem appears to be in the division routines, and can be reproduced (on my NCR Tower XP) by issuing WRITE 280/204...the PC executable reports 1.372-something-or-other, but the compiled Unix one reports 1. I haven't tracked this one down yet. Here's the corrected getcwd() patch: --------------------8<---------------cut here--------------->8--------------- *** Setup.orig --- Setup ************** *** 686,691 perror="#define" mkdir="#define" getwd="#define" rename="#define" select="#define" readdir="#define" --- 686,692 ----- perror="#define" mkdir="#define" getwd="#define" + getcwd="#undef " rename="#define" select="#define" readdir="#define" ************** *** 695,700 perror="#define" mkdir="#undef " getwd="#undef " rename="#undef " select="#undef " readdir="#undef " --- 696,702 ----- perror="#define" mkdir="#undef " getwd="#undef " + getcwd="#undef " rename="#undef " select="#undef " readdir="#undef " ************** *** 704,709 perror="#define" mkdir="#define" getwd="#undef " rename="#undef " select="#undef " readdir="#undef " --- 706,712 ----- perror="#define" mkdir="#define" getwd="#undef " + getcwd="#define" rename="#undef " select="#undef " readdir="#undef " ************** *** 714,719 perror="#undef " mkdir="#undef " getwd="#undef " rename="#undef " select="#undef " readdir="#undef " --- 717,723 ----- perror="#undef " mkdir="#undef " getwd="#undef " + getcwd="#undef " rename="#undef " select="#undef " readdir="#undef " ************** *** 751,756 /^#define HAS_PERROR/s?#define?$perror? /^#define HAS_MKDIR/s?#define?$mkdir? /^#define HAS_GETWD/s?#define?$getwd? /^#define HAS_RENAME/s?#define?$rename? /^#define HAS_SELECT/s?#define?$select? /^#define HAS_READDIR/s?#define?$readdir? --- 755,761 ----- /^#define HAS_PERROR/s?#define?$perror? /^#define HAS_MKDIR/s?#define?$mkdir? /^#define HAS_GETWD/s?#define?$getwd? + /^#define HAS_GETCWD/s?#define?$getcwd? /^#define HAS_RENAME/s?#define?$rename? /^#define HAS_SELECT/s?#define?$select? /^#define HAS_READDIR/s?#define?$readdir? ************** *** 801,817 case $strchr in strchr) $editor uhdrs/os.h <<EOF /#define strchr/,/#define strrchr/d - w - q - EOF - ;; - esac - - case $unix in - ATT) $editor uhdrs/os.h <<EOF - /#define HAS_GETWD/a - #define getwd(path) getcwd(path, SIZE_PATH) - . w q EOF --- 806,811 ----- case $strchr in strchr) $editor uhdrs/os.h <<EOF /#define strchr/,/#define strrchr/d w q EOF *** unix/u1file.c.orig --- unix/u1file.c ************** *** 6,11 #include "bfil.h" extern char *getenv(); extern char *getwd(); Visible char *curdir() { --- 6,14 ----- #include "bfil.h" extern char *getenv(); + #ifdef HAS_GETCWD + extern char *getcwd(); + #else extern char *getwd(); #endif ************** *** 7,12 extern char *getenv(); extern char *getwd(); Visible char *curdir() { static char buffer[SIZE_PATH]; --- 10,16 ----- extern char *getcwd(); #else extern char *getwd(); + #endif Visible char *curdir() { static char buffer[SIZE_PATH]; ************** *** 10,15 Visible char *curdir() { static char buffer[SIZE_PATH]; return getwd(buffer); } --- 14,22 ----- Visible char *curdir() { static char buffer[SIZE_PATH]; + #ifdef HAS_GETCWD + return getcwd(buffer, SIZE_PATH); + #else return getwd(buffer); #endif } ************** *** 11,16 Visible char *curdir() { static char buffer[SIZE_PATH]; return getwd(buffer); } Hidden string searchfile(base, abclib) string base; string abclib; { --- 18,24 ----- return getcwd(buffer, SIZE_PATH); #else return getwd(buffer); + #endif } Hidden string searchfile(base, abclib) string base; string abclib; { *** unix/u1os.c.orig --- unix/u1os.c ************** *** 16,21 #endif /* !NDEBUG */ #ifndef HAS_GETWD /* getwd - get working directory */ --- 16,24 ----- #endif /* !NDEBUG */ + #ifdef HAS_GETCWD + #define HAS_GETWD /* merge the two #defines */ + #endif #ifndef HAS_GETWD /* getwd - get working directory */ *** uhdrs/os.h.gen.orig --- uhdrs/os.h.gen ************** *** 67,72 #define HAS_PERROR /* can use sys_errlist and sys_nerr (from perror(3)) */ #define HAS_MKDIR /* mkdir() and rmdir() available */ #define HAS_GETWD /* getwd() available */ #define HAS_RENAME /* rename() available */ #define HAS_SELECT /* 4.2 BSD select() system call available */ #define HAS_READDIR /* Berkeley style directory reading routines */ --- 67,73 ----- #define HAS_PERROR /* can use sys_errlist and sys_nerr (from perror(3)) */ #define HAS_MKDIR /* mkdir() and rmdir() available */ #define HAS_GETWD /* getwd() available */ + #define HAS_GETCWD /* getcwd() available? */ #define HAS_RENAME /* rename() available */ #define HAS_SELECT /* 4.2 BSD select() system call available */ #define HAS_READDIR /* Berkeley style directory reading routines */ -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jmaynard@thesis1.hsch.utexas.edu | adequately be explained by stupidity. "...flames are a specific art form of Usenet..." -- Gregory G. Woodbury
staff@cadlab.sublink.ORG (Alex Martelli) (12/27/90)
jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes: ... >As another poster noted, there are several files missing from the version >posted to comp.unix.sources. I finally gave up on that one, FTPd the whole >thing from uunet.uu.net (it's in languages/abc/abc.unix.tar.Z, if memory Hmmm, but how are us poor FTPless folks supposed to cope? Any chance to see the missing files on the net anytime soon...? -- Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).
schulte@thp.uni-koeln.de (Martin Schulte) (12/30/90)
Several readers of this group complained about missing files in the abc-distribution. I got the original version via ftp from uunet.uu.net:/languages/abc/abc.unix.tar.Z With the sun4-patch I described lastly, it now gets compiled on a SunOS 4.1 Sparc ! For those of you who have no ftp-access, I made a little tar-files containing all the missing files ! If you drop me a little note, I will send it to you by email ! Martin -- -- Martin Schulte Institute for Theoretical Physics University of Cologne/Germany Internet: schulte@thp.uni-koeln.de
hsiegel@cvbnet.prime.com (mailhost) (12/30/90)
From article <SCHULTE.90Dec29203525@sparc0.thp.uni-koeln.de>, by schulte@thp.uni-koeln.de (Martin Schulte): > > Several readers of this group complained about missing files > in the abc-distribution. > > I got the original version via ftp from > uunet.uu.net:/languages/abc/abc.unix.tar.Z > > With the sun4-patch I described lastly, it now gets compiled on a > SunOS 4.1 Sparc ! > > For those of you who have no ftp-access, I made a little tar-files > containing all the missing files ! > > If you drop me a little note, I will send it to you by email ! Since the files appear to be missing in the posting to the net, and it does look like an attractive possibility, I suggest you pack up the missing files in "shar" format and post them to the net. Under most circumstances, I would think it wise to communicate via Email -- but I suspect you're going to be flooded! If you decide not to post, please send the files via Email to Howard Siegel (hsiegel@clavier.prime.com), and accept my thanks in advance. Howard Siegel hsiegel@clavier.prime.com Prime/Computervision hsiegel@primerd.prime.com Bedford, Mass. hsiegel%clavier.prime.com@RELAY.CS.NET (617) 275-1800 x4064 cvbnet!hsiegel@primerd.prime.com
gary@proa.sv.dg.com (Gary Bridgewater) (12/31/90)
In article <SCHULTE.90Dec29203525@sparc0.thp.uni-koeln.de> schulte@thp.uni-koeln.de (Martin Schulte) writes: > >With the sun4-patch I described lastly, it now gets compiled on a >SunOS 4.1 Sparc ! Hmm. Doesn't your compiler/linker notice the strange call to remove? Perhaps no one else has run with full header files?? gcc -pipe -O -DNDEBUG -I../bhdrs -I../ihdrs -I../uhdrs -c i3loc.c i3loc.c: In function l_remove: i3loc.c:430: warning: argument passing between incompatible pointer types i3loc.c:430: too many arguments to function `remove' i3loc.c: In function unbind: i3loc.c:456: warning: argument passing between incompatible pointer types i3loc.c:456: too many arguments to function `remove' *** Error code 1 But the big question - which I have reported to the authors - is what is the call to remove _really_ supposed to be? Remove() deletes files. It doesn't look like that is what is wanted here at all. -- Gary Bridgewater, Data General Corporation, Sunnyvale California gary@sv.dg.com or {amdahl,aeras,amdcad}!dgcad!gary C++ - it's the right thing to do.
schulte@thp.uni-koeln.de (Martin Schulte) (01/02/91)
I stated, that I made abc compiling on Sun4, but gary@proa.sb.dg.com still has problems: >Hmm. Doesn't your compiler/linker notice the strange call to remove? Perhaps >no one else has run with full header files?? > gcc -pipe -O -DNDEBUG -I../bhdrs -I../ihdrs -I../uhdrs -c i3loc.c >i3loc.c: In function l_remove: >i3loc.c:430: warning: argument passing between incompatible pointer types >i3loc.c:430: too many arguments to function `remove' >i3loc.c: In function unbind: >i3loc.c:456: warning: argument passing between incompatible pointer types >i3loc.c:456: too many arguments to function `remove' >*** Error code 1 This is certainly due to the fact that you use the ANSI-conform gcc instead of cc. I don't know how you managed it to get the gcc in your Makefile, but if you use cc or gcc -traditional instead it should work. But, as far as we experienced here, it's anyway at least not worse to use cc instead of gcc on the Sparc, the suns cc produces faster code and supports dynamic-linking. >But the big question - which I have reported to the authors - is what is >the call to remove _really_ supposed to be? Remove() deletes files. It ^^^^^^^^ >doesn't look like that is what is wanted here at all. I only took a short look on the sources, why do you think it should remove files ? Martin -- -- Martin Schulte Institute for Theoretical Physics University of Cologne/Germany Internet: schulte@thp.uni-koeln.de
sef@kithrup.COM (Sean Eric Fagan) (01/02/91)
In article <SCHULTE.91Jan1200851@sun0.thp.uni-koeln.de> schulte@thp.uni-koeln.de (Martin Schulte) writes: >>But the big question - which I have reported to the authors - is what is >>the call to remove _really_ supposed to be? Remove() deletes files. It > ^^^^^^^^ >>doesn't look like that is what is wanted here at all. > >I only took a short look on the sources, why do you think it should remove >files ? kithrup 1> man S remove REMOVE(S) UNIX System V REMOVE(S) Name remove - removes filename Syntax #include <stdio.h> int remove (filename) const char *filename; Description The remove function causes the file whose name is the string pointed to by filename to be no longer accessible by that name. A subsequent attempt to open that file using that name will fail, unless it is created anew. If the file is open, the behavior of the remove function is implementation-defined. [etc.] Seems to me that that pretty much indicates that remove() removes files, don't you think? Listen *very* carefully: it doesn't matter *what* compiler you use, if you have a function <x> in your standard library, and a program y which has its own definition of a function <x>, then you are opening yourself up to problems. What are you going to do if some of the other routines from your standard library use the function <x>, and the alien <x> has different semantics? (As it does in this case.) For an example of how to totally screw yourself, take any given program, and add this function: int write(int a, char *b, int c, void *d) { printf ("a = %d, b = %s, c = %d, d = %x\n", a, b, c, d); return -5; } This is an example of "Name Space Pollution." Both ANSI and POSIX have addressed this, and have come up with a list of functions and variables that are not to be touched by application programmers. remove() is in both of them. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
nicb@ctr@italy.eu.net (Nicola Bernardini) (01/02/91)
In article <1990Dec31.081319.2012@proa.sv.dg.com> gary@proa.sv.dg.com (Gary Bridgewater) writes: >In article <SCHULTE.90Dec29203525@sparc0.thp.uni-koeln.de> schulte@thp.uni-koeln.de (Martin Schulte) writes: >> >>With the sun4-patch I described lastly, it now gets compiled on a >>SunOS 4.1 Sparc ! > >Hmm. Doesn't your compiler/linker notice the strange call to remove? Perhaps >no one else has run with full header files?? > gcc -pipe -O -DNDEBUG -I../bhdrs -I../ihdrs -I../uhdrs -c i3loc.c >i3loc.c: In function l_remove: >i3loc.c:430: warning: argument passing between incompatible pointer types >i3loc.c:430: too many arguments to function `remove' >i3loc.c: In function unbind: >i3loc.c:456: warning: argument passing between incompatible pointer types >i3loc.c:456: too many arguments to function `remove' > >But the big question - which I have reported to the authors - is what is >the call to remove _really_ supposed to be? Remove() deletes files. It >doesn't look like that is what is wanted here at all. The problem is that "remove" is a macro for unlink defined in many stdio.h header files. What you have to do is to add (sorry, I have no patch program!) in uhdrs/os.h (or in uhdrs/os.h.gen, if you behave by the book): #ifdef remove /* must have been in stdio.h, evidently */ #undef remove #endif /* remove */ and everything will shut up after that. ------------------------------------------ Nicola Bernardini - nicb%ctr@italy.eu.net Centro Tempo Reale Villa Strozzi Via Pisana, 77 50143 Firenze Tel. ++3955/702444 Fax. ++3955/717712 -- ------------------------------------------ Nicola Bernardini - nicb%ctr@italy.eu.net Centro Tempo Reale Villa Strozzi
jeff@onion.pdx.com (Jeff Beadles) (01/02/91)
In <1991Jan01.211524.18484@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >In <SCHULTE.91Jan1200851@sun0.thp.uni-koeln.de> schulte@thp.uni-koeln.de > (Martin Schulte) writes: >>>But the big question - which I have reported to the authors - is what is >>>the call to remove _really_ supposed to be? Remove() deletes files. It >> ^^^^^^^^ >>>doesn't look like that is what is wanted here at all. >> >>I only took a short look on the sources, why do you think it should remove >>files ? > >kithrup 1> man S remove > > > REMOVE(S) UNIX System V REMOVE(S) > > Name > remove - removes filename > > Syntax > #include <stdio.h> > int remove (filename) > const char *filename; ... >Seems to me that that pretty much indicates that remove() removes files, >don't you think? It would indicate that if I had that particular function in libc, but since I don't... Now take a look at another case: % man remove No manual entry for `remove'. This looks like a System-Vism. Most systems that I've seen do however have unlink(2). (This is a BSD based system.) % man unlink UNLINK(2) COMMAND REFERENCE UNLINK(2) NAME unlink - remove directory entry SYNOPSIS unlink(path) char *path; DESCRIPTION Unlink removes the entry for the file path from its directory. If this entry was the last link to the file, and no process has the file open, then all resources associated with the file are reclaimed. If, however, the file was open in any process, the actual resource reclamation is delayed until it is closed, even though the directory entry has disappeared. ... -Jeff -- Jeff Beadles jeff@onion.pdx.com
schulte@thp.uni-koeln.de (Martin Schulte) (01/03/91)
I reply to sef@kithrup.COM I asked >I only took a short look on the sources, why do you think it should remove >files ? Later, he responded >kithrup 1> man S remove > REMOVE(S) UNIX System V REMOVE(S) > >... man page follows OK, this looks like the ever lasting problem: people asking questions without specifying their environment ! This man-page (and function) does neither exist in SunOS4.1, nor in System V.3! He further said: >Listen *very* carefully: it doesn't matter *what* compiler you use, if you >have a function <x> in your standard library, and a program y which has its >... I never said something different ! Martin -- -- Martin Schulte Institute for Theoretical Physics University of Cologne/Germany Internet: schulte@thp.uni-koeln.de
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/04/91)
As quoted from <1991Jan01.211524.18484@kithrup.COM> by sef@kithrup.COM (Sean Eric Fagan): +--------------- | In article <SCHULTE.91Jan1200851@sun0.thp.uni-koeln.de> schulte@thp.uni-koeln.de (Martin Schulte) writes: | >>But the big question - which I have reported to the authors - is what is | >>the call to remove _really_ supposed to be? Remove() deletes files. It | > ^^^^^^^^ | >>doesn't look like that is what is wanted here at all. | > | >I only took a short look on the sources, why do you think it should remove | >files ? | | remove - removes filename +--------------- And, lest anyone wonder, remove() is in both recent BSD (2.9 and later, 4.2 and later, at least) and recent System V (SVR3.2 has it; I didn't have it on our SVR3.1 system at work). It's *real* risky to use that name for a private function of a program. ++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
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/04/91)
As quoted from <1991Jan2.155305.10523@onion.pdx.com> by jeff@onion.pdx.com (Jeff Beadles): +--------------- | This looks like a System-Vism. Most systems that I've seen do however have | unlink(2). (This is a BSD based system.) +--------------- BSD (Sun?) added it for NFS: the semantics of unlink() are valid only for UNIX-like file systems, while remove() has semantics that are valid over a much wider set of filesystem types. AT&T picked it up later, apparently in SVR3.2. I was substituting unlink() for remove() in BSD sources from the net to make them work under Xenix, System III, and SVR2 and SVR3.1 long before AT&T got into it. ++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
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/04/91)
As quoted from <SCHULTE.91Jan3123904@sun4.thp.uni-koeln.de> by schulte@thp.uni-koeln.de (Martin Schulte):
+---------------
| This man-page (and function) does neither exist in SunOS4.1, nor in System V.3!
+---------------
Did they change things *again*, or were you thrown by SCO's adoption of
Microsoft's bizarre and incompatible manual sections? Try "man 2 remove".
(It's barely possible that it'll be in section 3, though.)
(I really wish SCO had stuck with the traditional manual sections. It would
make it easier for me to find things. (I also *really*, *really* wish AT&T
hadn't done some mucking about of their own --- last I saw, section 5 was for
different things in BSD and AT&T manuals. I *can* live with the ?_man
subdirectories, though.))
++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: ALLBERYpjg@acsu.buffalo.edu (Paul Graham) (01/06/91)
sef@kithrup.COM (Sean Eric Fagan) writes: [about remove(S) and having your own function with a libc name] |This is an example of "Name Space Pollution." Both ANSI and POSIX have |addressed this, and have come up with a list of functions and variables that |are not to be touched by application programmers. remove() is in both of |them. my os is supposed to posix compliant and i don't have remove(S). in fact i've never seen remove(S). what section is 'S' and what version(s) of unix have remove(S)? -- pjg@acsu.buffalo.edu / rutgers!ub!pjg / pjg@ubvms (Bitnet) opinions found above are mine unless marked otherwise.
sef@kithrup.COM (Sean Eric Fagan) (01/07/91)
In article <53567@eerie.acsu.Buffalo.EDU> pjg@acsu.buffalo.edu (Paul Graham) writes: >my os is supposed to posix compliant and i don't have remove(S). Then your OS is not posix compliant. In particular, remove() is required by ANSI C, which is required by POSIX. >in >fact i've never seen remove(S). what section is 'S' and what >version(s) of unix have remove(S)? SCO's 'S' section is the equivalent of everyone else's 2 and 3 sections. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
ronald@robobar.co.uk (Ronald S H Khoo) (01/07/91)
pjg@acsu.buffalo.edu (Paul Graham) writes: > my os is supposed to posix compliant and i don't have remove(S). in > fact i've never seen remove(S). what section is 'S' and what > version(s) of unix have remove(S)? I don't know about POSIX, but ANSI requires remove() [4.9.4.1]. The "S" category in remove(S) shows use of the braindamaged SCO manual pages. -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
guy@auspex.auspex.com (Guy Harris) (01/12/91)
>This man-page (and function) does neither exist in SunOS4.1, nor in >System V.3! The manual page "remove(S)" certainly doesn't exist under SunOS 4.1, and there doesn't seem to be a "remove(N)" in one of the more normally-named sections in the SunOS documentation. But as for the *function* "remove()", that's a different story: bootme% cat /etc/motd SunOS Release 4.1 (DLCD60) #18: Tue Dec 4 19:02:50 PST 1990 bootme% nm /usr/lib/libc.a | egrep remove remove.o: 00000000 T _remove
guy@auspex.auspex.com (Guy Harris) (01/12/91)
>BSD (Sun?) added it for NFS: the semantics of unlink() are valid only for >UNIX-like file systems, while remove() has semantics that are valid over a >much wider set of filesystem types. It sounds as if you're thinking of "rmdir()", which BSD added, but not specifically for NFS, as NFS didn't exist (the idea of having network file systems did, but NFS *in particular* didn't) when 4.2BSD was done. "unlink()", for plain files, is equivalent to "remove()"; it gets turned into a "remove this file" request when sent to an NFS server by a SunOS (or probably most other NFS) clients. Neither 4.2BSD nor 4.3BSD nor 4.3-tahoe have "remove()" (yes, I checked the source to 4.3-tahoe); 4.3-reno has it, as a wrapper around "unlink()". SunOS didn't have it prior to SunOS 4.1.
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/12/91)
As quoted from <5183@auspex.auspex.com> by guy@auspex.auspex.com (Guy Harris): +--------------- | It sounds as if you're thinking of "rmdir()", which BSD added, but not | specifically for NFS, as NFS didn't exist (the idea of having network | file systems did, but NFS *in particular* didn't) when 4.2BSD was done. +--------------- Then where the heck did it come from? I *know* I was hacking remove() into unlink() in otherwise extremely BSD-ish sources in '86.... ++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
meissner@osf.org (Michael Meissner) (01/12/91)
In article <5183@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: | >BSD (Sun?) added it for NFS: the semantics of unlink() are valid only for | >UNIX-like file systems, while remove() has semantics that are valid over a | >much wider set of filesystem types. ... | "unlink()", for plain files, is equivalent to "remove()"; it gets turned | into a "remove this file" request when sent to an NFS server by a SunOS | (or probably most other NFS) clients. | | Neither 4.2BSD nor 4.3BSD nor 4.3-tahoe have "remove()" (yes, I checked | the source to 4.3-tahoe); 4.3-reno has it, as a wrapper around | "unlink()". SunOS didn't have it prior to SunOS 4.1. The ANSI standard added remove. It is the same as unlink under UNIX. I forget whether it was added on general concensious, or whether the VMS-C representative insisted on it. Since 4.2, 4.3, and 4.3-tahoe preceded the ANSI standard, they certainly can't be held accountable for not having it..... -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?
guy@auspex.auspex.com (Guy Harris) (01/13/91)
>Then where the heck did it come from? I *know* I was hacking remove() into >unlink() in otherwise extremely BSD-ish sources in '86.... Beats me why the sources you saw used "remove()", but they sure as heck wouldn't have worked on vanilla 4.2BSD or 4.3BSD....
guy@auspex.auspex.com (Guy Harris) (01/13/91)
>The ANSI standard added remove. Yup, I know.... >It is the same as unlink under UNIX. Perhaps, unless there's some way in which one can read the standard as to say "remove()" should work on directories - but a quick look at POSIX didn't indicate any way in which I'd read the standard as saying that. >Since 4.2, 4.3, and 4.3-tahoe preceded the ANSI standard, Yup, I know... >they certainly can't be held accountable for not having it..... I wasn't holding them accountable for not having it, I was just noting that it didn't have it.