I'm trying to remove all files except read-only ones, but this command removes all of them anyway:
yes n | rm *
Did I do something wrong? If not, why doesn't it work?
For rm to automatically enable -i mode that prompts the user to delete unwritable files, the standard input has to be a terminal (as specified in the man pages).
So, for the command to work correctly the user has to specify the -i option manually:
yes n | rm -i *
After doing so the command works as expected.
In Posix systems, the read-only state of a file does not prevent it from being removed by rm.
You haven't said what your shell is, but perhaps you have an alias to rm that does ask you for confirmation when the file is read-only, and that alias behaves differently when it stdin is part of a pipe.
The problem is you only need write permissions to the folder, not to the files, to remove them:
(From here)
Any attempt to access a file's data requires read permission. Any attempt to modify a file's data requires write permission. Any attempt to execute a file (a program or a script) requires execute permission.
In *nix systems directories are also files and thus use the same permission system as for regular files. Note permissions assigned to a directory are not inherited by the files within that directory.
Because directories are not used in the same way as regular files, the permissions work slightly (but only slightly) differently. An attempt to list the files in a directory requires read permission for the directory, but not on the files within. An attempt to add a file to a directory, delete a file from a directory, or to rename a file, all require write permission for the directory, but (perhaps surprisingly) not for the files within. Execute permission doesn't apply to directories (a directory can't also be a program). But that permission bit is reused for directories for other purposes.
To find files with specific permissions you can use
find -perm <mode>
read more
To remove files found by find you can use
find . -perm 444 -exec /bin/rm {} \;
(mybe slightly different, it depends on files you search and system you have)
more exec examples
Related
Background
I'm maintaining a repo in which I create many small bash files containing tiny code snippets.
To create these files, I use the Right Click -> New -> File interaction in PyCharm/IntelliJ quite often:
These files are automatically created with the rw-rw-r-- (664) permissions.
So every time, I have to start a terminal, and execute chmod 700 somefile.sh to make them executable.
The Question
It would be wonderful to automatically set the permissions of files with a certain extension in IntelliJ/PyCharm.
I don't want all my files to be executable, just the files with a .sh extension.
Is there a way I configure this?
A non-elegant solution and potentially problematic would be to have a bash script in the background checking contents of a specific directory for specific filenames and applying chmod 700 on those.
I strongly suggest a special directory - to minimize the risk of this script affecting other/unexpected files.
You'd need to set it to sleep for a few seconds so that it doesn't take up too much of your CPU time.
It could look something like this:
background_chmod.sh:
#!/bin/bash
FILESPEC="*.sh"
DIRPATH=/some/special/path/
while [ 0 ] :
do
find $DIRPATH -name $FILESPEC -type f -exec chmod 700 {} \;
sleep 10; # tweak this to your requirements
done
You could then put it in your .bashrc file (if you are using bash) to execute when you log on.
Additional line in your .bashrc would be:
/path_to_script/background_chmod.sh &
Rememeber to:
chmod +x /path_to_script/background_chmod.sh
IMPORTANT: I have no means of testing the above. Please test this on some test files before implementing! Use at your own risk!
I want to move a couple of files from point a to point b
but I have to manually specify
mv /full/path/from/a /full/path/to/b
but some times there are 20 files which I have to move manually. Instead of /full/path/form/a, can't I just enter the a function which returns all the files which I want to move in my case;
/full/path/to/b is a directory, it's the target directory which all the files with extenstions mp3, exe and mp4 must go to:
mv ls *.{mp3,exe,mp4} /full/path/to/b
If I have to move a couple of files and I don't want to do it one by one, how can I optimize the problem?
The command mv ls *.{mp3,exe,mp4} /full/path/to/b in your question is not correct.
As pointed out in comments by #janos, the correct command is
mv *.{mp3,exe,mp4} /full/path/to/b
mv can complain about missing file if the file is really missing and/or the path is not accessible or is not valid.
As i can understand by your question description, if you go manually to the source path you can move the file to the desired directory.
Thus it seems that path is valid, and file exists.
In order mv to keeps complaining about *.mp3 not found (having a valid path and file) the only reason that pops up in my head is the Bash Pathname Expansion feature (enabled by default in my Debian).
Maybe for some reason this pathname expansion bash feature is disabled in your machine.
Try to enable this feature using command bellow and provide the correct command to mv and you should be fine.
$ set +f
PS: Check man bash about pathname expansion.
Is there a way to chmod 777 the contents of a tarfile upon creation (or shortly thereafter) before distributing? The write permissions of the directory that's being tar'd is unknown at the time of tar'ing (but typically 555). I would like the unrolled dir to be world writable without the users who are unrolling the tar to have to remember to chmod -R 777 <untarred dir> before proceeding.
The clumsy way would be to make a copy of the directory, and then chmod -R 777 <copydir> but I was wondering if there was a better solution.
I'm on a Solaris 10 machine.
BACKGROUND:
The root directory is in our ClearCase vob with specific file permissions, recursively. A tarfile is created and distributed to multiple "customers" within our org. Most only need the read/execute permissions (and specifically DON'T want them writable), but one group in particular needs their copy to be recursively writable since they may edit these files, or even restore back to a "fresh" copy (i.e., in their original state as I gave them).
This group is somewhat technically challenged. Even though they have instructions on the "how-to's" of the tarfile, they always seem to forget (or get wrong) the setting of the files to be recursively writable once untarred. This leads to phone calls to me to diagnose a variety of problems where the root cause is that they forgot to do (or did incorrectly) the chmod'ing of the unrolled directory.
And before you ask, yes, I wrote them a script to untar/chmod (specific just for them), but... oh never mind.
So, I figured I'd create a separate, recursively-writable version of the tar to distribute just to them. As I said originally, I could always create a copy of the dir, make the copy recursively writable and then tar up the copy dir, but the dir is fairly large, and disk space is sometimes near full (it can vary greatly), so making a copy of the dir will not be feasable 100% of the time.
With GNU tar, use the --mode option when creating the archive, e.g.:
tar cf archive.tar --mode='a+rwX' *
But note that when the archive is extracted, the umask will be applied by default. So unless the user's umask is 000, then the permissions will be updated at that point. However, the umask can be ignored by using the -p (--preserve) option, e.g.:
tar xfp archive.tar
You can easily change the permissions on the files prior to your tar command, although I generally recommend people NEVER use 777 for anything except /tmp on a unix system, it's more productive to use 755 or worst case 775 for directories. That way you're not letting the world write to your directories, which is generally advisable.
Most unix users don't like to set the permissions recursively because it sets the execute bit on files that should not be executable (configuration files for instance) to avoid this they invented a new way to use chmod some time ago, called symbolic mode. Reading the man page on chmod should provide details, but you could try this:
cd $targetdir; chmod -R u+rwX,a+rX .; tar zcvf $destTarFile .
Where your $targetdir is the directory you are tarring up and $destTarFile is the name of the tar file you're creating.
When you untar that tar file, the permissions are attempted to be retained. Certain rules govern that process of course - the uid and gid of the owner will only be retained if root is doing the untaring, but otherwise, they are set to the efective uid and gid of the current process.
Mac OS X Yosemite v.10.10.5.
I am trying to use the cp command to copy one Git directory to another.
This command-line statement:
cp -r /path/to/dir/from/ /path/to/dir/to/
Returns this error:
cp: /path/to/dir/to/.git/objects/00/00ad2afeb304e18870d4509efc89fedcb3f128: Permission denied
This error is returned one time each for (what I believe, but haven't verified, is) every file in the directory.
The first time I ran the command it worked properly, as expected, without error. But, without making any changes to any files, the second (and subsequent) times I ran the command, I got the error.
What's going on? And how can I fix this?
Edit:
In response to a question in the comment:
What does ls -l /path/to/dir/to/.git/objects/00/00ad2afeb304e18870d4509efc89fedcb3f128 show?
The answer is it shows:
-r--r--r-- 1 myusername staff 6151 May 6 00:45 /path/to/dir/to/.git/objects/00/00ad2afeb304e18870d4509efc89fedcb3f128
The reason you are getting Permission Denied is because you are trying to overwrite a file that already exists in the destination directory that has read only permissions set on it. Since it appears you're trying to overwrite it you could just remove the destination directory if it exists before the copy operation. Also you should use -R, not -r ...
Historic versions of the cp utility had a -r option. This
implementation
supports that option; however, its use is strongly discouraged, as it
does not correctly copy special files, symbolic links, or fifo's.
Using a command such as this should resolve your issue:
[[ ! -d dest ]] || rm -rf dest ; cp -R src dest
The above checks if dest exists; if it does recursively remove it, then copy the source to dest,
You may want cp -rp for this operation. -p preserves the user and group IDs associated with the file. Try starting over using -p and see if that solves the issue.
Anther reason you might be seeing this issue is if the permission really is denied. That is, if you're trying to copy into a folder owned by another user without superuser privileges.
our users have written a shell script to copy an application into into the /Applications folder on OSX. it works great the first time, but the second time they get an error. This is a new development, it apparently used to work fine before we changed the App name.
The shell script runs the following:
cp -a ApplicationName.app /Applications
open -a '/Applications/ApplicationName.app/Contents/MacOS/ApplicationName' --args -LSRC autolaunch
The first time it runs, it works fine, the application is copied over and then it launches. the second time it comes back with the following errors
[jrivera#chamomile] $ sudo ./InstallScript.sh /SRNM ABC1234567
cp: cannot overwrite directory /Applications/ApplicationName.app/Contents/Frameworks/Sparkle.framework/Headers with non-directory ApplicationName.app/Contents/Frameworks/Sparkle.framework/Headers
cp: cannot overwrite directory /Applications/ApplicationName.app/Contents/Frameworks/Sparkle.framework/Resources with non-directory ApplicationName.app/Contents/Frameworks/Sparkle.framework/Resources
cp: cannot overwrite directory /Applications/ApplicationName.app/Contents/Frameworks/Sparkle.framework/Versions/A/Resources/fr_CA.lproj with non-directory ApplicationName.app/Contents/Frameworks/Sparkle.framework/Versions/A/Resources/fr_CA.lproj
cp: cannot overwrite directory /Applications/ApplicationName.app/Contents/Frameworks/Sparkle.framework/Versions/A/Resources/pt.lproj with non-directory ApplicationName.app/Contents/Frameworks/Sparkle.framework/Versions/A/Resources/pt.lproj
cp: cannot overwrite directory /Applications/ApplicationName.app/Contents/Frameworks/Sparkle.framework/Versions/Current with non-directory ApplicationName.app/Contents/Frameworks/Sparkle.framework/Versions/Current
I'm not exactly sure why that's happening. it's the exact same script in the exact same location copying the exact same things 30 seconds apart. I dug into each and the directories and files all appear the exact same file type. I tried adding other commands to the cp to force it (-RfXv) but got the same thing. Any ideas? maybe it's a strange thing with sparkle?
I would suspect that the problematic files/directories have some extended attributes, and that cp is having problems overwriting the target when it has those attributes. (cp when preserving permissions often seems unreliable on different platforms).
Given that, there are a couple of workarounds to explore:
remove the target /Applications/ApplicationName.app before re-copying it.
use rsync, e.g.,
rsync -vaz ApplicationName.app/ /Applications/ApplicationName.app
Removing the target first may interfere with people using it while you are updating it; rsync works incrementally (and almost always updates more rapidly than cp).