stein (04/08/83)
#R:wjh12:-19400:fortune:11600012:000:237 fortune!stein Apr 7 18:35:00 1983 Setting your prompt in .login (but not in .cshrc) has the side effect of leaving the prompt unset if you invoke csh as an interactive subshell to your login shell. You would presumably want the prompt set in this case. Mark Stein
dan@haddock.UUCP (12/31/83)
#R:sri-arpa:-1461300:haddock:16800001:177600:466 haddock!dan Dec 30 14:17:00 1983 The problem with cxref is that it does not accurately find function definitions. The star gets put on the line number of the first declaration for the function that it finds, or nowhere at all! I was using it on PCC itself (an older version) and it was useless. Ctags -x works much better; out of the couple of hundred functions in pcc, it only omitted about ten. As far as I know there is NO program which will infallibly find function definitions in C source.
ARPA@sri-arpa.UUCP (02/12/84)
From: Jay Lepreau <Lepreau@UTAH-20.ARPA>
I looked into this awhile ago, and it appeared to me that as ex.recover
and preserve are written, making /usr/preserve 777 would open up a hole.
Those programs should work, at least in 4.2, with it 755 (they are
setuid). Have CCA emacs put its files somewhere else, say /usr/tmp.
No guarantees above is correct, I only took a quick look.
{hplabs,harpo}!utah-cs!lepreau
-------mather@uicsl.UUCP (02/18/84)
#R:sri-arpa:-1411400:uicsl:12500021:000:67 uicsl!mather Feb 17 10:14:00 1984 I'd like one too. Thanks. B.C.Mather uiucdcs!uicsl!mather
johnl@haddock.UUCP (03/15/84)
#R:heurikon:-24600:haddock:16800007:177600:548 haddock!johnl Mar 4 19:15:00 1984 If you read your manual, particularly the pages on mail, uucp, and uux, you'll see that multiple hop message forwarding is implemented by mail, not by uucp or uux. If you want to send stuff via a multihop path, either you disguise it as mail or use something like Berklix's uusend. System V put multiple hops into uucp itself with some strange restrictions, but since all intermediate sites need to run System V uucp also, this isn't likely to be of much help until System V becomes a lot more widely used than it is now. John Levine, ima!johnl
dan@haddock.UUCP (03/15/84)
#R:iedl02:-170200:haddock:16800008:177600:1709
haddock!dan Mar 12 21:58:00 1984
From: brian beattie <decvax!ucbvax!beattie@mitre-gateway.ARPA>
What about lines longer than the terminal width.
"stty line 80" may not work due to control chars.
unless you want "more" in the kernel with the reading
of /etc/termcap and all you will always end up with
either a partial solution or will be able to handle
only one type of terminal.
beattie@mitre
And what about whether a terminal wraps or not? I'll stick with the
traditional Unix definition of a line - a sequence of characters terminated
by a \n. Much more elegant. (And much better than systems like VMS or
TOPS-10 with their commands like SET TERM/VT100 !!!)
The kernel already looks at each character that goes out to your
terminal, in order to convert \n to \r\n and to expand tabs. The latter
means that it has to keep track of the current column, so it already "knows"
about the distinction between control characters and nonprinting characters.
The "traditional definition" of a line is not what tty.c uses.
Knowing whether the terminal wraps or not is a trivial thing compared to
all the options already in the terminal driver.
Everyone who thinks that kernel paging is a terrible idea because it
"doesn't belong in the kernel" should also, to be consistent, turn off
line editing too. After all, it's not much trouble to hit interrupt and
retype the line whenever you make a mistake, and line editing clearly
"doesn't belong in the terminal"--what's EMACS (or vi) for, anyway?
After you've used UNIX without kernel line editing for a while, you'll
understand how those of us who once used kernel paging, and can't anymore,
feel about "more". (More is less...)
Dan Franklinbarry@ism780.UUCP (04/10/84)
#R:uiucme:3100001:ism780:14400001:177600:1673 ism780!barry Apr 9 11:44:00 1984 Yes, when I worked for Sytek, L.A. I set up uucp which ran on their LocalNet setup. This included 6 machines locally (all Momentum Hawk 32's running v7 UNIX) and a connection from one of the Hawks to the VAX at Sytek's Mountain View site. Make sure that the "COMMAND" string at both ends of the connect is set to NONE and that FLOW is set compatibly at all FOUR points (BOTH ttys on each machine must be checked (uucico may be turning flow control on or off) AND each of the Sytek T-boxes must be set the same). Also make sure that your stty settings for erase and kill at each port are not '#' and '@' -- this might cause you to lose characters. I would advise you to start at 300 baud on the sending end and 300 or 1200 baud at the receiving end and turn off flow control all together -- the Sytek hardware will adjust the baud rates, and removing the flow control all together simplifies the situation. Because of problems with our UUCP software, I ended up having to run uucp at our site without flow control at 1200 baud. This worked fine; I didn't test it too much at higher speeds without flow control. By the way, the problems I had with bringing up UUCP had very little to do with the Sytek hardware, which I believe is a very good product. You just have to make sure that the connection is transparent which can be done by setting COMMAND to NONE and FLOW to appropriate values for your connection. I believe that there is one other setting which may be relevant (i.e. may interpret characters being passed through), but I don't remember what it is and I don't have a Sytek booklet at hand. Good Luck (with uucp you generally need it!) -- Barry Holroyd
avak@inmet.UUCP (05/19/84)
I worked on the 1620, which would tell you how it was doing by placing an AM radio on top... No need for wires, since the current switching in the core memory gerenated enough RF noise. NOP was 180 microseconds, so a FORTRAN do loop with one SIN computation was very slow: blink blink on the lights, and click click on the radio. As for RF noise, if you programmed timed loops, you could generate music.
avak@inmet.UUCP (05/20/84)
I could not reply directly, but I hope you get this anyway. A Z80 cross-assembler and associated tools (linker, librarian, locator, formatter, etc.) is available now from Intermetrics. A C cross compiler for the Z80 will be available soon. All tools are available on VAX/UNIX, VAX/VMS, and Apollo workstations. Contact: Deborah Sears Software Products Division Intermetrics, Inc. 733 Concord Ave. Cambridge, MA 02138 (617) 661 0072 P.S. C and Pascal are available for 8086 and 68000 processors.
james@inmet.UUCP (06/05/84)
#R:sri-arpa:-69600:inmet:10300019:177600:1062
inmet!james Jun 3 23:09:00 1984
Re: flashing lights.
This is one of my pet peeves. It seems someone somewhere high in the
computer marketing cartel subscribed to by all manufacturers decided
that flashing lights are bad for us. Why????? The only reason I can
think of to eliminate them is cost, but how much would it add to the
cost of our IBM 3083 or VAX 780 to add a panel of lights- it would be
trivial. With LED's nowadays you don't even incure any maintenance
cost. Balance this with three important benefits:
1- It gives us techies the usually illusory feeling we know
what the computer is doing.
2- It gives the corporate types who actually pay the bills
something to show visiting firemen and relatives on the
obligatory tour of the computer room. I always feel a
little embarassed when I show the President a large grey
freezer chest, and say: "Yup, that's what we just spent
X million dollars on."
3- Occasionly they actually really help debug flaky systems.
james triplett (...ima!inmet!james)henry@utzoo.UUCP (Henry Spencer) (06/10/84)
James Triplett asks why no flashing lights, commenting:
.............................................. The only reason I can
think of to eliminate them is cost, but how much would it add to the
cost of our IBM 3083 or VAX 780 to add a panel of lights- it would be
trivial. With LED's nowadays you don't even incure any maintenance
cost. ....
It's the usual sort of reason: they get little use and cost a fair bit.
The cost is not a matter of the LEDs themselves, but of the mounting
hardware to hold them, and the effects this has on cabinet design. You
would be *amazed* at the cost of bent sheet metal these days, when one
is talking about total production costs. Most manufacturers take the
view that it's better to add a bit of cheap electronics (a console
monitor program) than a bunch of expensive hardware.
Don't get me wrong -- I miss the lights and switches too. But I don't
expect them back.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrydonn@hp-dcd.UUCP (06/16/84)
Nf-From: hp-dcd!donn Jun 12 15:22:00 1984 I suggest that it is wise to take AT&T's documentation, or the fact that something is not documented, with a grain of salt; there is probably no clear rule to follow as to whether the error is in the code, documentation or the feature is "not ready yet". I've found a lot of errors in both undocumented features and documented non-features. Granted, if it's not documented, one should be more skeptical. The following example is the kind of thing that makes me nervous about trusting the documentation without confirming the details. A comparison of the semop(2) manual pages for System V Release 1 (a.k.a. 5.0) and Release 2: V.1: Semop is used to atomically perform an array of semaphore operations... V.2: Semop is uset to automatically perform an array of semaphore operations... I sincerely hope that the Release 1 version is correct, and some how the change crept into the manual on its own. Donn Terry Hewlett-Packard
ron@BRL-TGR.ARPA (06/17/84)
From: Ron Natalie <ron@BRL-TGR.ARPA> Actually, I think the computer manufacturers have had tghe desire to make things seem simpler by putting as few things as possible on the front of the CPUs. IBM did it, Sperry did it, most micros have done it. The idea is that they are not needed and they tend to intimidate non-hackers. DEC has been making their computers look more IBMish lately so they went that way too. -Ron
bob@hwcs.UUCP (Bob Gray) (06/20/84)
> This is one of my pet peeves. It seems someone somewhere high in the > computer marketing cartel subscribed to by all manufacturers decided > that flashing lights are bad for us. Why????? I agree. Two of our machines here have little LEDs on their CPU boards. The first thing I do if one of them dies is to open the front of the machine and see is going on. Very useful when running in single user mode and you are not getting any replies from the console. Another of our machines has a number of lights on the front which report disk activity. You can tell what stage of the boot procedure it is at (before anything appears on the console) by the pattern of the lights. If something goes wrong it saves a lot of time knowing at what stage it went wrong. Bob Gray. Dept. of Computer Science. Heriot-Watt University.
dmmartindale@watcgl.UUCP (Dave Martindale) (06/20/84)
Not having flashing lights on machines makes them boring to look at. This is good, because then you can tell the visitors that there isn't anything to look at in the machine room and there is no point in them going in. This is good, in turn, because you won't get people leaning against your disk drives and spinning them down. (It HAS happened to me. Non-technical visitors are now banned from the machine room on tours.)
jcp@BRL-TGR.ARPA (09/19/84)
From: Joe Pistritto <jcp@BRL-TGR.ARPA> The Heath Device uses 5 and 10 Mhz WWV signals. I have heard it does not have much sensitivity and doesn't work well at all inside buildings. -JCP-
grim@UDEL-EE.ARPA (09/19/84)
From: Dan Grim <grim@UDEL-EE.ARPA> My Heathkit catalog says "An RF receiver scans the 5, 10 and 15 MHz frequencies of WWV and locks onto the strongest signal" Also "Propagation delay can be set for up to 18.75 milliseconds (3600 miles from WWV)." The model number is GC-1000, and costs 249.95 for the kit. The RS-232C accessory is a GCA-1000-1 for 49.95.
henry@utzoo.UUCP (Henry Spencer) (09/27/84)
> The Heath device uses 5 and 10 Mhz WWV signals. I have heard it does > not have much sensitivity and doesn't work well at all inside buildings. 5, 10, and 15 MHz, actually. We got one a little while ago, and so far have had mixed results with it. Reception is somewhat a function of position within the building; experimentation is in order. We've never tried it deep within the building, since our building is long and skinny with essentially no windowless rooms. I'll post a more detailed report later, when we've evaluated it more thoroughly. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
guest2@smu.UUCP (12/01/84)
/* ---------- "Reading PC-DOS diskettes" ---------- */
I would like to read some text files from an IBM-PC diskette onto my
Honeywell microSystem NX. It is a 68000 workstation running the
...
We use KERMIT as a way of transfer. There are good kermits availlable
for most of the stand OSystems. Look for the public domain software
or look in one of the news net bulletin about kermit. In any case
you can reach me at
{..convex!smu!gertjan}
gertjan vinkesteymn
summer institute of linguistics
7500 W Camp Wisdom Rd
Dallas Tx 75236 tel 214:298-3331gertjan@txsil.UUCP (12/08/84)
It works fine for us at 18 bits, so 22 bits should not be a problem.
What gave me real problems was:
The GENERIC unix comes with RL02 but the 'swplo' and 'nswap'
is for the RL01. So look in the /genallsys.sh file
to 'adb' in the unix system.
# The following script can be of use:
adb -w /unix <<end-of-script
swplo?W 17000
nswap?w 3480
end-of-script
# end don't forget to do the same trick with /rlunix
adb -w /rlunix <<end-of-script
X?W 17000
Y?w 3480
end-of-script
# where X and Y are the numbers you found in 'adb -w /unix'
: gertjan vinkesteyn, SIL DALLAS
..{allegra,ctvax,ihnp4,rice,uiucds,unmvax}!convex!smu!txsil!gertjangertjan@txsil.UUCP (12/10/84)
sorry my adress was mentioned wrong.Here it is again:
: gertjan vinkesteyn, SIL DALLAS
..{allegra,ctvax,ihnp4,rice,uiucds,unmvax}!convex!smu!txsil!gertjanmatthew@imd.UUCP (01/20/85)
A reference: M.S. Hecht, J.R. Levine, and J.C. Walker, "A Distributed File System (DFS) for UNIX," January 1984 UNIFORUM Conference in Washington, D.C.
dan@haddock.UUCP (03/16/85)
As I understand it, the Newcastle Connection requires no kernel mods, merely recompilation (relinking, actually) of all commands and programs that you want to be able to go over the net.
ron@brl-tgr.UUCP (ron) (03/29/85)
It's JOHNSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSZZZZZZZZZZZZZZZZZZZZZZZZZZZZ Hopkins. -Ron
ron@brl-tgr.UUCP (ron) (03/29/85)
They are not Pseudotty's in the Berkeley sense. A Berkeley PTY has two sides, the side that looks like a tty to an application, and the control side which is connected to your communications program like telnetd or mpx or whatever. The System V SXT devices multiplex multiple "TTY devices" into a single channel going to a terminal. You can't divert the backend to a program, it always goes to the terminal that did the LINK ioctl to pick up the group of pty's. -Ron
rml@hpfcls.UUCP (rml) (05/16/85)
> Subject: Re: Setting environment variables within a C program. > > I don't know the "right" way, but one way is to copy the environ array > pointers into a new array and make your change. The reason you have to > use a new array is in case the change you are making adds a variable to > the environment. If you are only resetting a variable, you just > reassign that one pointer to the variable value. The reason this is > kludgey, of course, is that the space from the original environ becomes > unusable garbage. That is, I haven't the faintest idea how to return > it (i.e. free) to useful life. Why is it a problem to copy the original array? You only need to copy the pointers (not the environment strings themsleves). Even with a hundred 4-byte pointers, this wastes all of 404 bytes (with the null terminator). The problem becomes even less significant when the environment is being modified in preparation for a call to exec(2). In answer to your question, I don't know of a general-purpose, portable way to either avoid the copy or re-use the space. One non-general-purpose way would be in a case where the program was able to find an entry in the original environment which it knew to be useless; it could replace that pointer with one to the new entry. Bob lenk (hpfcla!rml)
rml@hpfcls.UUCP (rml) (05/18/85)
> I am having trouble in writing a routine to handle less than > one second sleeps on BSD 4.2 using setitimer and sigpause. The routine > I am using is similar to the code for sleep(). My problem, it keeps > hanging sfter a random number of calls. It seems that eventually it > does not return from sigpause. Why? What can I do about it? The problem is that while the routine is using sigpause (instead of pause), it never masks out the SIGALRM signal, so it is subject to the standard window of standard UN*X signals. Specifically the signal can occur here. V while(wakeup == 0) sigpause(0); Donn Seeley's posting in net.sources illustrates the use of sigblock to eliminate this window. From a quick look at the 4.2 source it has the same problem as your routine (it does use sigblock, but not to solve this problem). I agree with Doug Gwyn that select provides the most efficient short-term sleep. Bob Lenk {hplabs, ihnp4}!hpfcla!rml
matt@prism.UUCP (06/20/85)
/**** prism:net.unix-wizar / turtlevax!ken / 7:46 pm Jun 10, 1985 ****/ In article <340@cmu-cs-edu1.ARPA> hua@cmu-cs-edu1.ARPA (Ernest Hua) writes: >Does anyone have any idea how to truncate a file at the current point in >writing if it is opened by open()? I cannot use creat() because the file >is being used by another process, and I cannot use unlink() it is likely >that it is linked. If the updated contents is longer than the original, >it is not a problem because the file length is just extended. But if the >updated contents is shorter, the file does not shrink. We have 4.1BSD on >several 780's and 750's. try size = lseek(fd, 0L, 1); /* tell(fd) */ ftruncate(fd, size); /* int fd, size; */ It's yet another undocumented feature on 4.2. /* ---------- */ Ah, but if you look carefully, you'll see that the original poster (Ernest Hua) states very clearly that he's using 4.1, NOT 4.2 BSD. If I recall correctly, there's no equivilent of truncate() or ftruncate() in 4.1. [By the way, both of these functions are perfectly well documented in our copy of 4.2 - why not in yours?] ----------------------------------------------------------------------------- Matt Landau {cca, datacube, ihnp4, inmet, mit-eddie, wjh12}... Mirror Systems, Inc. ...mirror!prism!matt -----------------------------------------------------------------------------
gm@trsvax.UUCP (07/09/85)
If you want the directories to be all be 777 or 755, you could
always use find. As in:
find /directory -type d -print -exec chmod 755 {} \;
That may or may not help you with your problem. It sure would beat having to
do each directory by hand.
------------------------------------------------------------------------------
Number 4: The Larch.
Number 40: The Naughty Bits.
Number 4000: The Setuid Bit.
------------
George Moore (gm@trsvax.UUCP)shaddock@rti-sel.UUCP (07/09/85)
In article <11405@brl-tgr.ARPA> lauren@rand-unix.ARPA writes: >Luckily, that scenario doesn't happen very often, since many (but not all) >of the responders are smart enough to send only one copy of the > .... The "answering machine" program that I've seen keeps track of who it has replied to, and only replies to each person once. This would be a partial solution for mailing lists, although the first time an article came through everybody on the list would get bombarded. -- Mike Shaddock {decvax,seismo}!mcnc!rti-sel!shaddock
whp@cbnap.UUCP (07/09/85)
Modifying pr (on sys VR2 anyway) is not reasonable! This program is so buggy, convoluted, and bizzare that the only reasonable thing to do is to rewrite it from scratch! I tried to fix a bug once, the -w option doesn't work unless you have more than two columns; simply removing the test for number of columns caused pr to stop printing the first line of random pages! (this fix was given to me by UNIX support people, and even they gave up on pr!)
aeb@mcvax.UUCP (07/10/85)
In article <112@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >Um, I think errno is specified to be valid only if putchar returns the >constant EOF. Thus, the code should be: > > if (putchar ('\n') == EOF) > perror ("putchar"); > Unfortunately, this is not true. errno is set by system calls, but not by the stdio library routines. Thus, when a stdio library routine fails it may be that errno contains useful information (in case the failure was due to a system call error return), but it may also be that errno contains garbage (in case the library routine detected the error itself). Thus, fopen can fail when all _iob entries are taken; putc can fail when writing to a stream that has not been opened for writing, etc. This means that you cannot reliably use the stdio routines when you want to do error recovery. Example: #include <stdio.h> main(){ putchar('\n'); /* sets errno via isatty() */ fclose(stdout); /* make next putchar fail */ if(putchar('\n') == EOF) perror("putchar"); /* produce garbage */ } Again, the call a.out > /dev/null will produce putchar: no such device, and a.out | ... produces putchar: operation not supported on socket.
avolio@decuac.UUCP (07/10/85)
Swapon wants/needs block devices for arguments. (IE, Don't use the raw device.) The "funny" error message is due to a missing argument in a printf. (Something bad like "printf (%s : %s\n", arg1);") Also, if the device is currently being used for swapping, you get the same error message. -Fred
phil@brl-tgr.UUCP (07/11/85)
>> I am looking for a good way to generate the full path name of a directory, >> given only its inode number (plus the device number of its filesystem). >> The 'obvious' solution is ... (this is effectively what "ncheck" does). > > Not only is it the obvious solution, it's the only solution. No version of > UNIX currently in existence or coming out in the near future (nor, I > suspect, any version you're likely to see) makes it any easier. I disagree! If it were possible to set the current working directory to a given inode and device, then pwd would give you the answer. All the permission information, and even the bit denoting whether or not this inode refers to a directory is stored in the inode, and can easily be checked in such a call. Putting such a call in would be easy. Just do what "chdir" (well, actually "chdirec" in 4.2) does after it calls "nami". Why is this hard? Now, what would be hard would be generating the full path name for an arbitrary file given just the inode and device. The only program that can do that is find, and I strongly suspect that that will never change in the near or far future. Doing so would violate one of the founding principles of the Unix file system. But with a directory, you know that (save symbolic links) there is one unique path name for that directory. William LeFebvre Department of Computer Science Rice University <phil@Rice.arpa> or, for the daring: <phil@Rice.edu>
jad@hpfcla.UUCP (jad) (07/31/85)
> /***** hpfclo:net.unix-wizar / im4u!jsq / 9:27 pm Jul 24, 1985*/ > > Though other companies are working on multiprocessor systems of the > same general type as the Balance 8000 (i.e., multiprocessors with > memory shared among all processors, not dual processors or networked > single processors), Sequent appears to be the only one with an actual > product so far. I speak to you today from an HP 9000 Series 500, with 3 CPUs, 6 Meg of RAM, and 3 IOPs ... it is a heterogeneous multi- processor with shared memory and semaphores, and has been on the market for a couple of years now. The OS is Bell SysV (with Berkeley enhancements), and is what I'd call "an actual product" (even though it's not pure 4.2BSD! ;-) -- jad -- John A. Dilley, ARPA: terrapin@Purdue.EDU UUCP: {ihnp4}! hpfcla!jad PHONE: (303)226-3800 x4166
jad@hpfcla.UUCP (jad) (08/03/85)
> /***** hpfclo:net.unix-wizar / jad / 5:00 pm Jul 30, 1985*/ > > ... it is a heterogeneous multiprocessor with shared memory and ... ^^^^^^^^^^^^^^^ Yiiii! Make that homogeneous. Slip of the mind there. All the processors are identical, except of course the IOPs. Soooooory! -- jad -- John A. Dilley, ARPA: terrapin@Purdue.EDU UUCP: {ihnp4}! hpfcla!jad PHONE: (303)226-3800 x4166
jad@hpfcla.UUCP (jad) (08/03/85)
> /***** hpfclo:net.unix-wizards / microsoft!gordonl / 7:20 pm Jul 28, 1985*/ > I've just discovered what appears to be a "day 1" bug in fgrep. Its > present in our V7, SYS III, and SYS 5 sources, so its probably present > in all fgrep sources out there. I tried the bug on the Boyer-Moore fgrep (called bm) posted to net.sources recently; the Boyer-Moore algorithm correctly handles this case. In case anyone cares ... -- jad --
pavlov@hscfvax.UUCP (840033@G.Pavlov) (08/06/85)
Re: multiprocessor HP9000 :
Here ! Here ! (hear, hear ??)
But it's not Sys V (yet).
... and this is the wrong place for this, I know. But it's a very nice
machine.
greg pavlov, FSTRF, Amherst, N.Y.berger@datacube (09/07/85)
Don't know how good the Green Hills Compiler is but you can get it
from the Cambridge, Mass firm of Oasys 617-491-4180. They sell all
sorts of software tools. Green Hills phone number is: 818-796-6543
and they are in Pasadena, Ca.
They both have ads in the latest Unix Review.
Bob Berger
Datacube Inc. 4 Dearborn Rd. Peabody, Ma 01960 617-535-6644
ihnp4!datacube!berger
ima!inmet!mirror!datacube!berger
decvax!cca!mirror!datacube!berger
decvax!genrad!wjh12!mirror!datacube!berger
{mit-eddie,cyb0vax}!mirror!datacube!bergerrs@mirror.UUCP (10/14/85)
>Sun Microsystems gets their LaserWriter from Apple, and they provide an >interface kit which has filters for troff, ditroff, Diablo, and plot(5) >output. If you already have a LaserWriter, you can get it separately, >but they charge $1800. The same(?) functionality is available from Adobe (415-852-0271) for about one-third that for binary. It is wonderful. -- Rich $alz {mit-eddie, ihnp4!inmet, wjh12, cca, datacube} !mirror!rs Mirror Systems 2067 Massachusetts Ave. 617-661-0777 Cambridge, MA, 02140
tim@ISM780B.UUCP (10/29/85)
/* Written 7:23 pm Oct 26, 1985 by guy@sun in net.unix-wizar */ don't think Motorola tells you 1) that it won't kill the system if you RTE with arbitrary bits or 2) how to make sure that a bus error frame is safe. /* End of text from net.unix-wizar */ If you want to see _wierd_ behaviour from a 68010, try changing the PC in a bus error stack frame. We had a case like this in the Callan Unistar 312 ( 68012 based box, running a system V pageing system ). We wanted to deliver a signal that a user was wanting to trap, but we also want to rerun an instruction, since the reason we are in kernel mode is that we have just finished a page fault. By experiment it was found that the 68012 is totally shpxrq(rot 13) by this. We got around this with the trace bit. Tim Smith ihnp4!cithep!tim ihnp4!ima!ism780!ism780b!tim <- or something like that!
lee@haddock.UUCP (11/01/85)
I have some rather large data files stored on disk in compacted form.
I use ccat and a pipe to feed the data file to a plotting program.
This fortran program accepts the uncompacted data from standard input
via an unformatted read statement and plots it; it exits from the
plotting loop when an EOF condition is detected. At this point I
want the program to accept input from the keyboard; however, it
continues to read from the pipe. Do you have any advice on how I
can redirect the input once the EOF is reached? Thanks for your support.
If you do not have access to the source of the Fortran program, the following
would work on SystemV:
ccat packedfile | cat - /dev/tty | fortranprogram
Cat, yes it can be used for something other than printing files! :-)ajs@hpfcla.UUCP (01/21/86)
> ...is any reliable [way] for the parent to tell if the exec() in the forked > child succeeded or failed. Problem: A parent process forks a child process which does a variety of environment setups, then execs another program which runs for an indefinite time (e.g. a shell). The parent needs to return zero if all goes well (just through the exec), or non-zero if any error occurs (including failure to exec the other program). How can it tell? Solution: Parent opens a pipe before forking, and uses fcntl(2) to set the F_SETFD (close-on-exec) flag for the write end. After forking, parent closes the write-end (parent is a reader), and child closes the read-end (child is writer). Parent reads from the pipe, which blocks. Child writes a message to the pipe and exits if any error occurs, including exec failure. Parent gets back either zero bytes (exec succeeded) or one or more bytes of error information. This has the advantage of also being a form of synchronous wait-for-exec. (Note, this does NOT detect exec failure AFTER the kernel closes the pipe. You can't have EVERYTHING.) Alan Silverstein, Hewlett-Packard Fort Collins Systems Division, Colorado {ihnp4 | hplabs}!hpfcla!ajs, 303-226-3800 x3053, N 40 31'31" W 105 00'43"
jad@hpcnoe.UUCP (03/05/86)
> /***** hpcnoe:net.unix-wizar / sun!tut / 5:04 pm Feb 24, 1986*/ > Let's not lose perspective by emphasizing differences between 4 BSD > and System V. The two UNIX variants are at least 95% similar. It's > not overly difficult to write software that will run on both (the more > complicated the software, the harder it is, though). I beg to differ. Considering UNIX system calls, 50% of Berkeley's are unique to them; 23% of the SystemV syscalls (of which there are far fewer: 71 vs BSD's 121) are unique to System V. Of the C library calls supplied by System V and 4.2BSD, only 61% are even compatible. And approximately 50% of the commands in each UNIX system are unique. [1] Sure they're both UNIX, and I agree that a lot of the good stuff hasn't changed much (they both have IO redirection and pipes, a major niceness, and the ability to write shell scripts and C programs). But you can't ignore differences like the absence of csh(1), or the absense of shared memory and semaphores (both have their advantages, I admit). I too am a regular user of 4.2BSD, System V, and HP-UX, and agree that the transition is not too difficult. But I maintain that there are differences major enough to make switching undesirable, especially with respect to kernel and network specific tasks. -- jad -- John A Dilley Hewlett Packard Co. Colorado Networks Division Fort Collins, Colorado AT&T: (303)229-2787 UUCP: {hpfcla,hplabs} !hpcnoe!jad [1] "UNIX System V and BSD4.2 Compatibility Study", March 1985, Joseph Uniejewski, Apollo Computer Inc. * UNIX (and System V) are trademarks of AT&T Bell Labs (I think) * HP-UX is a trademark of Hewlett-Packard, Co.
ron@BRL.ARPA (Ron Natalie) (03/09/86)
I would like to see the compatibility study redone if you remove NETWORKING from 4.2 and remove all the non-portable stuff from System V. Shared Memory is not portable, nor is it required by the SVID. Semaphores might be useful, but not as implemented, they need to be fixed so they work. If you did a comparison of the system calls/programs/etc... as a function of the sameness biased by how frequently they were used, you'd probably find the 95% value more correct. -Ron
john@wvlpdp (04/10/86)
No doubt part of the problem of incompatible structures is due to the fact that int's on PDP'11 are 16 bits and 32 bits on VAXes. If you have no need for a int to be greater than 32767 then use short. John A. Ebersold World Video Library (not a video store) ihnp4!convex!ctvax!trsvax!doc!wvlpdp!john 2747 Airport Freeway Fort Worth, Texas 76111
john@wvlpdp (04/10/86)
Contact: Catalytix Corp 55 Wheeler Street Cambridge MA 02138 617-497-2160 I saw their stuff demonstrated at the Dallas Uniforum; looked very good but unfortunatly it would not port well to a PDP 11/73
daemon@houligan.UUCP (05/06/86)
-=[ I love my little pet lineater. I feed it twice hourly. ]=- > From: john@wvlpdp.UUCP > Newsgroups: net.unix-wizards > Subject: Re: Orphaned Response > Nf-ID: #R:cirl.UUCP:258:wvlpdp:6300003:37777777600:369 > Nf-From: wvlpdp!john Apr 10 09:34:00 1986 > > No doubt part of the problem of incompatible structures is due > to the fact that int's on PDP'11 are 16 bits and 32 bits on VAXes. > > If you have no need for a int to be greater than 32767 then > use short. ....and be sure to cast/mask appropriately when calling "printf". For an example of the symptoms caused by failure to do this, see the field "Nf-ID" in the header of the enclosed letter (above). Somebody in the mailer world missed... > John A. Ebersold World Video Library > (not a video store) > ihnp4!convex!ctvax!trsvax!doc!wvlpdp!john 2747 Airport Freeway "But, Jim, I'm a Programmer, not an Exterminator!" {ccvaxa,pur-ee,ucbvax!sun}!gould!cstrickland (Craig Strickland @ Gould) +1 305 587-2900 x5014 CIS: 76545,1007 Source: BDQ615 MCIMail: 272-3350 This message contains no user-serviceable parts. Refer all servicing to qualified personnel. Disclaimer: The opinions expressed and information presented herein are solely those of the author, and do not necessarily represent the views of my employer.