rkumar@buddha.usc.edu (Anon) (11/27/89)
Here are some questions related to file management under UNIX. 1) dir-a and dir-b are two directories. Both may have files with same names. How does one move the latest versions of the files from dir-b to dir-a? In other words, I want foreach file f in dir-b do if (f does not exist in dir-a) then copy f from dir-b to dir-a else /* let f-a be the corresponding copy in dir-a */ if (f is more recent than f-a) move f from dir-b to dir-a endfor 2) Suppose that a text file f is being included (e.g., #include) in more than one source. What is, if there is, a mechanism to protect file f from being accidentally deleted/modified? Preferably, rm, mv, etc should be able to detect if f is being used in some other file. The user may be expected to explicitly state that f is being used in source s when s is created. Please e-mail your responses, and I will post a summary next week. Thanks, Ravi ......................................... . The Hanu-man Logo which is `'\`' (wtlifter@hanuman.edu) now selling like hot turkey :-> _/ \_
cpcahil@virtech.uucp (Conor P. Cahill) (11/27/89)
In article <21408@usc.edu>, rkumar@buddha.usc.edu (Anon) writes: > Here are some questions related to file management under UNIX. > > 1) dir-a and dir-b are two directories. Both may have files > with same names. How does one move the latest versions > of the files from dir-b to dir-a? In other words, I > want Using cpio: cd dir-b find . -print | cpio -pdv dir-a > 2) Suppose that a text file f is being included (e.g., #include) > in more than one source. What is, if there is, a mechanism to > protect file f from being accidentally deleted/modified? > Preferably, rm, mv, etc should be able to detect > if f is being used in some other file. The user may > be expected to explicitly state that f is being used > in source s when s is created. The easiest way to do this (if you really want to) is to create a hard link to the file in each directory that you wish to use it. This way you can remove it from whatever directory you want to and it will still be available where ever else it was linked to. If you require this kind of operation in the same directory, then look before you remove. (of course you could link the file to different entries in the same directory and have different source files include different include files). The best solution would be to have a separate include directory wherein this file is placed and never removed (similar to /usr/include). -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
rice@dg-rtp.dg.com (Brian Rice) (11/29/89)
In article <1989Nov27.114301.2440@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: >In article <21408@usc.edu>, rkumar@buddha.usc.edu (Anon) writes: >> 2) Suppose that a text file f is being included (e.g., #include) >> in more than one source. What is, if there is, a mechanism to >> protect file f from being accidentally deleted/modified? >The best solution would be to have a separate include directory wherein >this file is placed and never removed (similar to /usr/include). The -I flag to the C compiler can help; it specifies a directory to look for include files. This means that if you had an include file called wilbur.h, you could put it in your own personal include directory, say, /usr/users/rkumar/include. Then your source code would just have #include "wilbur.h" and your makefile would contain lines like cc -c kludge.c -I/usr/users/rkumar/include I think that this solution is the one with the greatest long-term payoff. The trouble with links is that they hide information in an undesirable way. If joe/a.h and jane/a.h are links to the same file, the only ways a naive observer has of knowing that changes to joe/a.h will appear in jane/a.h are (1) making such a change and encountering the possibly unwanted consequences, or (2) having a paranoid outlook and the ls -il command. In a software engineering project, a safer practice is to have only one name for the header file and to document various modules' dependencies on it in a makefile, as above. Brian Rice rice@dg-rtp.dg.com (919) 248-6328 DG/UX Product Assurance Engineering Data General Corp., Research Triangle Park, N.C. "My other car is an AViiON."
rkumar@buddha.usc.edu (CPR) (12/02/89)
In article <21408@usc.edu> rkumar@buddha.usc.edu, that is me, C.P. Ravikumar, raised some simple questions. I am posting the responses which I got. This is very long, so it may be a good idea to print it and read it. >Here are some questions related to file management under UNIX. > >1) dir-a and dir-b are two directories. Both may have files > with same names. How does one move the latest versions > of the files from dir-b to dir-a? In other words, I > want > > foreach file f in dir-b do > if (f does not exist in dir-a) then > copy f from dir-b to dir-a > else > /* let f-a be the corresponding copy in dir-a */ > if (f is more recent than f-a) > move f from dir-b to dir-a > endfor > >2) Suppose that a text file f is being included (e.g., #include) > in more than one source. What is, if there is, a mechanism to > protect file f from being accidentally deleted/modified? > Preferably, rm, mv, etc should be able to detect > if f is being used in some other file. The user may > be expected to explicitly state that f is being used > in source s when s is created. > > ------------------------------------------------------------------ akhale@jerico.usc.edu writes ... If you have a huge project with files being shared by several people then you can use a version system. SCCS and RCS come to mind and you can use makefiles to indicate dependencies. These are stored in separate files, so if the source files are deleted, they can still be recovered. RTFM for RCS and SCCS and make to figure out how to set up a proper control system. Thats how you would do part 2) , but theres still no easy way to change rm. mv etc. to ensure that this does not take place. You would probably have to write shell scripts for all of these to ensure that. And nothings gonna prevent someone from doing cat > filename anway !! You can write scripts for part 1) like #!/bin/csh -fb cd dirb; foreach f (*) if ( -f $f) then if ( ( -e dira/$f ) && (-f dira/$f)) then # gross hack ... find $f -newer dira/$f -exec { cp $f dira/$f} \; else cp dirb/$f dira/$f endif endif end This should work, but I patched it together in3 minutes so no guarantees. dira and dirb need to be full path names Alternatively, use make to do this ... RTFM Abhijit (akhale@jerico.usc.edu) ---------------------------------------------------------------------------- schizo.samsung.com (Andrew Arensburger) writes ... In article <21408@usc.edu> I wrote: >1) dir-a and dir-b are two directories. Both may have files > with same names. How does one move the latest versions > of the files from dir-b to dir-a? This sounds like an ideal use for links: arrange 'dir-a' the way you want it (by hand, if necessary) and then make 'dir-b' a link to 'dir-a'. Use 'ln -s dir-a dir-b' (symbolic link, since only root can make hard-links to directories). >2) Suppose that a text file f is being included (e.g., #include) > in more than one source. What is, if there is, a mechanism to > protect file f from being accidentally deleted/modified? > Preferably, rm, mv, etc should be able to detect > if f is being used in some other file. The user may > be expected to explicitly state that f is being used > in source s when s is created. I believe the mechanism you are referring to is protection bits. If your file is called 'foo.h', change its protection bits using chmod 644 foo.h This will allow everyone to read the file, although only the owner will be able to change it. Or you could go a step further and change the protection to 444 (read-only for everyone). Then the owner would have to give himself write-permission on the file before changing it. -- jit@pit-manager.MIT.EDU (Jonathan Kamens) writes ... In article <21408@usc.edu> you write: >1) dir-a and dir-b are two directories. Both may have files > with same names. How does one move the latest versions > of the files from dir-b to dir-a? In other words, I > want > > foreach file f in dir-b do > if (f does not exist in dir-a) then > copy f from dir-b to dir-a > else > /* let f-a be the corresponding copy in dir-a */ > if (f is more recent than f-a) > move f from dir-b to dir-a > endfor I don't know of any 'basic' way to do this, i.e. a basic Unix command that is common over a wide range of Unix platforms and that behaves as expected most of the time. However, many people have written utilities for the maintenence of parallel directory trees. A few examples of such programs are track (started at AT&T, I believe, but most of the work being done on it now is being done here at Project Athena), reconcile (created by and still being developed at the Laboratory for Computer Science (LCS) here at MIT), and ninstall, a program written by Hewlett-Packard for "Network Based Software Distribution". There's also the BSD rdist program, which might possibly be hackable to keep two directories on the same host in sync. If you just want the capabilities you described, with no fancy bells and whistles, you can get them by writing a very short C program and a shell script. The C program takes a filename argument, and prints to its standard out the modification time of the file, as a Unix time value. You can use that value for any two files to see which one is older, and base whether or not you copy the file on that. Come to think of it, you can probably do that in perl without even writing any C code, since perl has a stat() call, and you can get the modification time for use in comparisons from the result of that stat. >2) Suppose that a text file f is being included (e.g., #include) > in more than one source. What is, if there is, a mechanism to > protect file f from being accidentally deleted/modified? > Preferably, rm, mv, etc should be able to detect > if f is being used in some other file. The user may > be expected to explicitly state that f is being used > in source s when s is created. There is no way that I know of to do this. ---------------------------------------------------------------------- guy@auspex.com (Guy Harris) writes ... >1) dir-a and dir-b are two directories. Both may have files > with same names. How does one move the latest versions > of the files from dir-b to dir-a? In other words, I > want > > foreach file f in dir-b do > if (f does not exist in dir-a) then > copy f from dir-b to dir-a > else > /* let f-a be the corresponding copy in dir-a */ > if (f is more recent than f-a) > move f from dir-b to dir-a > endfor Try exactly that. It sounds like you're using C shell, so I'll give you C shell answers (similar answers exist for the Bourne/Korn shell). For the "if f does not exist in dir-a", check out the C shell's notion of an expression, which includes a "-e" operator for testing whether a file exists. For the "if f is more recent than f-a", you'll have to write a program that "stat"s the two files whose pathnames it's given as arguments, and compares their mod times, exiting with an exit status indicating whether one file is more recent than the other or not. Both C and Bourne/Korn shells let you test, in an "if", whether a command returned "true" or "false". >2) Suppose that a text file f is being included (e.g., #include) > in more than one source. What is, if there is, a mechanism to > protect file f from being accidentally deleted/modified? No such mechanism. > Preferably, rm, mv, etc should be able to detect > if f is being used in some other file. The user may > be expected to explicitly state that f is being used > in source s when s is created. Nope. "rm" and "mv" certainly don't know anything about #include, nor do they know about any special table of dependencies such as you mention. If you want that, you'll have to write your own "rm", "mv", etc.. You could make the file not writable, which will cause "rm", at least, to pause and ask "do you really want to remove this" before it goes ahead and removes it. ............................................................ ``Why is it easy to say paralyze than to say parallelize?'' (Heard in ICPP 1989)