I have found a part of script like this In xx.sh：
BUILD_BOOT=.
mkdir -p $BUILD_BOOT
Can anybody help to explain what's the script above for as the directory parameter is .?
-p is short for --parents - it creates the entire directory tree up to the given directory.
E.g., suppose there are no directories in your current directory.
If you execute:
mkdir a/b/c
It will fail, since you do not have an a subdirectory.
On the other hand
mkdir -p a/b/c
Will create the entire structure - a/b/c
mkdir -p means: create the directory and, if required, all parent directories. The fact that this makes little sense when the path is specified as ., so the current working directory, does not change this. Most likely the line where the path is defined is meant to be adapted as required.
In general: consult the linux manual pages for questions about commands and their options like this: man mkdir. A great source of information!
See mkdir.
It creates all the intermediate directories on the path to the final directory that do not already exist (as well as the final directory), and doesn't fail if the target directory already exists.
In context, it is pointless; if the BUILD_ROOT is the current directory, it already exists. At some time, the BUILD_ROOT must have been a longer path.
Related
I'm trying to create a file structure in unix using the relative path, however the directories are being created under my current directory? What am i doing wrong.
mkdir ../folder1 -p folder2/folder3 folder2/folder4 folder5
.. goes back to my home and /folder should go into folder1, but all of this is being done my current directory?
All the filename arguments to mkdir are simply directories to create, they're not interpreted relative to each other. Putting ../folder1 first doesn't make it use that as the starting directory for all the rest.
You can use brace expansion to concatenate all the subdirectory paths to a single directory prefix.
mkdir -p ../folder1/{folder2/{folder3,folder4},folder5}
Also, remember that options usually go before filename arguments.
I am beginner in linux and wondering about a shorter way to go a directory having same parent directory. Here I elaborate that.
dir1
- dir11
- dir12
- dir13
- dir14
Directory dir1 has sub-directories dir11,...,dir14. I am at directory dir13 and want to go to dir12. What is direct way to do this?
I can do
cd..
cd dir12/
But I am wondering whether I can do this in single step. Any ideas?
cd doesn't only take one directory to change to. You can provide a complete path to which you want to go.
You can simply type cd ../dir12
You can also go all nuts with cd ../dir12/../dir13/../dir14/..
Try also the following: type cd ..<press Tag twice>. This will list you all directories in the path you have given.
There are wildcards that cd can use. For example ~ is your home directory. cd ~ or just cd will change into your $HOME.
See man cd (in a terminal) for more.
I am copying files from source to location. The source is not owned by me and the permission for files at source is ----rwx---. The permission of files coped to destination directory which is owned by me is ----r-x---. The permission of destination directory is drwxrwsrwx. How do I have the files with same permission of destination directory. I tried "cp --no-preserve=all" but it did not work (still the same permission).
Try this:
cp --no-preserve=mode,ownership $backupfile $destination
Let me rephrase that to "How to preserve permissions of destination directory on copy?"
I can't take credit for the answer since I just combined a couple of answers I found on the wild. So here it comes.
Firstly
Permissions are generally not propagated by the directory that files are being copied into, rather new permissions are controlled by the user's umask. However when you copy a file from one location to another it's a bit of a special case where the user's umask is essentially ignored and the existing permissions on the file are preserved.
Which explains why you can't directly propagate the permissions of the src to the dst directory.
However, there is two-step workaround to this.
cp-metadata: Copy the attributes and only the attributes you want to preserve back to the source directory. Here is a quick script that can do this:
#!/bin/bash
# Filename: cp-metadata
myecho=echo
src_path="$1"
dst_path="$2"
find "$src_path" |
while read src_file; do
dst_file="$dst_path${src_file#$src_path}"
$myecho chmod --reference="$src_file" "$dst_file"
$myecho chown --reference="$src_file" "$dst_file"
$myecho touch --reference="$src_file" "$dst_file"
done
You can leave out the touch command if you don't want keep the timestamp.
Replace myecho=echo with myecho= to actually perform the commands.
Mind that this script should be run in sudo mode in order to be able
to run chown and chmod effectively
cp --preserve: After you have successfully run the first command
now it's time to copy the contents along with the attributes to the dst
directory.
--preserve[=ATTR_LIST]
preserve the specified attributes (default: mode,ownership,timestamps), if possible additional attributes: context, links, xattr, all
\cp -rfp $src_dir $dst_dir should do what you want.
I need to make a hierarchie of directories but I can only use 1 command, how can I do the following?
I'm currently in the directory called 'linux', now I have to create here a directory called 'a' and in this directorie I have to create a directory called 'b'.
thnx
You can try:
mkdir --parents a/b
mkdir -p a/b/c/d
-p Create intermediate directories as required. If this option is not specified, the full path prefix of
each operand must already exist. On the other hand, with this option specified, no error will be
reported if a directory given as an operand already exists. Intermediate directories are created with
permission bits of rwxrwxrwx (0777) as modified by the current umask, plus write and search permission
for the owner.
In the installation guide of some soft, user is told to run this
sudo ln -s /opt/local/somesoft/somsoft* /opt/local/bin
Is this command dangerous ? Should /opt/local/bin be prevented from calling something else tha n itself ?
This command does few things
sudo gives root permissions to the 'ln' binary
ln is instructed to go through all files matching pattern /opt/local/somesoft/somsoft*
for every such file it tries to create symbolic link in /opt/local/bin directory
this created symbolic link will have the same name as the file just being processed
Your first question is, is it dangerous? Most probably not, there are few things which might go wrong
your $PATH environment contains some strange directory, so instead of calling /usr/bin/ln (as was the original intention I believe) you wold be tricked into calling some different executable. For example if your PATH=.:/tmp:/usr/bin, 'ln' is first searched in your current directory, then in /tmp and then in /usr/bin. And it's called with superuser permissions ...
there are no such files as /opt/local/somesoft/somsoft* . In such case ln will create symbolic link '/opt/local/bin/somsoft*' (including the star in it's name). That's probably not what you wanted
/opt/local/bin already contains the files with the same names as /opt/local/somesoft/somsoft* . In such case ln will not create new files there (is it good or bad? that is the question)
You don't have /opt/local/bin . In such cases there are several ways of how the command fails (depending whether you have /opt/local directory and how many files match the pattern /opt/local/somesoft/somsoft*)
Your second question does not make much sense. /opt/local/bin is a directory, and directory can't "call" anything. So it can't be prevented to do so. If you ask whether the symbolic links should be created there, I would say why not. The whole idea behind the command is to
install somesoft into special directory so that you won't pollute your /usr/bin or any other common directory
to be able to run the commands without the need of specifying every time full path /opt/local/somesoft/somsoft... you may want to create symbolic links in /opt/local/bin. And make sure that your /opt/local/bin is in your directory.