0 votos

¿Cómo puedo modificar /System/Library/ScriptingDefinitions/CocoaStandard.sdef y que los cambios persistan?

Estoy tratando de modificar /System/Library/ScriptingDefinitions/CocoaStandard.sdef . Quiero hacer esto porque muchas aplicaciones hacen referencia a este archivo en sus propias definiciones de scripts, y quiero experimentar con la adición de nuevas cosas que tendrán efecto en cada aplicación. Dado que las entradas de las definiciones de scripting se asignan directamente a los objetos de Cocoa y sus métodos, me imagino que esto sería una manera eficaz de meterse con los objetos de otras aplicaciones.

He reiniciado el sistema operativo de recuperación y he ejecutado los siguientes comandos en un terminal:

csrutil disable
umount "/Volumes/Macintosh HD"
mkdir /Volumes/mhd
mount /dev/disk3s1 /Volumes/mhd
cd /Volumes/mhd/System/Library/ScriptingDefinitions
mv CocoaStandard.sdef CocoaStandard.sdef.original
ln -s /Library/ScriptingDefinitions/CocoaStandard.sdef .
reboot

Tenga en cuenta que ya he colocado una copia de CocoaStandard.sdef en /Library/ScriptingDefinitions .

El problema con el que me encuentro es que, a pesar de desactivar la Protección de Integridad del Sistema, una vez que reinicio en MacOS, los cambios que hice en /System/Library/ScriptingDefinitions se han revertido de alguna manera. No hay CocoaStandard.sdef.original y CocoaStandard.sdef es, una vez más, un archivo normal y no un enlace simbólico.

¿Cómo puedo evitar que se reviertan estos cambios? Alternativamente, si hay una mejor manera de agregar definiciones de scripting personalizadas a las aplicaciones existentes, eso también funcionaría. (Intenté añadir directamente entradas al .sdef dentro de una copia de la aplicación, pero luego, cada vez que intento controlar esa copia de la aplicación usando AppleScript, obtengo el error -1728).

0voto

bobince Puntos 270740

Luego leí que (como apuntaba @red_menace en los comentarios) el comportamiento era causado por el volumen del sistema sellado. No he hecho esto, pero csrutil authenticated-root disable en el terminal de recuperación debería evitar que se produzca. Pero según esta página Pero hay varias razones por las que no es deseable, sobre todo si se trata de algo que puede lograrse de otras maneras.

Específicamente, la manera que encontré que funciona fue crear una imagen de disco en la Utilidad de Discos, y luego montarla en /System/Library/ScriptingDefinitions . Esto reemplazará temporalmente el contenido del directorio con el contenido de la imagen de disco sin modificar realmente nada en el disco. Los pasos básicos para hacerlo son

  1. Abra la Utilidad de Discos.
  2. Archivo->Nueva imagen->Imagen en blanco...
  3. Establece un tamaño de archivo menor (yo usé 16 MB, aunque incluso eso es mucho) y guarda la imagen del disco. La guardé en el escritorio como ScriptDefs.dmg.
  4. Coloque el CocoaStandard.sdef modificado en la imagen de disco montada y expúlselo.
  5. Terminal abierto.
  6. hdiutil attach ~/Desktop/ScriptDefs.dmg
  7. Mira la lista que aparece y busca el /dev/disk#s# que figuran en la parte inferior.
  8. sudo mount -t apfs -o nobrowse /dev/disk#s# /System/Library/ScriptingDefinitions (sustituyendo disk#s# con los valores de arriba)

Según mis pruebas, esto fallará (comprensiblemente) con un error de "permiso denegado" si la Protección de Integridad del Sistema está activada, así que tendrás que desactivar eso primero. Además, no crees un DMG comprimido, porque por alguna razón eso fallará con el mismo error incluso si el SIP está desactivado.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X