Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!buddha.usc.edu!rkumar
From: rkumar@buddha.usc.edu (CPR)
Newsgroups: comp.unix.questions
Subject: Re: Some simple questions (VERY Long)
Message-ID: <21533@usc.edu>
Date: 2 Dec 89 06:06:28 GMT
Sender: news@usc.edu
Distribution: usa
Organization: University of Southern California, Los Angeles, CA
Lines: 201

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)