I am on macos mojave. I have a file on my system that was locked by Dreamweaver. I copied the file to another directory to work on it while it is checked out by another user, but the lock was copied with the file. So I have a file on my system outside the sandbox that I cannot write to and I cannot remove. Sudo is not helping. I noticed it has extended attributes and tried to clear it but it did not work. How can I clear the extended attribute or remove the file?
$ xattr index.html
com.apple.FinderInfo
$ xattr -c index.html
xattr: [Errno 1] Operation not permitted: 'index.html'
$
I found the problem. First I had to remove the lock. I did this through the Finder GUI.
Control-click the file in your Finder.
Select ‘Get Info’ from the
menu that appears.
Expand the ‘General’ section, if it isn’t
expanded already.
Deselect the ‘Locked’ checkbox.
After the file was unlocked then the extended attribute could be removed.
$ xattr index.html
com.apple.FinderInfo
$ xattr -c index.html
$
Related
so i was using command prompt to make some code in C. Basically in the code I write an array to a file at the end of the code using fwrite() and the file is called output. Basically I wanted to remove "output" to see what would happened. So I did $ rm output. But now when I press $ ls nothing appears. If I go to another directory and use $ ls it is fine and $ ls actually shows all the files. However, $ ls does not work in the directory where I used $ rm output in. However, if I do $ vim FILE where FILE is a file I know is in the current directory, it actually shows me the contents. So I know it's still there and not deleted but it's not visible. So I tried to use WinSCP to try to move the folders. But then I got an error message that says
Can't get attributes of files 'DIR..'
Command 'ls -la -d "DIR.." ; echo "WinSCP: this is end-of-file:$status"' failed with invalid output ''.
where DIR is the path to my directory.
Does anyone know a fix to this it would be greatly appreciated.
I found the mistake. I mistakenly created a file called ls
I attempted to download VirtualBox from terminal. Now, when I try to update, or input a command this reads out:
tyiese#penguin:~$ apt-get update
E: Malformed entry 1 in list file /etc/apt/sources.list.d/virtualbox.list (Component)
E: The list of sources could not be read.
tyiese#penguin:~$ rm /etc/apt/sources.list.d/virtualbox.list
rm: remove write-protected regular file '/etc/apt/sources.list.d/virtualbox.list'? Y
rm: cannot remove '/etc/apt/sources.list.d/virtualbox.list': Permission denied
I did attempt to remove the file - I think - but, as you can see it was not accepted.
As for the file removal, the last line of the output you provided hints what the problem is. Given your question, I assume you're not too familiar with users and permissions in GNU/Linux. The $ sign means you're running your commands as ordinary user, whereas to modify most system/configuration files (such as those pertaining to apt) you need root privileges. You typically obtain those on a per-command basis by prepending a command with sudo. So in your case that would be:
sudo rm /etc/apt/sources.list.d/virtualbox.list
After that you would be prompted for your password and (assuming your user is allowed to do so) the command would be run as root.
As for your original problem - malformed entry in sources file - I cannot help you unless you post the contents of said file. It might be a missing keyword or missing newline at the end. Hard to say.
One remark for the future. When pasting multi-line transcripts or snippets of code, please place them between two sets of triple backquotes (```) on lines of their own for better formatting.
root cause for this error is recent update made by you.
Generally copy n paste resultant to new line to the file which for some reason is causing the file to go in invalid state.
use sudo to edit the file and remove the unnecessary line.
This will work 99%.
cheers
I can not delete this directory admin when under the root permission. Can anyone help?
This is mainly due to the improper uninstall of the Vesta control panel. And the file attributes are shown here:
-------------e- admin/conf/mail
-------------e- admin/conf/web
-------------e- admin/conf/dns
and the attributes for directory admin are:
----i--------e- admin/conf
It seems the attribute i is causing problems, that attribute means the file is immutable.
With files like this not even root can change them, you need to change permissions first and then try to delete.
if you have a ext2, 3 or 4 filesystem you can use the chattr command to change the attribute.
Try executing the command:
>sudo chattr -i {filename}
This commands removes the attribute, and you should be able to delete the files.
If you want to set this bit to another file, is a trick to secure some files from deletion even from root, you can try:
>sudo chattr +i {filename}
I just installed ctags via homebrew and appended the following line in my ~/.vimrc:
set tags=./tags,tags;$HOME
And then I ran /usr/local/bin/ctags -R . on some of my directories and opened some files stored in the directories, then some of those scripts succeeded in importing tags file but others didn't.
For example, I opened up test.py on my Python workspace, which I already run the above command in, and then I tried to put Ctrl+] on my GVim, it looks like successfully imported the tags file.
I also opened up hello.go located in ~/go/src/github.com/user/hello, in which I already executed the above ctags command, successfully imported the tags file. However, my test.rb file, which I just put on the Go's directory in order to do test purpose, didn't import the tags file correctly.
Also, when I executed the ctags command on ~/another_go_workspace/src, and then opened up the file located in ~/another_go_workspace/src/hello/hello.go, then the file didn't import the tags file... However, since I appended set tags=./tags,tags;$HOME on my ~/.vimrc, doesn't it automatically look for higher directories, right?
So what am I missing?
And if it doesn't import the tags file in higher directories, do I have to execute the ctag command on EVERY directory, i.e. on ~/go/src/soccer_analysis, ~/go/src/coffee, ~/go/src/utility, etc, etc... ?
Thanks.
Your value for the tags option is correct and your assumptions about its behaviour are correct too.
With your setting, set tags=./tags,tags;$HOME, Vim will search for a tags file in the directory of the current file first then for a tags file from the working directory upward to $HOME.
This allows you to generate a tags file at the root of your project and be sure that Vim will pick it up wherever you are in your project and whatever the working directory is.
With the following structure and your current settings:
project/
bar/
bar.js
foo/
foo.js
project.js
tags
Vim should find tags in all the following scenarios and their variants:
$ vim project.js
$ cd foo && vim foo.js
$ cd bar && vim bar.js
$ vim foo/foo.js
$ vim bar/bar.js
$ cd bar && vim bar.js ../project.js
Every time you add a new file to your project or write to an existing file, you must re-index your whole project. From what you wrote about the ruby file, it looks like you didn't run ctags after adding the file. Try this for a selection of files in your project: :echo tagfiles().
No, vim doesn't go up directories to find tags files. I recommend you start vim from the top level directory (where you generated your tags), then traverse to whatever file you want.
vim go/src/coffee
Vim is capable of navigating filesystems nicely with commands like :Explore.
EDIT: I was wrong, semicolon can be used to search upwards. See :help file-searching
Also, I noticed that you tried to add $HOME to your tags, which isn't going to work for a number of reasons.
Documentation (:help 'tags') says:
Filenames for the tag command, separated by spaces or commas.
Therefore:
The delimiter is incorrect
$HOME is going to be treated like a tags file
So the "correct" way of doing this would be:
set tags=./tags,tags,$HOME/tags
Even if you do that though, I don't think it's going to work. Tags files comprise primarily of 2 elements, a search pattern and a filename. If you generated the file from the top, all filenames will be relative to that directory.
So if you are deep down in some subdir, vim will try to open the file using the relative filepath from the top, starting at that subdir.
The problem may have been caused by a typo. I think
set tags=./tags,tags;$HOME
should be
set tags=./tags;,tags;$HOME
On Linux, I need to know which files were added/modified/moved/deleted after compiling and installing an application from source code, ie. the command-line, Linux equivalent to the venerale InCtrl5.
Is there a utility that does this, or a set of commands that I could run and would show me the changes?
Thank you.
Edit: The following commands are sort of OK, but I don't need to know the line numbers on which changes occured or that "./.." were updated:
# ls -aR /tmp > b4.txt
# touch /tmp/test.txt
# ls -aR /tmp > after.txt
# diff -u b4.txt after.txt
If you only need to know which files were touched, then you can use find for this:
touch /tmp/MARK
# install application here
find / -newercm /tmp/MARK
This will show you all files whose contents or metadata have changed since you touched /tmp/MARK (including newly added files).
I would personally use something like Mercurial (version control) to do this.
The main reason, is that it is not only effective but it is also clean, since it will only add a hidden directory to the top of the tree where you want to check these changes.
Let's say that you need to know what files changed in /etc/. So before installation (you need to have mercurial installed) you add the directory to mercurial:
cd /etc
hg init
hg add
hg ci -m "adding all files in /etc/ to track them down"
The above will effectively "add" all the files to track them. To verify nothing has changed:
hg st
Should return no files.
If you (or the installation) modifies a file, you should see something like this:
hg st
M foo.sh
The "M" before the file states the given file was modified.
For new files you would see a ? before the file like:
? bar.sh
After you are done and no longer want Mercurial, simple remove the hidden directory:
cd /etc
rm -rf .hg