I am running these three commands.
cd "${folder1}"
diff -ruN "${folder1}" "${folder2}" > "${patchname}"
patch -f -s -d "${folder1}" --merge < "${patchname}"
When I run them it successfully changes the files in folder1 to the same as folder2. However when I run these commands I get the output.
patch: **** Can't rename file ./update.patch.omMg8yG to update.patch : Operation not permitted
The problem is here:
cd "${folder1}"
diff -ruN "${folder1}" "${folder2}" > "${patchname}"
You're inside folder1, and trying to create a patch that's also inside folder1 (which we know because your log file is calling the file ./update.patch.omMg8yG, explicitly referring to the current directory), which contains a set of differences between folder1 and folder2, while those differences also include the contents of the output file itself -- the output file being generated over the course of the diff operation, and read over the course of patch operation.
Consequently, patch is trying to change the patch file it's reading from. It's failing, hence the error, but you shouldn't be having it make the attempt -- particularly since on most UNIXlike operating systems, this attempt wouldn't fail (I'm assuming you're on Cygwin, or on a remote filesystem mount that doesn't support open unlinked files).
Modify your patchfile variable to point to a location in a different directory, neither folder1 or folder2.
Related
Using any of the standard Robot libraries, is it possible to recursively copy the contents of a directory to an existing destination directory?
Basically, I'm looking for the equivalent of the following shell command: cp -r foo/. bar (note the trailing dot)
I tried Copy Directory but this creates a directory foo inside bar (as documented) and it doesn't stop doing that even when supplying the trailing dot. Copy Files chokes when it encounters a directory.
Is there anything I overlooked? Or do I need to just call cp -r myself?
As I only need this to work on Linux, I ended up implementing a custom keyword calling cp -r. If this is ever needed cross-platform, then I'll follow the suggestions to directly implement it in Python.
Copy Directory Contents
[Documentation] Recursively copies the contents of the source directory into the destination.
[Arguments] ${source} ${destination}
Directory Should Exist ${source}
Directory Should Exist ${destination}
${result} = Run Process cp -r ${source}/. ${destination}/
Should Be Equal As Integers ${result.rc} 0
I have two VM's : dev and prod.
I want to use rsync to copy dump file from prod and then restore it on dev. I'm using this command to copy:
rsync -rave user#ip:/home/user/dumps /home/anotheruser/workspace/someapp/dumps
The same thing successfully copies static files (.html, .css) from another directory, but in this case only the folder itself is created but without the file:
/home/anotheruser/workspace/someapp/dumps
but I'm expecting:
/home/anotheruser/workspace/someapp/dumps/dumpfile
What is going wrong? dumpfile exists there user#ip:/home/user/dumps/dumpfile.
The command you want is probably this:
rsync -av user#ip:/home/user/dumps/ /home/anotheruser/workspace/someapp/dumps/
I've
removed the r because it's implied by the a anyway.
removed the e because that was probably your problem; it requires a parameter that you haven't given.
added the / at the end of the pathnames to make sure they're treated as directories.
I know this is a basic question but I'm missing something fundamental about makefiles.
Take this simple rule/action:
doc: ${SRC_DIR}/doc/dir1/file1.pdf ${SRC_DIR}/doc/dir1/file2.pdf
cp $? ${DEST_DIR}/doc/
the first time I run it, it copies file1.pdf and file2.pdf to the destination/doc directory. Perfect. I'm expecting the next time I run it, for it to do nothing. The source files haven't changed, aren't they a dependency? But when I run I get :
cp : cannot create regular file ..... :Permission denied.
so, 2 questions:
1) Why is it trying to do it again? When I run make -d I see it eventually says: No need to remake target .../file1.pdf and .../file2.pdf but then
it says : must remake target 'doc'
If it doesn't need to make either pdf file, why does it need to make doc?
2) say the pdf files had changed in the source, they are read only though, so it gets the permission denied error. How do you get around this?
A make rule:
target: preqreq0 prereq1...
command
...
says that target needs to be (re)made if it does not exist or is older than
any of the prerequisites preqreq0 prereq1..., and that target shall be
(re)made by running the recipe command ....
Your rule:
doc: ${SRC_DIR}/doc/dir1/file1.pdf ${SRC_DIR}/doc/dir1/file2.pdf
cp $? ${DEST_DIR}/doc/
never creates a file or directory doc, so doc will never exist when
the rule is evaluated (unless you create doc by other means), so the recipe
will always be run.
The kind of target that I believe you want doc to be is a phony target,
but you are going about it wrongly. A reasonable makefile for the purpose would
be:
SRC_DIR := .
DEST_DIR := .
PDFS := file1.pdf file2.pdf
PDF_TARGS := $(patsubst %,$(DEST_DIR)/doc/%,$(PDFS))
.PHONY: doc clean
doc: $(PDF_TARGS)
$(DEST_DIR)/doc/%.pdf: $(SRC_DIR)/doc/dir1/%.pdf
cp $< $#
clean:
rm -f $(PDF_TARGS)
I recommend The GNU Make documentation
As for your second problem, how to overwrite "readonly" files, it is unrelated to make.
You cannot overwrite files to which you do not have write permission, regardless
of the means by which you try to do it. You must get write permission to any files
that you need to write to. It is a system administration matter. If you do not
understand file permissions you may find help at sister-site Unix & Linux
or serverfault
I have a general question as to why this occurs, and a misconception about 'pwd'.
You start with directory /test and in it you have /test/folder1.
Folder 1 has: file1.txt
In 2 separate terminals we "cd /test", and do an "ls" and discover folder1 as the output for both of these terminals.
We now "cd folder1" on terminal one. Terminal two remains in /test.
If we then "mv folder1 folder2" on terminal two and run an "ls" we get folder2 as the output. Clearly indicating our mv was successful.
However, within terminal 1 (which was in /test/folder1) if we run a "pwd" the output remains /test/folder1. Ie: it does NOT reflect that we have since moved the folder to /test/folder2.
Why is this the case? I can understand why if we were to edit the file1.txt it is just a pointer within the file system that should be pointing to the same file. Indeed it is as you can modify the file in each terminal and see the edits in the other. However, why is it the case that the 'pwd' command no longer reflects the actual path to that directory?
Thanks!
Assuming you're using bash, pwd is showing you the value of the PWD environment variable, which is updated when you change directory with cd. The folder1 directory changing name does not cause bash to update PWD. However you can find evidence that the directory has changed name:
pwd -P will show the new name of the directory.
ls -l /proc/self/cwd will link to the new name.
I think it is just the case that the first terminal has no reason to re-evaluate where it is. If you do the following command in the first terminal
cd .
you will see your current working directory has indeed changed per the rename (mv).
I use an rsync command to sync two directories remote >local
the command is (used in python script)
os.system('rsync --verbose --progress --stats --recursive\
--copy-links --times --include="*/" --include="*good_name*.good_ext*"\
--exclude-from "/myhome/mydir/src/rsync.exclude"\
%s %s'%(remotepath,localpath))
I want to exclude certain directories that has the same files that I also want to include.
I want to include recursively
any_dir_name/any_file_name.good
but I want to exclude any and all files that are in
bad_dir_name/
I used --exclude-from and here is my exclude from file
*
/*.bad_dir_name/
Unfortunately it doesn't work. I suspect it may have something to do with --include="*/" but if I remove it the command doesn't sync any files at all.
I got it. I used -vv to find according to which rule the directory was showing up in the sync list and since rsync supports regular expressions,
I changed my include statement from "*/" to
--include="*[^.bad_dir_name]/"
and all works fine now.