6

I considered asking this on Super User, and I also thought that TeX users on the Mac would be better able to help and be helped. I'll let the mods decide.

I opened texdoc color and came to grfguide.pdf. I am greeted with this: alt text
I understand that all default TeX Live packages are installed in a "protected" folder. Using another app (called Afloat), I found out that grfguide.pdf can be found in /usr/local/texlive...

I will want to "process the dtx files" to see further documentation. Now, Spotlight doesn't search the protected folders. I won't be able to just type in sty or dtx or ins. How do I search the TeX Live folders on a Mac?

Kit
  • 16,430

5 Answers5

10

It shouldn't be necessary to compile those files since compiled versions are already included in TeX Live. Say

texdoc -l color

to get access to all parts of the documentation. In this case, select the second document (color.pdf) which is the "developer part" of the documentation.

Philipp
  • 17,641
  • 2
    Thanks to Philipp's posting on the texdoc list, I added aliases so that, starting with the next texdoc update in texlive/mactex, texdoc color-dev will give you the developer doc for color (and similarly for graphics, graphics, and epsfig).

    Of course, using the -l switch when you're not satisfied with the first result is always a good habit.

     – mpg Oct 26 '10 at 21:10
  • Huh. In MiKTeX, when you run texdoc foo (which is actually an alias for mthelp foo or something, I think) and foo has more than one document to choose from, it opens an HTML page listing all of the choices in the default browser. I'm not sure I'm too thrilled with this; sometimes I don't like what my browser will do when I click on one, and sometimes I don't notice that it's done this and wonder what's taking so long. (Though there is a --view flag that will take you straight to the first one, as well as the -l flag you mention, so it's not really a problem either way.) – SamB Feb 05 '11 at 22:06
3

I rather strongly suspect that the reason spotlight doesn't index the texlive folder is that it is inside /usr, which has the "invisible" Finder flag set. You can turn that flag off with xattr, but maybe you don't want to index all of /usr. In which case you could use xattr to set the invisible flag on all subdirectories of /usr except /usr/local, and then turn off the one on /usr. Something like this:

xa="`xattr -px com.apple.FinderInfo /usr`"
for d in /usr/*; do xattr -wx com.apple.FinderInfo "$xa" "$d"; done
xattr -d com.apple.FinderInfo /usr
xattr -d com.apple.FinderInfo /usr/local

A much simpler fix would be to move /usr/local/texlive to a new place and insert a symlink in the original location. That might give you trouble when you wish to install texlive 2011, though, unless you remember to move it back first. So playing around with xattr seems safer. (The only documentation of xattr seems to be the one you get by running xattr --help.

Harald Hanche-Olsen
  • 15,968
  • 1
    +1, I am certain your reasoning is correct, and I've used this trick myself (usually to hide things from Spotlight). I recommend /Users/Shared/texlive as the target of the symlink. I can't think of any reason why installing the new Texlive across this symlink would cause problems: it's a completely standard technique used by UNIX sysadmins. The only thing to watch for is permissions. – Charles Stewart Oct 27 '10 at 07:24
  • @Charles, then maybe we could suggest that future versions of TeX Live to be installed in a Spotlight-accessible folder? – Kit Oct 27 '10 at 08:30
  • @Kit: I wouldn't like that. I want things to be in exactly the same place on both my Mac OSX and Linux machines. Doing just this is high up on the things I like about the way Texlive does things. – Charles Stewart Oct 27 '10 at 08:49
  • @Charles, I could try out your method then. It looks good just as well. Blame my suggestion on my limited experience :) – Kit Oct 27 '10 at 10:01
  • What, no xattr(1) or xattr(8)? What kind of lousy excuse for a *nix ... wait, what are you talking about, there is so an xattr(1)! (Now what I want to know is how Google found a page with a # in the URL...) – SamB Feb 05 '11 at 22:14
  • @SamB: Okay, so there's an xattr(1) on the web, but it's not included with the system. The man page doesn't hold a any more information than the --help output anyhow. Apple's habit of looking at the bit after the # to decide what contents to serve has had me puzzled too, as it seems to skirt the boundaries of how http is supposed to work. But evidently, google's search robot is aware of this behaviour. – Harald Hanche-Olsen Feb 05 '11 at 22:58
2

The most GUI-friendly way is to navigate to /Library/TeX/Documentation (or perhaps /Library/TeX/Root) and then use the Finder's search box to find what you're interested in.

Access to these "hidden" folders is enabled with symlinks for exactly this reason.

Will Robertson
  • 73,872
1

I don’t have a Mac. Maybe locate .dtx works. If not, you might try find /usr -name '*.dtx' (both on the command line, the second command might be somewhat slow as it doesn’t use an index).

Caramdir
  • 89,023
  • 26
  • 255
  • 291
  • Yes, locate works fine on a Mac; this is how I routinely find source of installed packages when I want to look at it. – Alan Munn Dec 31 '10 at 17:56
1

They should be in something like

/usr/local/texlive/2010/texmf-dist/source/

Using find from that path should be able to help you find them. In particular the ones you're looking for are under latex/graphics.

Juan A. Navarro
  • 62,139
  • 32
  • 140
  • 169