I am stuck with a directory which is not getting deleted.
Every time I do rm -rf it is not shown in ls for sometime but reappears after sometime.
drwxr-xr-x 2 root root 4096 Aug 11 05:20
Above is it's ls -l result.
The directory got created on 11 Aug. But when I delete it, it reappears back with same creation date.
Related
I connect to a remote computer thru VNC and use Konsole for my work. Konsole is version 2.3.3 using KDE 4.3.4. I have these two aliases:
alias ll 'ls -haltr; pwd'
alias cd 'cd \!*; ll'
which I observed to have the following behavior:
When path exists, it will cd to it and also do the ll alias
When path doesn't exist, it will simply say the path doesn't exist and won't do the ll anymore
Example:
Path exists
[10] % cd foo
total 14K
-rw-r----- 1 user group 913 Jun 3 2014 readme
-rw-r----- 1 user group 1.2K Dec 3 2020 report.txt
drwxr-x--- 2 user group 4.0K Jan 12 17:50 ./
drwx------ 77 user group 8.0K Jun 24 11:57 ../
/home/user/foo
[11] %
Path doesn't exist
[10] % cd nowhere
nowhere: No such file or directory.
[11] %
Now our department has transferred to another division and we've just started to connect remotely thru Exceed TurboX. I still use Konsole but the version is now 2.10.5 using KDE 4.10.5. I copied over the same two aliases, but I'm now observing a different behavior:
When path exists, it will cd to it and also do the ll alias (basically same as #1 above)
When path doesn't exist, it will attempt to cd AND still do the ll (different as #2 above)
So for #2, here's how it looks like:
[10] % cd nowhere
nowhere: No such file or directory.
total 120K
-rw-r----- 1 user group 272 Jan 6 2021 .cshrc
-rw-r----- 1 user group 1.2K Jan 6 2021 .alias
drwxr-x--- 2 user group 4.0K Jan 12 17:50 ./
drwx------ 77 user group 8.0K Jun 24 11:57 ../
/home/user
[11] %
I would like to know how to get behavior #2 of the previous working environment to this current working environment.
I've added the information on the Konsole and KDE versions because if the behavior is due to the version and there's no workaround, then I'll just be sad for the rest of my life working in this new remote desktop env. ^_^
I'm currently exploring a "check first if the path exists before doing ll" but to no avail. :'(
Edit:
The shell I'm using is tcsh
% printenv SHELL in both environments showed /bin/tcsh
And in addition:
Old environment
% echo $version
tcsh 6.17.00 (Astron) 2009-07-10 (x86_64-unknown-linux) options wide,nls,dl,al,kan,sm,rh,color,filec
New environment
% echo $version
3
The information in the question is still not sufficient to find out why tcsh behaves differently in the two working environments.
The alias defines a sequence of commands (cd followed by ll) without any condition.
alias cd 'cd \!*; ll'
On one system the execution of the alias seems to stop if the cd command reports an error for currently unknown reasons.
The correct way to prevent the execution of ll after a failed cd command would be the conditional execution of the ll command, e.g.
alias cd 'cd \!* && ll'
The decade long advice is: do not use aliases, use functions.
ll() { ls -haltr "$#" && pwd; }
cd() { cd "$#" && ll; }
I created a user with admin access named hadoop. The funny thing is that when I create a folder and try to give it 777 access it gives me back an error.
hadoop#linux:~$ mkdir testfolder
hadoop#linux:~$ ls -ltra testfolder/
total 8
drwxrwxrwx 25 hadoop sudo 4096 Jun 14 20:00 ..
drwxrwxr-x 2 hadoop hadoop 4096 Jun 14 20:00 .
hadoop#linux:~$ chmod -777 -R
testfolder/ chmod: cannot read directory ‘testfolder/’: Permission denied
Why is that when I am the creator of the directory ?
hadoop#linux:~$ groups
hadoop root sudo
Strangely, using the GUI, I can go in and right click the directory and change the file permissions. Can anyone help me understand what i am not understanding.
Note : I use Ubuntu 14
Your command chmod -777 -R testfolder/ is the issue here, more specific the - as part of the first argument.
Leave it away, just use chmod 777 -R testfolder/ and all should be fine...
Not exactly sure about the details, but the -777 should remove permissions, thus preventing access at least to the recursive portion of the command. I assume that is not what you want to do. Instead you probably want to grant more permissions to the directory. Looks like the command blocks itself. Though that might be by purpose, at least in an indirect manner.
I am trying to figure out in what condition would two different cd commands lead to the same directory.
For example: Under what condition do both cd /b/c/d/e and cd d/e change to the same directory?
Could someone help me with this as I do not quite understand how to figure this out.
If you create a symbolic link to directory "d" in the directory below b:
e.g.
/temp/b/c/d/e is the directory structure
cd /temp
ln -s /temp/b/c/d
now inside of temp you will have two directories, one real and one a symbolic link to d.
/temp$ ls -al
total 12
drwxrwxr-x 3 temp temp 4096 Oct 5 18:25 .
drwxr-xr-x 34 temp temp 4096 Oct 5 18:24 ..
drwxrwxr-x 3 temp temp 4096 Oct 5 18:24 b
lrwxrwxrwx 1 temp temp 20 Oct 5 18:25 d -> /temp/b/c/d
and you can do
cd b/c/d/e
or
cd d/e
and get to the same directory.
Say you are at the pwd (present working directory) of /b/c
Then cd /b/c/d/e will bring you to the same location as cd d/e
In the first you are defining the absolute path, whereas in the second you are defining the relative path.
Let's see the examples:
cd b/c/d/e
cd d/e
Both of them are using relative paths to e/
In fact, we can assume that in the seconds one, you are in the directory c
When I say relative path, it's because you don't have a / at the beggining of the path, and it means that cd will look for the path you're providing, from your current directory (. or $PWD).
cd ./b/c/d/e
cd ./d/e
or
cd "$PWD"/b/c/d/e
cd "$PWD"/d/e
You can get your current directory with the pwd command. It will give you the value of the PWD environment variable
I am working on Solaris 10 machine. In that i cannot able to untar my file. Logs are given below. Anyone please suggest what may be the issue? I can able to create tar file but unable to untar. :(
bash-3.2# ls -lrth ConfigCheck-120614-KL.out*
-rw-r--r-- 1 root root 144K Jun 12 17:15 ConfigCheck-120614-KL.out
-rwxrwxrwx 1 root root 146K Jun 16 16:49 ConfigCheck-120614-KL.out.tar
bash-3.2# tar xvf ConfigCheck-120614-KL.out.tar
tar: extract not authorized
bash-3.2# tar tvf ConfigCheck-120614-KL.out.tar
-rw-r--r-- 0/0 147377 Jun 12 17:15 2014 ConfigCheck-120614-KL.out
Solaris 11 tar will fail with that error message if you are running as uid 0 but do not have the Media Restore profile set up in the RBAC configuration.
Unless you're trying to restore from backup, you should normally be untarring files as a normal user, not root, to avoid accidentally overwriting critical system files.
I keep seeing a 403 error for my stylesheet which is hosted on my Rasberry Pi (webserver). I ran ls -al and this is the result:
pi#raspberrypi ~/www $ ls -al
total 16
drwxr-xr-x 2 pi root 4096 Mar 17 20:18 .
drwxr-xr-x 12 root root 4096 Mar 15 16:44 ..
-rw-r--r-- 1 pi root 644 Mar 17 20:18 index.html
-rw------- 1 pi root 329 Mar 17 20:19 stylesheet.css
The index.html data shows up when I point my browser at the ip, but there is no formatting and whenever I try to acess the css file through looking at the source code it keeps telling me theres a 403 error :(
Can anyone help a brother out??
Cheers!
You need proper permissions for the www folder, and that depends on which webserver you are running. For apache on debian the user is www-data, if your webroot is ~/www and you are user pi try these commands
Change owner to apache user recursively
Change Permissions to read for all recursively
chown -R www-data:www-data /home/pi/www
chmod -R 644 /home/pi/www