As it says in the description. I first check our database is up to date
mh547:bin crashandburn4$ sudo /usr/libexec/locate.updatedb
Password: #password entered and function executed without errors
I then try and search for something inside my Documents folder
mh547:bin crashandburn4$ cd ~/Documents/
mh547:Documents crashandburn4$ ls
Mamp_workspace/ Scenarios.docx gc01/
mh547:Documents crashandburn4$ locate Scenarios.docx #nothing returned
I then try another random folder:
mh547:Documents crashandburn4$ cd ..
mh547:~ crashandburn4$ ls
Applications/ Movies/ drawable/ untitled-2.pdf
Desktop/ Music/ drawable-xhdpi/ untitled-2.synctex.gz
Documents/ Pictures/ dwhelper/ untitled-2.tex
Downloads/ Public/ linux_ssh* website-terminal-copy-paste
Dropbox/ Samsung/ scripts/ workspace/
Google Drive/ Sites/ untitled-2.aux workspace_copy_to_linux*
Library/ android-sdks/ untitled-2.log
mh547:~ crashandburn4$ locate website-terminal-copy-paste
/Users/crashandburn4/website-terminal-copy-paste #correct result returned
can anyone help me? I've been stuck on this for a good half hour or so.
As pointed out by plundra, that's because the locate OSX ships with is old and crippled and doesn't index and/or report files which are not readable by nobody, even when run as root. What you can do though is either install homebrew and then GNU locate, or, as suggested here use mdfind -name instead (I don't have an OSX box at hand to test this).
It's because your Documents-folder isn't world readable, which is a good thing, specially on shared systems.
The BUGS section of the locate(1) man-page explains it:
The locate database is typically built by user ''nobody'' and the
locate.updatedb(8) utility skips directories which are not readable
for user ''nobody'', group ''nobody'', or world. For example, if your
HOME directory is not world-readable, none of your files are in the
database.
Try running ls -ld ~/Documents and you'll see the permissions. Wikipedia have an article on Unix permissions if you are unfamiliar with these.
You can do sudo ln -s /usr/libexec/locate.updatedb /usr/local/bin/updatedb to make the updatedb command available
Related
I often use fzf to navigate the filesystem, especially the Alt-c key binding.
When invoked, fzf generates a list from the current working directory.
Is it possible to make fzf generate a list from a specified directory?
I have tried fzf <dir>, but it results in an error (unknown option). Also, I can't find any options like -C <dir> for specifying the start directory.
I had a more general issue which might be useful for you. The following is from a blog post I wrote about it:
Configuring FZF to search useful directories beyond the working directory
I use fzf both as a command line tool and from within Vim using the fzf.vim plugin. It makes finding (and opening) files intuitive, fast, and frees you from needing to remember their location or exact name. By default, fzf searches recursively within the current directory, which is often just what you want. If you need to search for a file in some directory beyond the current working directory you need to specify that path as an argument to fzf, after which it's business as usual (fzf will recursively search the specified directory).
The Problem
It always felt a shame to have to occasionally precisely specify a path in order to get a fuzzy search going... precisely specifying a path is the exact thing that fzf is supposed to unburden your from! My initial approach was to supply the home directory path and let fzf search everything, the home directory path can be specified in only a couple of characters so there's no real burden in that case.
The problem with doing this is that you end up searching a lot of directories which you know don't have the file you want. The main offenders were directories you end up with if you install say, anaconda3. The results would be swamped with thousands of internal files, with very long paths. The long paths tended to 'soak up' any letters I entered in the search, so it was difficult for fzf to filter them out.
The Solution
You can choose which searching tool fzf uses under the hood. The default is the standard linux find command, but you can also use fd, ripgrep or silver searcher. Apart from being a lot faster than the default find, these latter tools respect .ignore files. This means that fzf will skip any files or directories listed in a .ignore file. We can turn this feature to our advantage.
First, we install fd. If you run Ubuntu 19.04 (Disco Dingo) or newer, you can install the officially maintained package:
sudo apt install fd-find
If you use an older version of Ubuntu, you can download the latest .deb package from the release page and install it via:
# adapt version number and architecture
sudo dpkg -i fd_8.2.1_amd64.deb
Now we configure fzf to use fd by adding the following line in your .bashrc:
export FZF_DEFAULT_COMMAND="fdfind . $HOME"
If you're using an older version than Ubuntu 19.10, the above line needs to be modified like so:
export FZF_DEFAULT_COMMAND="fd . $HOME"
Now fzf will always search recursively from the home directory, and respect any .ignore files. So let's make one in the home directory:
touch ~/.ignore
I find that the list of directories that I might conceivably (~15) want to recursively search with fzf is shorter that the list of directories that I would never want searched. The total number of files in the directories I want searched is about 5000 or so - easily handled by fd.
In the .ignore file, I first list all my home directories, each followed by a '/':
# start by igoring every home directory
anaconda3/
arch/
cache/
code/
Desktop/
.
.
.
Then below those, put the directories that you want to be searched, each preceded by a '!' and followed by a '/':
# now un-ignore the ones I care about
!code/
!Desktop/
!documents/
!downloads/
.
.
.
The '!' will 'cancel out' the previous ignore commands.
And there we have it. We can invoke fzf wherever we are in the file system and start typing vague things about the file(s) we have in mind and fzf will search in a set of predefined directories and find it with ease. This completely removes the barrier of thinking where a file might be and how precisely it was named.
N.B. I have noticed that, for some reason, a couple of subdirectories were not showing up in the fzf search, and so I explicitly created some '!path/to/missed/directory/' lines in this section...
N.B. You may be wondering "What if I find myself in an unusual directory not on the list, and want to use fzf?". I had the same concern so I put a couple of aliases in my .bashrc that can toggle the above configuration on and off at will (be sure to use 'fdfind' for Ubuntu 19.10+, as disused above):
# restore fzf default options ('fzf clear')
alias fzfcl="export FZF_DEFAULT_COMMAND='fd .'"
# reinstate fzf custom options ('fzf-' as in 'cd -' as in 'back to where I was')
alias fzf-="export FZF_DEFAULT_COMMAND='fd . $HOME'"
If you're using Vim to create the .ignore file, an easy way to get a list of all the directories in your home directory is the following command:
:.!ls ~/
Append a '/' to all lines by putting the cursor on the first directory in the list and entering the following command:
:.,$ norm A/
Similar to above, insert the '!' before each one by putting the cursor on the first directory in the list and entering the following command:
:.,$ norm I!
Assuming you're using bash or similar, this is built into the default completion options which get installed with fzf: https://github.com/junegunn/fzf#fuzzy-completion-for-bash-and-zsh
tldr; enter start file or directory, append ** and hit Tab. So if you'd enter cd /foo/** then tab opens fzf with /foo as start directory.
edit at the time of writing the commands for which this works are hardcoded in fzf's bash helpers, which is why this works for cat and cd but not for tac or nano. This is the complete list:
awk cat diff diff3
emacs emacsclient ex file ftp g++ gcc gvim head hg java
javac ld less more mvim nvim patch perl python ruby
sed sftp sort source tail tee uniq vi view vim wc xdg-open
basename bunzip2 bzip2 chmod chown curl cp dirname du
find git grep gunzip gzip hg jar
ln ls mv open rm rsync scp
svn tar unzip zip
To add other commands use this in e.g. your .bashrc, after the place where fzf gets sourced (something like [ -f ~/.fzf.bash ] && source ~/.fzf.bash):
__fzf_defc "tac" _fzf_path_completion "-o default -o bashdefault"
Alternatively: open an issue to ask for the commands you want to be added to fzf by default, things like tac and nano are super common anyway.
You can do something like:
find <dir> | fzf
fd . <dir> | fzf
Source.
I'm running Fedora on a laptop with a small SSD and large HDD. I've got the OS installed on the SSD and my data on the HDD.
All my files are located at /run/media/kennedy/data/Kennedy
What I had before (and want again) is a symlink from /home/kennedy to that location. That way I'm not messing with actual /home, but when I am in /home as normal user, all my things are easily accessed and stored with plenty of space. Right now /home/kennedy has the standard directories; desktop, documents, downloads, and so forth. No files worth worrying about.
So I opened a shell, logged in as su, and entered
ln -s /home/kennedy /run/media/kennedy/data/Kennedy
expecting that when I cd /home/kennedy and ls, I would see all my lovelies. Instead, I see that standard folders and nothing more. Whisky Tango Foxtrot, over.
edit to add: I'm pretty sure the permissions are right, but only pretty sure. How do I check and correct that (if off)?
You have to reverse the arguments:
ln -s /run/media/kennedy/data/Kennedy /home/kennedy
This will:
run successfully if /home/kennedy doesn't exist (kennedy would be the new symlink)
fail if /home/kennedy exists and it is not a directory (symlink or a regular file); need add -f flag in such a case - ls -sf ...
if /home/kennedy is a directory, then the symlink will be created as /home/kennedy/kennedy
See this related post: How to symlink a file in Linux?
You have the command backwards, it should be:
ln -s /run/media/kennedy/data/Kennedy kennedy
Invoke the command while you are in your /home directory, then you should be set.
I ran sudo find -L / -name .rvmrc and got:
/Library/Application Support/Comodo/Antivirus/Quarantine: Permission denied
and also: /dev/fd/3
When I try navigating to the directory I can only get to Application Support, and then from that directory when I run cd Comodo I get Comodo: No such file or directory But it is there if find is finding it right? or no? <<< I believe this is just the find process?
When I try to navigate to it using the finder I just get to Application Support, and Comodo is not there. I am displaying hidden files too. I am trying to remove all files of a certain type so I can get a new program to work properly. This find command suggests one of these files is still out there but I can not get to it.
For /dev/fd/3 why is this being matched? I'm no expert but I just did a quick google search and this is a file descriptor right? Does it even have content? How/Why could it match .rvmrc? When I try looking at it with cat I just get a bad file descriptor error. (Should I extract this into a separate question?)
Thanks for your help.
It looks like your user do not have sufficient privileges to access this Comodo directory.
Try ls -la "/Library/Application Support"/* . This should show who can access Comodo. If it is owned by yourself, then you can do a
chmod +rx "/Library/Application Support/Comodo/"
, then only view its content.
You might have access Quarantine because the find -L followed a link.
Edit
Once you have done this and cannot chmod anymore, then try to see who owns the dir:
ls -lad "/Library/Application Support/Comodo/Antivirus/"*
I downloaded the linux Tor Browser package, which is a self-contained folder. I made a symlink to the run script:
$ ln -s torbrowser/start-tor-browser ~/bin/torbrowser
However, the link was broken upon creation. All I did was run that command, nothing else, and it was broken. I did ls and got:
lrwxrwxrwx 1 synful synful 28 Jul 18 21:52 torbrowser -> torbrowser/start-tor-browser
...which is weird because torbrowser/start-tor-browser had 755 permissions. Also, I ran file:
$ file ~/bin/torbrowser
bin/torbrowser: broken symbolic link to `torbrowser/start-tor-browser'
I made a new bash script and a symlink to it to test this, and had no such problems. I'm not sure why it's only happening with start-tor-browser. It's got normal permissions and is just a normal bash script (even according to the file command).
...any ideas?
It's important to know that
ln -s SOURCE TARGET
create a symlink called TARGET which is symbolically linked to the string SOURCE. If SOURCE is a relative path (that is, it does not start with /), then it is interpreted relative to the directory that TARGET is in. If it is an absolute path, then it's an absolute path. If it is a string which could not be a path, or includes a non-existing path or file, or is otherwise not a valid path string, no matter. ln -s does not check that SOURCE exists or is even a valid path. You could store almost any shortish string you wanted in the dirent.
So when you do this:
$ ln -s torbrowser/start-tor-browser ~/bin/torbrowser
what you are doing is, roughly:
create a directory entry inside your bin subdirectory with name torbrowser.
Make that new directory entry a symbolic link (symlink) to the (relative) path torbrowser/start-tor-browser
The new symlink is a circular. ~/bin/torbrowser is linked to ~/bin/torbrowser/start-tor-browser, which means you have to follow the symlink in order to resolve the symlink. If you try to use it, you'll see:
$ cat ~/bin/torbrowser
cat: /home/joshlf13/bin/torbrowser: Too many levels of symbolic links
$
Sometimes -- often, even -- the ability to symlink to a relative path is extremely handy. A common use is getting rid of version numbers:
$ ln -s apps/my_fancy_app_v2.63.1 apps/my_fancy_app
Now, not only can I call my_fancy_app without remembering its version string, I can also move the entire folder elsewhere, without breaking the symlink:
$ mv apps /usr/local/apps
But other times -- as in your example, I think -- you need to symlink to an absolute path.
As for the permissions, symlinks always have permissions lrwxrwxrwx because the actual permissions used by file operations are the permissions on the real file. (You can think of that as meaning that anyone can follow the symlink, but that's not quite true: they'd also need read permissions for any directory they need to follow. More accurately, anyone who can see the symlink can see the name it points to, even if they have no access to the file with that name.
It is important that the TARGET you specify in
ln -s TARGET LINK_NAME
is full path of the file/directory.
I had this issue, in my case when I cd into target's directory and did
ln -s ./eclipse.ini ~/Desktop/eclipse1 resulted in broken link
But when I did this ln -s $(pwd)/eclipse.ini ~/Desktop/eclipse It worked!
the above usage given for ln:
ln -s SOURCE TARGET
is correct, but confusing when referred to the man page:
ln [OPTION]... [-T] TARGET LINK_NAME (1st form)
as 'TARGET' has different meaning
Note: this can also happen due to permissions
eg. if you try
sudo ln -s /home/somesuperuser/commonfile /home/somenormaluser/commonfile
this would not work, while
sudo mv /home/somesuperuser/commonfile /usr/share/commonfile
sudo ln -s /usr/share/commonfile /home/somenormaluser/commonfile
sudo ln -s /usr/share/commonfile /home/somesuperuser/commonfile
does work
I also struggled with this, I got lots of time Linux sym link broken after creating, but solution is simple - as mentioned by rici:
If SOURCE is a relative path (that is, it does not start with /), then
it is interpreted relative to the directory that TARGET is in.
In other words:
You have this dirs:
- my_directory
-- directory_1
- other_directory
-- *you want your directory_1 link here*
Easiest approach. Got to "other_directory". From there is simple:
ln -s ../my_directory/directory_1 directory_1
Done :)
After searching online, the best solution I've found so far is to just make a symbolic link in either "/Library/logs/" or "~/Library/logs/" to get it to show up in the Console application.
I'm wondering if it would be possible to add a new directory or log file to the "root" level directly under the "LOG FILES" section in the console.
Here's a quick screenshot:
There is one way to get your log files into the console.
You can add a symlink to the log file or log directory to one of the directories in the list. The directory ~/Library/Logs seems like the logical choice for adding your own log files.
For myself I wanted easy access to apache2 logs. I installed apache2 using macports and the default log file is located at /opt/local/apache2/logs.
Thus all I did was create the symlink to that directory.
# cd ~/Library/Logs
# ln -s /opt/local/apache2/logs/ apache2
Now I can easily use the console.app to get to the logs.
My solution for macOS Sierra:
First and last step, you must create a hard link from your source (log) directory into (as example) one of existing official log directories, you can seen in console.app.
I take my ~/Library/Logs directory for that.
hln /usr/local/var/log /Users/dierk/Library/Logs/_usr_local_var_log
Cross-posting this great tool for creating hardlinks originally posted by Sam.
Short intro:
To install Hardlink, ensure you've installed homebrew, then run:
brew install hardlink-osx
Once installed, create a hard link with:
hln [source] [destination]
I actually just came across this option that worked perfectly for me:
Actually if you open terminal and...
$ cd /Library/Logs
then sym-link to your new log directory. eg i want my chroot'ed apache logs as 'www'
$ ln -s /chroot/apache/private/var/log www
then re-open Console.app
drill down into /Library/Logs and you will find your sym-linked directory.
;-)
Mohclips.
http://forums.macosxhints.com/showthread.php?t=35680
In Terminal run this command... append any log file directories you want to add
defaults write com.apple.Console LogFolderPaths -array '~/Library/Logs/' '/Library/Logs/' '/var/log/' '/opt/local/var/log/'
Since Mavericks, symlink behavior as change so "ln - s" doesn't work anymore.
use hardlink-osx instead to create an hardlink to your directory (may be installed via homebrew)
Very old post I know but, this is the only way I could get it to work.
cd /Library/Logs
sudo mkdir log_files
sudo ln -s /Users/USERNAME/Sites/website/logs/* log_files
In mac os 10.11, you may not be able to link to folder of logs, but instead you need to link to each log of logs folder in side console.
ln -s /opt/local/apache2/logs/error_log ~/Library/Logs/Apache2/error_log
You can just open any text file with console.app and it will add and keep it. Folder's though, no luck on that yet.
I was able to hardlink the files into ~/Library/logs by running:
ln /usr/local/var/logs/postgres.log ~/Library/logs
Notice the absence of -s.
No luck for directories though.
OSX Sierra 10.12.6
Just tried to do something similar.
I enter this in terminal, while the Console.app was running.
sudo mkdir -p /usr/local/var/log/apache2
sudo mv /private/var/log/apache2 /usr/local/var/log/apache2/apache2-old
sudo ln -s /usr/local/var/log/apache2 /private/var/log/apache2
Now whenever I open the Console.app it crashes.
Really wish there was a way of adding log files in the files. You CAN do it by dragging and dropping a folder onto the Console.app (given it a directory path as an argument), but the added folder only displays its immediate contents and doesn't allow for recursively descending into folders.
---------EDIT BELOW----------
Nevermind I stupidly did something like this leading to infinite recursion in Console.app
sudo mkdir -p /usr/local/var/log/apache2
sudo ln -s /private/var/log/apache2/apache2 /usr/local/var/log/apache2
sudo mv /private/var/log/apache2 /usr/local/var/log/apache2/apache2-old
sudo ln -s /usr/local/var/log/apache2 /private/var/log/apache2
I don't believe it's possible.
If you're generating log files, you should generate them into one of the standard locations anyway, so this won't be an issue.