Ralph Shumaker wrote: > Ralph Shumaker wrote: >> Carl Lowenstein wrote: >>> On Feb 7, 2008 3:03 PM, Ralph Shumaker <[EMAIL PROTECTED]> wrote: >>> >>>> I decided to move parts of my home directory to a partition where it >>>> would be easy to keep things that I would like to have common to >>>> multiple distributions. I mount that partition as /share. On that >>>> partition I have /share/home/myUser/Pictures (among other directories >>>> like Music and such). I deleted the empty directory ~/Pictures and >>>> created a link ~/Pictures pointing to /share/home/myUser/Pictures. I >>>> don't have any problem, until I finally discovered one. Everything >>>> works as expected (like when I click on the Gnome menu bar Places => >>>> Pictures) except the screensaver. >>>> >>>> I had the screensaver set to show fotos from ~/Pictures, and it *used >>>> to* work. But now it doesn't. It's been a while since I had the >>>> screensaver turned on, so other things I have done may be to blame, but >>>> my suspicion is what I described above. >>>> >>>> Could anyone point me in the right direction? TIA >>>> >>>> Preferably, I shouldn't have to settle for a link *inside* the actual >>>> ~/Pictures directory pointing to the other place (which *did* work). >>>> Everything else seems to be happy with replacing the ~/Pictures >>>> directory with a link to the other place. Why not the screensaver? >>>> >>> >>> What happens if you go to screensaver setup and browse for the >>> directory it uses for pictures? Maybe you have to delete the old >>> information and replace it. Even it if gets replaced with a directory >>> name that looks exactly the same to the naked eye. >>> >>> carl >>> >> >> Screensaver setup gives no such option. It has themes, one of which >> is "Pictures folder". Just for grins, I selected another theme, and >> exited setup. The alternate theme came up. I went back in and >> switched it back to "Pictures folder", but it still doesn't see the >> pictures. >> >> I seem to recall recently stumbling onto a file that identified the >> locations of the Places menu item (on the Gnome desktop menu). But I >> don't recall where that was. Command history won't help me, because I >> was in mc when I viewed the contents of that file. > > I don't have the skills to search contents of files recursively, tho I > didn't do too bad at it just now. I still have too much to learn about > it for it to be useful to me.
I seem to have lost the trend of this conversation, so I haven't trimmed anything above. However, I refuse to let confusion on my part keep me from furthering the thread! ;-) ..anyway.. search recursively is not so daunting a task. The most difficult part is specifying _what_ to search (ie, which files). You can try the gui tools, eg the search-button within nautilus. And if searching for content is a frequent chore, maybe you should look as special tools for that -- isn't that what beagle does? There are probably more But grep does quite a decent job. One of my favorite command line recipes is: grep -slri 'text to search for' /home/jsack/workdir Lookup the options in 'man grep', and it should be understandable. I also frequently add one other option to restrict the files being searched: grep -slri --include='*.py' '^import' /home/jsack/python If your search is really complicated, nothing beats combining the find program with grep. But getting comfortable with find _is_ somewhat intimidating. I thought I recently saw a gui front-end to find, but I can't (umm,) find it just now. > > I didn't find that file using that method. I just went poking around > more or less where I was before and found the file. Somehow, my > rearranging stuff caused a few lines in ~/.config/user-dirs.dirs to be > changed from 'XDG_xxx_DIR="$HOME/yyy"' to 'XDG_xxx_DIR="$HOME/.Trash/yyy"'. > > Problem solved by changing back to: > XDG_Pictures_DIR="$HOME/Pictures" > > Since that works, I will now change back the other 3 lines that got > changed in the same way. > > Interesting that this file somehow was aware of the moves I made to > those directories. But if I move the target of a link, the link is > unaware and becomes broken. The symbolic link feature is a simple mechanism. It merely contains the [path_to/]name of the target and has an attribute-bit set so that the OS knows it is a link. You can see the actual contents by the following. readlink ho stat ho If you delete, rename, or move the target, the link is untouched. I'm not sure if this is a universally accepted term, but I call it a "stale link". You can do more experiments to perhaps fix these ideas in your memory. - - - echo 'hello again' >> hi ln -sf hi ho cat ho rm hi cat ho readlink ho - - - I've added a couple extra options to previous example lines. Extra credit if you figure out what they are, and why I added them. Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-newbie
