for example, my directory like this:
lib
|
+--foo.so
+--bar.so -> bar.so.1.0.0.0
+--bar.so.1.0.0.0
Are these both ways always same?
The reason I ask this question is that I found unix will copy to real so file when I
cp -r lib /path/to/
new directory like this:
/path/to/lib
|
+--foo.so
+--bar.so
+--bar.so.1.0.0.0
The difference between so and ls -s is the difference between a file and a symbolic link. Symbolic links are like aliases to other files and operations on them result in changes in the linked files. When you do cp, it copies the linked file to the target directory with the link name as the file name, i.e., it reads the linked file when it opens the symbolic link to copy it. So lose the link and instead get a copy of the linked file. If you use -P option of the cp command you can preserve the symbolic link information.
cp -P lib /path/to/
Related
I am having trouble symlinking dotfiles. I have a folder in my home directory ~/dotfiles which I have synced to a github repo. I am trying to take my .vimrc file in ~/dotfiles/.vimrc and create a symbolic link to put it at ~/.vimrc. To do this I type in
ln -s ~/dotfiles/.vimrc ~/.vimrc
But when I run that it says
ln: /Users/me/.vimrc: File exists
What am I doing wrong?
That error message means that you already have a file at ~/.vimrc, which ln is refusing to overwrite. Either delete the ~/.vimrc and run ln again or let ln delete it for you by passing the -f option:
ln -s -f ~/dotfiles/.vimrc ~/.vimrc
There is a better solution for managing dotfiles without using symlinks or any other tool, just a git repo initialized with --bare.
A bare repository is special in a way that they omit working directory, so you can create your repo anywhere and set the --work-tree=$HOME then you don't need to do any work to maintain it.
Approach
first thing to do is, create a bare repo
git init --bare $HOME/.dotfiles
To use this bare repo, you need to specify --git-dir=$HOME/.dotfiles/ and --work-tree=$HOME, better is to create an alias
alias dotfiles='/usr/bin/git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME
At this point, all your configuration files are being tracked, and you can easily use the newly registered dotfiles command to manage the repository, ex :-
# to check the status of the tracked and untracked files
dotfiles status
# to add a file
dotfiles commit .tmux.conf -m ".tmux.conf added"
# push new files or changes to the github
dotfiles push origin main
I also use this way to sync and store my dotfiles, see my dotfiles repository and can read at Storing dotfiles with Git where I wrote about managing for multiple devices.
How to symlink all dotfiles in a directory recursively
Have a dotfiles directory that is structured as to how they should be structured at $HOME
dotfiles_home=~/dotfiles/home # for example
cp -rsf "$dotfiles_home"/. ~
-r: Recursive, create the necessary directory for each file
-s: Create symlinks instead of copying
-f: Overwrite existing files (previously created symlinks, default .bashrc, etc)
/.: Make sure cp "copy" the contents of home instead of the home directory itself.
Tips
Just like ln, if you want no headache or drama, use an absolute path for the first argument like the example above.
Note
This only works with GNU cp (preinstalled in Ubuntu), not POSIX cp. Check your man cp, you can install GNU coreutils if needed.
Thanks
To this and this.
I have a file (reviews_dataset.tar.gz) that contains many files which contains data. I am required to extract the files in this archive and then perform some basic commands on the file. So far I have created a directory named (CW) and found a command tar zxvf fileNameHere.tgz but when I run this it of course cannot find my file as I have not "downloaded it" into my directory yet? How do I get this file into my directory so that I can then extract it? Sorry if this is poorly worded I am extremely new to this.
You must either run the command from the directory your file exists in, or provide a relative or absolute path to the file. Let's do the latter:
cd /home/jsmith
mkdir cw
cd cw
tar zxvf /home/jsmith/Downloads/fileNameHere.tgz
You should use the command with the options preceded by dash like this:
tar -zxvf filename.tar.gz
If you want to specify the directory to save all the files use -C:
tar -zxf filename.tar.gz -C /root/Desktop/folder
I am on Mac OS.
I have a directory with round about 3000 files and several subdirectories (wordpress installation)
Now I have to find all the files in a similar directory (have to separate master and child installation) that are additional files and have to copy them away into another directory.
I use this command:
$ diff -rq dt-the7 dt-the7-master-from-Yana|grep 'Only in dt-the7'|awk {' print $3 $4 '}|sed 's/:/\//g'|xargs -J {} rsync -av {} neu/
but somehow a certain file 3d.png and a list of other that should be in a subdir of the destination dir are copied into the root dir of the destination.
Any idea why that might be?
It makes no difference whether I use cp, rsync or ditto
You need the -R relative option on your rsync command.
Without this rsync just copies the item referenced rather than the path referenced, so items at the root level are copied as you expected but items in sub-directories are also copied to the root, which is not what you wanted.
With the option rsync takes account of the relative path and recreates it at the destination.
An example with another command might help, consider:
cp A/B.txt C/
that will copy B.txt into C, it does not create a folder A in C which in turn contains the file B.txt. rsync without -R behaves like that cp command, with -R it creates the A directory in C.
HTH
I tried to create a symbolic link to a non existing file
ln -s non_existing_file.txt $HOME/dir1/dir2/my_symbolic_link
Then I tried to write something in the non existing file using the symbolic link
vi $HOME/dir1/dir2/my_symbolic_link
Now after saving and exiting non_existing_file.txt is created under dir2.
Can someone explain why?
ln -s target linkpath
creates a symlink at linkpath which holds the name target. Operations on the symlink interpret the name target relative to the directory where the symlink resides, not the present working directory.
So, if you have a symlink holding, say, ../usr in /tmp/link-to-usr, then ls /tmp/link-to-usr will list the contents of /usr (which is /tmp/../usr) regardless of where the ls command is executed.
I want to copy a complete directory content from /home/private_html/userx/ into the /home/private_html/usery/, the problem is that the directory userx contains few symlinks, and when using the cp it just skip them (skip occurs, if symlinks directs into a file, in case if it points into the directory, it just copy WHOLE directory instead...).
The command I was using looks following:
# cp -iprv /home/private_html/userx/ /home/private_html/usery/
Has anyone a solution to copy the directory "just as it is" into other place?
On FreeBSD, cp doesn't have an -r option. It does have -R, which should do what you want:
-R If source_file designates a directory, cp copies the directory and
the entire subtree connected at that point. If the source_file
ends in a /, the contents of the directory are copied rather than
the directory itself. This option also causes symbolic links to be
copied, rather than indirected through, and for cp to create spe‐
cial files rather than copying them as normal files. Created
directories have the same mode as the corresponding source direc‐
tory, unmodified by the process' umask.
Roland is right about the -R flag. You could also use a pair of tar-processes, which would make your command a little bit more system-independent:
tar -C /home/private_html/userx/ -cpf - . | tar -C /home/private_html/usery/ -epf -