So I have folder aa
$ mkdir aa
and path expansion for ls command works like this:
$ ls -la a*
total 0
drwxr-xr-x 1 a a 0 Mar 29 08:41 ./
drwxr-xr-x 1 a a 0 Dec 31 1979 ../
$ ls -la a?
total 0
drwxr-xr-x 1 a a 0 Mar 29 08:41 ./
drwxr-xr-x 1 a a 0 Dec 31 1979 ../
But "the same" for mkdir shows an error:
$ mkdir a*/bb
mkdir: cannot create directory 'a*/bb': No such file or directory
$ mkdir a?/bb
mkdir: cannot create directory 'a?/bb': No such file or directory
Where can I read why this difference in behavior happens and is there simple trick to let mkdir be "smarter" for behavior like in ls?
This does not work, since wildcard expansion is done before the argument is passed to mkdir. bash tries to expand a*/bb, doesn't find a match and tells you so. mkdir is not even invoked here. You can also try e.g.
echo a*/bb
or as you did before
ls -la a*/bb
Both commands will give you the same error message.
Now I realize how stupid that question was. Probably I wanted something like this for expansion to work:
mkdir "$(ls -d a?)"/bb
Try:
mkdir -p a*/aa
mkdir -p a?/aa
Related
I'm building a gitlab ci pipeline, and try to create a directory if it not exists.
Can anybody tell me what I'm doing wrong here?
$ if [ ! -d aws ]
$ then
$ mkdir aws
mkdir: cannot create directory ‘aws’: File exists
ERROR: Job failed: exit code 1
the relevant part of the gitlab-ci.yml
script:
- export
- ls -al
- if [ ! -d aws ]
- then
- mkdir aws
- fi
$ ls -al
total 128
drwxrwxrwx 16 root root 4096 Sep 17 12:07 .
drwxrwxrwx 6 root root 4096 Sep 17 12:07 ..
drwxrwxrwx 2 root root 4096 Sep 17 12:07 aws
I now just used mkdir -p and removed the test
you have something with aws name, which might be symbolic link, hard link, regular file, vs.
first delete or move that file to somewhere else then try again
you can try -e (returns true if file exists regardless of type).
I'm facing #subj . If I try to create a file/dir in my home directory it gets created as root:daemon instead of user:staff. I found this behaviour only for one directory ( all the other dirs aren't affected).
It used to create files properly before and now it sets root:daemon with 644.
I can't see any guid or sticky bits, etc.
What do I miss?
$ whoami
user
$ pwd
/home/user
$ touch 1
$ ll 1
-rw-r--r-- 1 root daemon 0 Jul 31 09:50 1
$ ls -ld /home/user/
drwxr-xr-x 13 user staff 4096 Jul 31 09:50 /home/user/
$ ls -ld /home/
drwxr-xr-x 5778 root staff 450560 Jul 31 08:21 /home/
$ umask
0022
I might be due to file access control set to root:daemon. If you run
getfacl /home/user
it should tell you if that was the problem. If yes, then you can set per-folder with the command setfacl with the parameters you prefer.
Another cause that comes to my mind is if that is a mountpoint masked with those particular user and group; you can check that with cat /etc/fstab.
I am trying to get alias's setup so that they print out the command, then run the command.
Ex:
> alias ls='ls -alh'
> ls
Running "ls -alh"
total 1.8G
drwxr-x--- 36 root root 4.0K Apr 23 09:44 ./
drwxr-xr-x 28 root root 4.0K Mar 6 17:24 ../
Is this possible? I was thinking of using a wrapper function, but I am unsure as to how one would acomplish this.
Thanks!
Just add an echo command in your alias before the actual command:
alias ls='echo "Running ls -alh"; ls -alh'
alias ls='echo "Running ls -alh" && ls -alh'
This runs two commands one after the other. The first command is echo "Running ls -alh", the && checks the return value of the echo command, if that's 0, then the command ls -alh is run. However, if for some reason there is a problem with the echo command and its return value is not 0 then the ls command won't be run.
The && command can come in very handy when writing scripts to run one command only when another is successful.
I am using [/usr/bin/]install in a Makefile to copy some binaries into my $HOME directory. My umask is set to 700.
The problem is that I am using install -D -m 700 to install the binaries and the parent directory is created with permissions of 755 and not 700:
$ umask
077
$ ls
$ touch hello
$ ls -l
total 0
-rw------- 1 emuso emuso 0 Apr 5 13:15 hello
$ install -D -m 700 hello $PWD/this/is/hello
$ ls -ld this
drwxr-xr-x 3 emuso emuso 4096 Apr 5 13:17 this
$ ls -lR this
this:
total 4
drwxr-xr-x 2 emuso emuso 4096 Apr 5 13:17 is
this/is:
total 0
-rwx------ 1 emuso emuso 0 Apr 5 13:17 hello
I want that the directories this and is get permissions 700 instead of 755.
Solutions that come to my mind are:
using install -d -m 700 to create the directory structure by hand.
using chmod to fix permissions manually.
The major drawback for the first solution is that I have a directory structure, which I would have to travel and create by hand.
So my question is: Is there an elegant way to control permissions for directories created by "install -D"?
What you want to achieve does not seem possible with a single invocation to install only, so you might have to resort to a combination of mkdir and install. Depending on your exact situation, you might be able to take advantage of a canned recipe, using something like this:
define einstall
test -d "$(dir $#)" || mkdir -p "$(dir $#)"
install -m 700 $< $#
endef
some/new/test/hello: hello
$(einstall)
If you plan to play around with canned recipes with make v3.81 or older, please make sure to read this answer to Why GNU Make canned recipe doesn't work?
I am using the Bash FTP command to ftp files, however i have a problem where i try to create a directory that is more than 2 folders deep. It works if i use two folders deep but if i go to three folders deep then it fails. For example:
mkdir foo/bar - this works
mkdir foo/bar/baz - this fails
I have also tried this:
mkdir -p foo/bar/baz - which didn't work, it ended up creating a '-p' directory
The shell script i am trying to run is actually quite simple but as you can see the directory structure is 3 folders deep and it fails to create the required folders:
#!/bin/bash
DIRECTORY="foo/bar/baz"
FILE="test.pdf"
HOST="testserver"
USER="test"
PASS="test"
ftp -n $HOST <<END_SCRIPT
quote USER $USER
quote PASS $PASS
mkdir $DIRECTORY
cd $DIRECTORY
binary
put $FILE
quit
END_SCRIPT
mkdir under ftp is implemented by the ftp server, not by calling /bin/mkdir no such options as -p,
what you should do is
mkdir foo
cd foo
mkdir bar
cd bar
mkdir baz
cd baz
If you still want your original construct, you can also do it like this:
#!/bin/bash
foo() {
local r
local a
r="$#"
while [[ "$r" != "$a" ]] ; do
a=${r%%/*}
echo "mkdir $a"
echo "cd $a"
r=${r#*/}
done
}
DIRECTORY="foo/bar/baz"
FILE="test.pdf"
HOST="testserver"
USER="test"
PASS="test"
ftp -n $HOST <<END_SCRIPT
quote USER $USER
quote PASS $PASS
$(foo "$DIRECTORY")
binary
put $FILE
quit
END_SCRIPT
Try lftp instead:
[dong#idc1-server1 ~]$ lftp sftp://idc1-server2
lftp idc1-server2:~> ls
drwxr-xr-x 3 dong dong 4096 Jun 16 09:11 .
drwxr-xr-x 18 root root 4096 Apr 1 22:25 ..
-rw------- 1 dong dong 116 Jun 16 09:28 .bash_history
-rw-r--r-- 1 dong dong 18 Oct 16 2013 .bash_logout
-rw-r--r-- 1 dong dong 176 Oct 16 2013 .bash_profile
-rw-r--r-- 1 dong dong 124 Oct 16 2013 .bashrc
drwx------ 2 dong dong 4096 Jul 24 2014 .ssh
lftp idc1-server2:~> mkdir a/b/c/d
mkdir: Access failed: No such file (a/b/c/d)
lftp idc1-server2:~> mkdir -p a/b/c/d
mkdir ok, `a/b/c/d' created