¿Usando el comando sudo en el script de shell en la aplicación Automator?

Estoy planeando hacer una pequeña aplicación de Automator para convertir estos comandos en algo que pueda ejecutar con regularidad:

rm -rf ~/Library/Caches/*
rm -rf ~/Library/Saved\ Application\ State/*
sudo rm -rf /Library/Caches/*
sudo rm -rf /System/Library/Caches/*
atsutil databases -removeUser
sudo atsutil databases -remove
sudo atsutil server -shutdown
sudo atsutil server -ping
sudo rm -rf /var/folders/*

Dado que implica sudo, que entiendo que es un comando peligroso, ¿se recomienda esto para alguien nuevo en Automator y no dañará la Mac?

Probé el comando sugerido en iMac que no se apaga desde que actualicé a OS X 10.11, El Capitan para solucionar problemas con el apagado de mi Mac (es MacOS Sierra 10.12.6 en una Mac Mini antigua).

Agradecería cualquier consejo sobre esto, ya que conozco los conceptos básicos de Automator, solo si se recomienda hacerlo con los comandos sudo como una aplicación de Automator.

En su lugar, haga un script de shell, que también pregunte y/n antes de hacer cosas.

Respuestas (2)

Sudo no es (en sí mismo) peligroso. Sudo simplemente elimina las restricciones de protección, poniendo la carga de ejecutar un código seguro en usted, en lugar de protegerlo detrás de escena. Sudo puede ser peligroso cuando, por ejemplo:

  • Comete un error de codificación que tiene consecuencias no deseadas: por ejemplo, si tiene la intención de ejecutar:

    • sudo rm -Rf /Users/yourname/something/something/

      pero en su lugar escribes:

    • sudo rm -Rf /Users/yourname/ something/something/

      (con un espacio accidental después de 'tunombre')

    la segunda secuencia de comandos (con el espacio erróneo) eliminará todos los datos del usuario 'tunombre' sin previo aviso.

  • Ejecutas el código de otra persona que resulta ser malicioso. El código malicioso que se ejecuta sin sudo puede causar algún daño, pero el código malicioso que se ejecuta con sudo puede comprometer su sistema por completo.

Siempre que tenga cuidado, sudo es lo suficientemente seguro. Solo tenga en cuenta los posibles daños.

Yo diría que lo que describiste es "peligroso". Pararse en la cima de un acantilado es "peligroso", pero eso no significa que sea "dañino", solo significa que debe tener cuidado. Y si eres cauteloso, no debes dejar que el peligro te impida disfrutar de la vista.
@Wowfunhappy — Eh, tomayto-tomahto. Veo tu punto, aunque parece mera semántica.

sudoSer peligroso

No hay comandos peligrosos, per se. Es lo que haces con ellos lo que puede causar problemas. Por ejemplo, el comando inofensivo yesque generará una cadena repetidamente hasta que la elimine, puede usarse de manera nefasta para hacer que una máquina se arrastre:

echo "Spawning 1000 yesses"
for i in {1..1000} ;
do
  ( /usr/bin/yes & )
; done

Nada allí es peligroso. Es cómo se usa lo que causa el problema.

sudono otorga ni elimina permisos/restricciones en su cuenta. Le permite ejecutar un comando como otro usuario. Este suele ser el superusuario (también conocido como root), por lo tanto, el comando - su "do" ( su= Identidad de usuario sustituta )

La clave para recordar es que cuando ejecuta un comando con el prefijo, sudolo está ejecutando como root y no como "usted".

Arreglando tu Script

Aquí hay algunos consejos...

  • Ejecute el script en sí (no los comandos individuales) con sudo.
  • Antes de ejecutar la "carne" del script, primero verifique los privilegios de root:

    # Validates that user is root; exits if not
    echo "Checking Root Priviliges"
    if [ $(id -u) -ne 0 ]
    then 
      echo "User is not root"
      exit 1;
    else 
      echo "User is root.  Continuing";
    fi
    
  • No use la expansión de tilde (~) para su ruta. Utilice la ruta completa en su lugar. Esto asegurará que está afectando el directorio que desea afectar. El directorio de inicio para usted es muy diferente del directorio de inicio raíz.

    rm -rf ~/Library/Caches/*                  ← Don't do this!!!
    rm -rf /Users/FooBarUser/Library/Caches/*  ← Do this instead!
    
  • Si planea automatizar esto (suena como si lo hiciera), deberá guardarlo como un script (bash o zsh) y luego sugiero usar launchdy no Automator para esto. Consulte el formato plist posterior al lanzamiento para ejecutar un comando en un momento específico en un día laborable para obtener detalles sobre cómo lograr esto.