Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!samsung!sdd.hp.com!wuarchive!psuvax1!news From: schwartz@groucho.cs.psu.edu (Scott Schwartz) Newsgroups: comp.os.misc Subject: Re: Globbing Message-ID: Date: 2 Apr 91 05:59:28 GMT References: <44381@cos.com> <44431@cos.com> <=baGj#dc1@cs.psu.edu> <44480@cos.com> Sender: news@cs.psu.edu (Usenet) Organization: PSU CS Lines: 34 In-Reply-To: fetter@cos.com's message of 1 Apr 91 18:25:41 GMT Nntp-Posting-Host: groucho.cs.psu.edu In article <44480@cos.com> fetter@cos.com (Bob Fetter) writes: | What was Primos doing? ... Am I on the right track with what was | happening with Primos that was upsetting you? Yes, although I should clarify that Primos' command processor doesn't do redirection itself. I was doing that by hand inside each command. So each time the command ran it truncated the earlier output. Arguably that was simply a bug. One fix would arrange to write in append mode, but that's ugly in the cases when you do want to overwrite. Fixing the shell to do the redirection and keep the files open between iterations might have worked, assuming I'd had sources and was allowed to do anything with them. :-) Under Unix, of course, the whole thing is much easier. | Are there other things (good/bad) from that environment worthy of | discussion? More than I can count. :-) One nasty thing was that io to ttys was different than to files. (Different system calls, from what I remember.) That made the whole redirection idea much stickier. Multics, apparently, had some way to do redirection ("utterly trivial", cf DMR, 1984), so it might actually have been possible in Primos. But any details of such things were safely hidden from anyone who would be interesting in knowing about them. A nicer thing was that (in some cases) you could mark executables so that globbing/command iteration would not be done on them. -- sparc ld: triple word score