Can't mv or cp to /usr/share/dict

El Capitan implimented SIP (System Integrity Protection), which means you cannot modify any of the system files or folders. Not even using the 'sudo' command.

<https://en.wikipedia.org/wiki/System_Integrity_Protection>

<About System Integrity Protection on your Mac - Apple Support>

If you had things in any of the SIP protected directories before upgrading to El Capitan, they would have been moved or deleted.

If you want more information about SIP, Google will give you lots of articles about it, and even if you want to disable it. But, you can bet the next time you upgrade OS X, it will clean out anything in SIP protected directories, just like it did during the El Capitan upgrade.

The contents of /usr/share/dict are ancient, so it's not surprising you have some updates.

Depending on what you're up to, use /usr/local/share/dict — particularly if whatever tool you're using supports looking there either in place of or in addition to looking in the system location — or maybe use the system dictionaries over in /Library/Dictionaries. The latter has APIs and related pieces available, and there are examples.

And yes, you're going to run into SIP for this case, and at each upgrade.

Might also want to toss a bug report or an enhancement request at Apple or whoever is maintaining the tool(s) you're using here, if they can't properly contend with /usr/local/share/dict, too.

Tailgating MrHoffman, here is where you (sudont) would file bug reports:

BugReporter

<http://bugreporter.apple.com>

Free ADC (Apple Developer Connection) account needed for BugReporter.

Anyone can get a free account at:

https://developer.apple.com/register/index.action

sudont wrote:

So, only

/usr/local/*

is truly user space now? That is to say, the only directory where I can put stuff and expect it to remain across Apple updates?

Really, I've never understood why any System files are anywhere in

/usr

. It seems to me that, as the name implies, it should be the unix equivilent of the Home directory. But, what do I know?

you have to go back to the late 60's and early 70's to understand how all this evolved.

Disks were small (a 1 megabyte disk in those days was HUGE). You either had multiple disks, or you partitioned the disk. You needed one partition for swap, and one partition for the boot files and / (the file system root).

I'm sure that initially everything was in /bin, after all Unix was small, it ran on a PDP-11 with 64 kilobyte address space. Then they put user files on the /usr mount point.

But over time more apps came along, and they created a /usr/bin (maybe because it had more space than the boot partition and/or maybe because these were programs created by users - I do not know). But that established the pattern that has been Unix for years and years. Trying to change it is really not worth the effort.

If you want to get inside the heads of some of the early Unix developers, then you need to find the "Bell System Technical Journal (Unix System) Vol. 57 / PP. 1897-2312 / July-Aug 1978". You might even find it on-line, but as Bell Labs has changed hands and the Bell System Technical Journal copyright ownership is most likely all confused by now. But you can learn a lot about the early days from the people that created Unix (Ken Thompson, Dennis Ritchie, Brian Kernighan, Steven Bourne, etc...).

Here's the usual reading...

The first is the general discussion and overview and how Apple stores stuff:

https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/ FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_re f/doc/uid/TP40010672-CH2-SW6

And the pathname discussion is where most Unix and Unix-like systems park their various files and parts:

http://www.pathname.com/fhs/pub/fhs-2.3.html

And then there's what Apple states is available to developers as part of System Integrity Protection:

https://developer.apple.com/library/mac/documentation/Security/Conceptual/System _Integrity_Protection_Guide/Introduction/Introduction.html

Also see man hier for some related details.

It's been preferred to park add-on stuff in /usr/local for a while now for most Unix and Unix-like systems, irrespective of OS X and SIP. Or to treat the particular package as an application bundle, and to place the software (bundle) in /Applications, of course.

There's been a running debate over whether to use /usr/local and /opt for "stuff", but OS X and various other Unix and Unix-like distros have gone to /usr/local and not /opt.

sudont wrote:

Right. Macports creates an /opt directory. I had been using /usr/bin when I compiled unix apps, but I see now that /usr/local/bin is in my path, and I probably should've been using that. ...

FWIW and with OS X, for a wordlist or related data, locating the files somewhere underneath /User/Shared/ or somewhere underneath your own login directory (/User/yourshortname, also accessible via ~) would be more typical. These directories areas are out in the areas that the GUI can see and access.