Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!adm!Postmaster%FINFUN.BITNET@WISCVM.WISC.EDU From: Postmaster%FINFUN.BITNET@WISCVM.WISC.EDU (PMDF Mail Server) Newsgroups: comp.unix.questions Subject: Undeliverable mail Message-ID: <9726@brl-adm.ARPA> Date: Fri, 9-Oct-87 22:03:17 EDT Article-I.D.: brl-adm.9726 Posted: Fri Oct 9 22:03:17 1987 Date-Received: Mon, 12-Oct-87 00:58:18 EDT Sender: news@brl-adm.ARPA Lines: 465 The message could not be delivered to: Addressee: pietilainen Reason: %MAIL-E-NOSUCHUSR, no such user PIETILAINEN at node OPMVAX ---------------------------------------- Received: from FINFUN.BITNET by OPMVAX.KPO.FI; Sat, 10 Oct 87 03:10 O Received: From WISCVM(SMTP) by FINFUN with RSCS id 4582 for PIETILAI@FINFUN; Sat, 10 Oct 87 03:10 O Received: from SEM.BRL.MIL by WISCVM.WISC.EDU ; Fri, 09 Oct 87 10:39:57 CDT Received: by SEM.BRL.ARPA id ab21070; 29 Sep 87 4:46 EDT Received: from SEM.BRL.MIL by SEM.brl.ARPA id ab20790; 29 Sep 87 2:52 EDT Received: from sem.brl.mil by SEM.BRL.ARPA id aa20763; 29 Sep 87 2:46 EDT Date: Tue, 29 Sep 87 02:46:04 EST From: The Moderator Subject: INFO-UNIX Digest V4#029 To: INFO-UNIX@BRL.ARPA Reply-to: INFO-UNIX@BRL.ARPA Message-ID: <8709290246.aa20763@SEM.BRL.ARPA> INFO-UNIX Digest Tue, 29 Sep 1987 V4#029 Today's Topics: mounting forms on lp ?????? Pascal to C translator wanted Re: tty watcher Re: SysV lp spooler a security hole Re: Using subdirectories from make CSI Tape for 3B2/400 question about signal Re: Re: Re: History (origin of foobar) Re: Invisible Ascii with VI Re: question about signal Need getting Kermit or Xmodem going between SUNos and APPLE II ----------------------------------------------------------------- From: "Donald D. Woelz" Subject: mounting forms on lp ?????? Date: 24 Sep 87 20:46:23 GMT To: info-unix@brl-sem.arpa I am using System V.2.2 on a NSC32032 based system. I have a printer connected via serial rs232 port. I want to be able to mount different forms on the printer for various reports (such as mailing labels, invoices, etc.). What do I need to do to the interface shell script, or any other program (I have only binaries for all but the interface program) to accommodate changing forms without other reports in the print queue printing on those forms, and vice-versa? I am in desperate need of a quick solution. Your collective help would be much appreciated. Thanks ******************************************************* Don Woelz GENROCO, Inc. {seismo?, ames, rutgers, harvard}!uwvax!uwmcsd1!grc!don ******************************************************* ----------------------------- From: Duke Robillard Subject: Pascal to C translator wanted Date: 24 Sep 87 21:21:01 GMT To: info-unix@SEM.BRL.MIL We have some Pascal code (about 12,000 lines) that we wish were C (so we could have the same source for Suns, VAX/UNIX, Amdahl/UTS, and Cray machines). I understand HCR Corp. has a Pascal compiler that translates to C first and then compiles the C. Has anyone used this product to translate Pascal to maintainable C? Has anyone used anything else to translate Pascal to maintainable C? -- +-------------------------------------------------------------------+ | Duke Robillard {ihnp4!}m10ux!rgr | | Disclaimer: I claim to live in Dis. | +-------------------------------------------------------------------+ ----------------------------- From: Peter da Silva Subject: Re: tty watcher Date: 25 Sep 87 04:06:25 GMT To: info-unix@SEM.BRL.MIL In article <1431@cognos.UUCP>, brianc@cognos.uucp (Brian Campbell) writes: > ! <...an effective tty watcher or "spy" program, > ! ! When did MS-DOS start supporting multiple users so that such a thing > ! would make sense? > Well, although the posted message didn't specifically mention it, the > original question related to watching what callers were doing on a BBS. > I guess MS-DOS just might have won this round. You can, of course, do the same thing on UNIX (watch what people are doing on a BBS), exactly the same way (have the BBS program echo stuff). I've seen two systems that do it (one of which not only traps the characters, but talks to called processes via pipes so you can have other programs do mail, etc, and have them echoed too). -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*. ----------------------------- From: "Michael C. De Masi" Subject: Re: SysV lp spooler a security hole Date: 24 Sep 87 17:45:48 GMT To: info-unix@brl-sem.arpa In article <484@riddle.UUCP>, domo@riddle.UUCP (Dominic Dunlop) writes: ... > > Incidentally, it occurs to me that the only reason that > > lp < file > > gets around the problem is because of a security hole in the UNIX kernel. > Were access rights checked on every read, rather than just when the file is > opened, a setuid program would be unable to read a file with restricted > permissions, even if it had been opened and attached to stdin by a shell > which was able to read it. ... > Dominic Dunlop > domo@riddle.uucp domo@sphinx.co.uk How can this be considered a security hole? When redirecting standard input from a file into a program, setuig-gid or not, one still has to have the proper permissions to read the file that's being redirected. That is, if you can't read the file, you can't redirect it as input to another program, anyway, so what's the problem? If I'm reading what you wrote correctly, every utility within UNIX would have to have the same ownership (effectively) as every file on which it is to work. You can't mean that, can you? By the same token, what you say is true, permissions are only checked at the time a file is opened. But all that amounts to is that if you are reading from (or writing to) one of my files, and within the course of your process I change the permissions on that file in such a way as to make it inaccessable to you, it will have no effect on your process (unless you close the file, for some rea- son, then try to re-open it) but again, what's the big deal? If you wish to maintain a file with restricted access, create it that way. As I said, perhaps I misunderstand you, if so, please point out my error (Nothing like a good argument, huh?) -- Michael C. De Masi - AT&T Communications (For whom I work and not speak) 3702 Pender Drive, Fairfax, Virginia 22030 Phone: 703-246-9555 UUCP: seismo!decuac!grebyn!paisano!demasi "There are monkey boys on the premises." Unknown red Lectroid. ----------------------------- From: Wallis Subject: Re: Using subdirectories from make Date: 25 Sep 87 13:31:05 GMT To: info-unix@brl-sem.arpa In article <204@tut.cis.ohio-state.edu>, mdf@tut.cis.ohio-state.edu (Mark D. Freeman) writes: > In <831@ektools.UUCP> jim@ektools.UUCP (James Hugh Moore) writes: > >Basically, he has asked me if > >there is a way of keeping source in one directory and objects in another and > >using one makefile. > > >we would like to specify paths from a common directory, and have different > >directories for source, objects, special testing software, etc. > > I am in need of similar advice. I want: > > /foo = sources > /foo/reg = objects > /foo/special = objects created with certain #defines the regular ones > don't have. > > just doesn't hack it. Yes, I'm doing some things under MSDOS... On UNIX, the following should work. I'll base the example on the following directory structure (which I think is a little more common than the one above. proj |||| ------------------- || -------------- | -------||------ | | | | | bin include obj src Also, assume theat the makefile is in the 'src' directory. ---- # BASE == the root directory of the project BASE = .. SOURCE_DIR = $(BASE)/src INC_DIR = $(BASE)/include OBJ_DIR = $(BASE)/obj BIN_DIR = $(BASE)/bin PRODUCT = foobar CFLAGS = -c -I$(INC_DIR) LDFLAGS = -s SPEC_DEFS = -DJUNK=boffo OBJ_FILES = $(OBJ_DIR)/foo.o \ $(OBJ_DIR)/bar.o $(PRODUCT): $(OBJ_FILES) $(CC) $(LDFLAGS) -o $(PRODUCT) $(OBJ_FILES) $(OBJ_DIR)/foo.o: $(SRC_DIR)/foo.c $(INC_DIR)/hdr.h $(CC) $(CFLAGS) $(SRC_DIR)/bar.c $(OBJ_DIR)/bar.o: $(SRC_DIR)/bar.c $(INC_DIR)/hdr.h $(CC) $(CFLAGS) $(SPEC_DEFS) $(SRC_DIR)/bar.c ----- Whether or not these types of constructs work under MS-DOS depends on whose 'make' command you are using. I have one version of make that is almost totally compatible with unix make, and another that would not handle this at all. Note that the same techniques used above can be used with multiple source or object directories. If you need to be able to build multiple versions of a particular object with different #defines, try the following: $(OBJ_DIR_A)/foo.o: $(SRC_DIR)/foo.c $(INC_DIR)/hdr.h $(CC) $(CFLAGS) $(SPEC_DEFS_1) $(SRC_DIR)/bar.c $(OBJ_DIR_B)/foo.o: $(SRC_DIR)/foo.c $(INC_DIR)/hdr.h $(CC) $(CFLAGS) $(SPEC_DEFS_2) $(SRC_DIR)/bar.c $(PRODUCT_1): $(OBJ_FILES_1) $(CC) $(LDFLAGS) -o $(PRODUCT_1) $(OBJ_FILES_1) $(PRODUCT_2): $(OBJ_FILES_2) $(CC) $(LDFLAGS) -o $(PRODUCT_2) $(OBJ_FILES_2) Hope this helps. Let me kow if I confused you more than ever! Dave Wallis ihnp4!ihlpm!snafu AT&T Network Systems, Inc. (312) 510-6238 ----------------------------- From: Yasuki Izaki Subject: CSI Tape for 3B2/400 Date: 25 Sep 87 18:20:26 GMT Keywords: SCSI Tape To: info-unix@brl-sem.arpa Does anyone out there know about SCSI Tape Drive board from Feith Systems? They just announced this product a month ago(I think). We are considering purchasing it. We'd like to know how it works in terms of the performance. Any inputs will be appreciated. Thanks in advance. Yasuki Izaki Work : (415) 867-5073 Work UUCP: {ihnp4|ptsfa}!pbhyf!ysk -- Yasuki Izaki {ihnp4,pyramid,qantel}!ptsfa!pbhye!ysk (415) 867-5073 ----------------------------- From: Michelle Ruscetta Subject: question about signal Date: 25 Sep 87 02:54:19 GMT To: info-unix@brl-sem.arpa Question about signal(): Should the return from a signal handling routine specified by a call to signal() go to the instruction which caused the signal, or to the instruction immediately following that which caused the signal? For example: void (*p_my_handler)(); main() { extern void my_handler(); int y = 0; int x = 3; p_my_handler = my_handler: signal(SIGFPE, p_my_handler); x = x/y; /* should my_handler return to here? */ printf("return from signal\n"); /* or should my_handler return to here? */ } void my_handler() { signal(SIGFPE, SIG_IGN); /* do something useful */ signal(SIGFPE, p_my_handler); } --------------------------- I have run this example on two different machines, with different results; (both were running implementations of System V) one returned to the statement following that which cause the signal (the printf), and the other returned to the instruction which caused the signal -- hence throwing the program into an infinite loop continuously executing x/y and catching the floating point exception. I know it is not very good practice to return from signal-handlers but this question came up in a discussion and I would be interested to hear opinions as to which is the 'correct' way for signal to handle this. ----------------------------- From: Dave Decot Subject: Re: Re: Re: History (origin of foobar) Date: 25 Sep 87 04:41:33 GMT To: info-unix@brl-sem.arpa This is not related to UNIX. See mod.announce.newusers, including you oldusers who should know better. Dave ----------------------------- From: "Paul Sutcliffe Jr." Subject: Re: Invisible Ascii with VI Date: 28 Sep 87 04:03:36 GMT Keywords: vi To: info-unix@SEM.BRL.MIL In article <258@unx1.UUCP> andy@unx1.UUCP (Andy Clews) writes: > Specifically: I sometimes get files from a net source that have an "extra" > CR tacked on the end of the line, and VI shows them as ^M on the screen. > For various reasons these are a pain. I'd like to be able to get rid of > them with, say, a global substitute. I've tried 1,$s/^V^M$// but this > does not seem to do what I want. > I'd appreciate email replies if any. I thought this reply might be of general interest, so I'm posting it. Your "1,$s/^V^M$//" didn't work because the search pattern didn't match anything in your text file. You asked vi to find all lines where the character just before the end of line ($) was a carriage-return. This pattern will not match because the lines in your text were terminated by a CR/LF pair, so there was a line-feed between the "^M" and the "$". A better way to do this would have been "1,$s/^V^M//". This would replace all occurrances of ^M with nothing. You don't need an end-of-line indicator as there are (should be) no other ^M's in the text. - paul -- Paul Sutcliffe, Jr. UUCP (smart): paul@devon.UUCP UUCP (dumb): ...{rutgers,ihnp4,cbosgd}!bpa!vu-vlsi!devon!paul ----------------------------- From: Chris Torek Subject: Re: Invisible Ascii with VI Date: 28 Sep 87 13:31:47 GMT Keywords: vi To: info-unix@SEM.BRL.MIL In article <469@devon.UUCP> paul@devon.UUCP (Paul Sutcliffe Jr.) writes: >Your "1,$s/^V^M$//" didn't work because the search pattern didn't match >anything in your text file. You asked vi to find all lines where the >character just before the end of line ($) was a carriage-return. This >pattern will not match because the lines in your text were terminated >by a CR/LF pair, so there was a line-feed between the "^M" and the "$". Nope. A linefeed is a Unix newline; CR-LF pairs form a literal control-M followed by a newline. vi breaks a file apart at newlines (so as to create a series of lines), and, internally, does not carry around the newlines (linefeeds) at all. There is no line-feed between the ^M and the $-end-of-line, and in fact, typing the characters : % s / ^V ^M $ / / works fine for me. Of course, this could be a bug in other versions of vi. (At this very moment, I am running `Version 3.7, 6/7/85'---so says `:ver'.) (Going the *other* way---adding ^Ms---is another matter entirely.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris ----------------------------- From: Doug Gwyn Subject: Re: question about signal Date: 28 Sep 87 19:32:32 GMT To: info-unix@SEM.BRL.MIL In article <720001@hpclmar.HP.COM> mar@hpclmar.HP.COM (Michelle Ruscetta) writes: > Should the return from a signal handling routine specified by a call > to signal() go to the instruction which caused the signal, or to the > instruction immediately following that which caused the signal? If it's an asynchronous trap, it should complete the interrupted instruction sequence. If it's a synchronous trap (e.g. SIGFPE), there is no "right" answer. Presumably the synchronous exception occurred because some machine operation had invalid operands; unless you can be sure that the signal handler has fixed the operands (which is almost never the case, due to code optimization etc.), retrying the faulting instruction would just cause another trap. Portable, robust programs should not just return from a SIGFPE handler. ----------------------------- From: Peter Klosky Subject: Need getting Kermit or Xmodem going between SUNos and APPLE II Date: 25 Sep 87 20:17:02 GMT Keywords: kermit modem xmodem Sun Apple smartterm emulator To: info-unix@brl-sem.arpa We are trying to get an Apple II one of our people has at home to send files over the phone to our Sun network running 3.2 Sunos. We need to get kermit or xmodem going, we suppose. It does not look like the Sun comes with a communications protocol like xmodem or kermit; does anyone know if it perhaps hidden in some directory we've never seen or on some tape we have not read? We don't think we can get uucp g protocol going on the Apple. Has anyone heard of Smartterm, a Hayes product to run on the Apple? What protocols does it run? What would you suggest we do to get these two machines talking? To retransmit our request, let us say again we need retransmission in case of line noise. -- Peter Klosky, Citcom Systems (materiel de telecommunications) seismo!vrdxhq!baskin!citcom!peter (703) 689-2800 x 235 ----------------------------- End of INFO-UNIX Digest ***********************