Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!mcnc!rti-sel!dg_rtp!goudreau From: goudreau@dg_rtp.UUCP (Bob Goudreau) Newsgroups: comp.unix.questions Subject: Re: A couple questions Message-ID: <1752@dg_rtp.UUCP> Date: Wed, 22-Apr-87 17:56:23 EST Article-I.D.: dg_rtp.1752 Posted: Wed Apr 22 17:56:23 1987 Date-Received: Fri, 24-Apr-87 05:30:16 EST References: <3164@jade.BERKELEY.EDU> <2382@ncoast.UUCP> Reply-To: goudreau@dg_rtp.UUCP (Bob Goudreau) Organization: Data General, RTP North Carolina Lines: 82 In article <2382@ncoast.UUCP> robertd@ncoast.UUCP (Rob DeMarco) writes: >In article <3164@jade.BERKELEY.EDU> marcp@beryl.berkeley.edu (Marc M. Pack) writes: >>Hello! I've a couple of questions in UNIX 4.2. >> >>1. How do programs like "more" distinguish between text files and >> executable files? Hopefully, there's something surer than >> just taking a sample of a file and testing it. (This question >> came up when a bunch of people started accidentally sending >> executables to a line printer, and I was trying to figure >> out a way to filter out the execs from the texts). > > I would believe that a pretty sure >method would be to test the file >permisions, if an "x" accours in the >file permisions, then it is executable, >other wise its text. > This isn't such a good idea, for three reasons: 1) Shell scripts are executable files, but they are also printable ASCII files. It might make some of your users a little mad to find some print jobs refused. 2) On the other side of the coin, there exist files which are not executable and which are also unprintable; a common example is any ".o" file. 3) Finally, pr can accept redirected input. How is it supposed to do a stat() on stdin? A better filter would be a program that looks for indications that the file is an object or a.out (program) file. This is in fact what more does; it checks for for a "magic number" at the beginning of a file indicating that the file is a program or object file. >>2. Is it possible to, while in a C program, call another program and >> put it into the background? Actually, I know it's possible, >> 'cause I can do it with a line like: >> >> system("cat textfile &"); >> >> This won't work, however, if I try to "more" the file instead. >> What determines what can be put in the background and what can't? > > My guess is that more accepts input, >since you have to press to go >on. Since it is in background, it >doesn't wait for it to complete before >going on, therefor , getting input is >imposible, because it doesn't check for >input. This is along the right lines, but not correct. Consider the following program: main() { system ("more /etc/termcap &"); for (;;) ; } This will work, (try it) because only one process (the more) is trying to read its stdin. (The system() does a fork() and the child process inherits identical copies of its parent's file descriptors, including stdin). The place where you will run into trouble is when your main program is also trying to read stdin at the same time; the two processes will fight over the input. The same is true of stdout and stderr -- you will get jumbled-together output. The moral is, Be careful of what child processes do with file descriptors inherited from the parent. If the child is going to open its own files, go right ahead and use system(foo &) to put it in the background. You may want to become familiar with the fork() system call, since it allows you to bypass some of the overhead of the system() lib function. -- Bob Goudreau Data General Corp. 62 Alexander Drive Research Triangle Park, NC 27709 (919) 248-6231 ...!mcnc!rti-sel!dg_rtp!goudreau