¿Te gusta resolver problemas con hacks terribles? Me gusta resolver problemas con hacks terribles.
Lo siguiente evitará este comportamiento en una máquina que ejecute 10.13 High Sierra con la protección de la integridad del sistema desactivada .
Instrucciones
-
Cree un nuevo archivo /Library/scripts/Fix-Applications-Folder.sh con el siguiente contenido:
!/bin/bash
function main {
while [[ $(pgrep Finder) -eq "" ]] ; do sleep 1 ; done
mv /Applications /Apps
sleep 1
killall Finder
sleep 1
mv /Apps /Applications
}
main &
-
Haz que el archivo sea ejecutable: sudo chmod +x /Library/Scripts/Fix-Applications-Folder.sh
-
Añade el script como gancho de inicio de sesión : sudo defaults write com.apple.loginwindow LoginHook /Library/Scripts/Fix-Applications-Folder.sh
Salga y entre, y al arrastrar las aplicaciones fuera de /Applications se comportará como cualquier otra carpeta de su máquina.
¿Qué ocurre?
Este truco aprovecha una peculiaridad de Finder que he descubierto: Si cambias el nombre de la carpeta Aplicaciones por otro y vuelves a iniciar Finder, el comportamiento especial del alias de la carpeta desaparecerá, y esto persiste incluso una vez que el nombre de la carpeta ha sido cambiado de nuevo a "Aplicaciones". Los efectos duran hasta la próxima vez que se reinicie el Finder, lo que normalmente no ocurrirá hasta que se cierre la sesión o se reinicie.
Así, las instrucciones anteriores crean un script que automatiza este proceso, y configuran un gancho de inicio de sesión para ejecutar ese script cada vez que un usuario inicia sesión. El scriptespera a que se inicie el Finder, y luego renombra /Applications
a /Apps
y mata a Finder. Una vez que Finder se ha reiniciado, la carpeta se renombra de nuevo a /Applications.
PREGUNTAS Y RESPUESTAS
¿Causa esto algún efecto secundario?
Hasta ahora no he encontrado ninguno. La carpeta de Aplicaciones conserva su bonito icono, y al ejecutar path to applications folder
en Applescript seguirá devolviendo el resultado correcto.
¿Funciona esto en otras versiones de Mac OS X?
No lo he probado en Mojave ni en Catalina, pero sospecho que funcionará sin cambios en Mojave. En Catalina, como mínimo tendrías que volver a montar /
como lectura-escritura; puede intentar añadir sudo mount -uw /
antes de la última línea del script.
Este método hace no funcionan en 10.9 Mavericks, que no presenta la peculiaridad del Finder que he descrito anteriormente. No sé qué pasará en 10.10-10.12, habría que probarlo.
¿Puedo hacerlo sin desactivar el SIP?
No, y también tendrás que dejar el SIP desactivado. Todo el propósito de SIP es evitar que los usuarios hagan cosas como esta.
Los loginhooks están obsoletos, ¿por qué no usaste launchd?
Los Loginhooks tienen dos propiedades muy útiles:
- Se ejecutan siempre que un usuario se conecta (no sólo cuando el sistema arranca)
- Funcionan como Root.
Los LaunchAgents sólo consiguen el número 1, y los LaunchDemons sólo el número 2. Dicho esto, la ejecución del script como LaunchDemon casi funcionan, el único problema es cuando un usuario se desconecta y vuelve a conectarse (o un segundo usuario se conecta).
Tenga en cuenta que, según Apple, su máquina sólo puede tener un Loginhook a la vez. Así que en el caso de que ya tengas un Loginhook configurado para otra cosa, tienes que añadir el código a tu script existente en lugar de crear uno nuevo.
¿Por qué pasar por todo este problema? No puedes simplemente mantener el cmd
¿clave?
Me doy cuenta de que estoy siendo un poco loco, pero esto me ha molestado legítimamente durante años. No me gusta su incoherencia. /Applications
es sólo una carpeta, y maldita sea, debería comportarse igual que cualquier otra carpeta. Este comentario que dejé en Hacker News hace un tiempo también puede proporcionar una idea de por qué estoy tan molesto por el comportamiento: https://news.ycombinator.com/item?id=20224370
Tal vez nadie más use esto, pero quería tener la solución documentada. (Sólo deseo que funcione en Mavericks-estoy tratando de mover mi vida a Mavericks).
0 votos
Mojave ha hecho