Come posso accelerare Terminal.app o iTerm su Mac OSX?

Ogni volta che lancio iTerm o Terminal dopo che non lo uso per poche ore, ci vuole da 10-20 secondi per restituire un prompt. Lo schermo è vuoto e, anche se posso digitare, non posso effettivamente eseguire alcun command.

Se chiudo un'applicazione, i lanci successivi (se praticati relativamente poco dopo) sono abbastanza veloci. La lentezza sembra solo verificarsi se l'applicazione non è in esecuzione per poche ore.

Sto eseguendo OSX 10.5.7 su un MacBookPro. Ho la stessa impostazione su un altro computer, senza rallentamenti.

Qualche idea come accelerare le cose?

Provare a eliminare i file di registro di sistema di Apple in /var/log/asl/ :

 sudo rm /var/log/asl/*.asl 

Questo mi ha fatto il trucco.

Un altro suggerimento potrebbe essere utile:

Modificare l'avvio della shell da default /usr/bin/login a /bin/bash -l , oppure /usr/bin/zsh se si utilizza zsh.

Questo potrebbe rendere il vostro Terminal / iTerm2 lanciare in velocità di luce!

  • Per Terminale: Preferenze → Avvio: Modifica da "Predefinito shell di login" in "Comando: /bin/bash -l "

  • Per iTerm2: Preferenze → Profili → Generale → Comando: Cambi da "Login Shell" a "Comando: /bin/bash -l "

Ho bisogno di una certa reputazione per commentare i post? Comunque cancellare i registri di sistema lo faceva anche per me, grazie. Ho cercato di patch path_helper con la patch qui: gist.github.com/123525, come suggerito in un commento su http://mjtsai.com/blog/2009/04/01/slow-opening-terminal-windows/ ( riferito in precedenza in questo thread) ma senza alcun risultato. Ottengo un errore criptico. Tuttavia, tale patch dovrebbe accelerare il lancio di terminal.app.

aggiunta: Come ho detto, cancellare i registri ha fatto il trucco per me, ma il problema continua a emergere come i registri continuano a crescere più dopo averli rimossi. Ho scoperto che il "tweaking" /etc/asl.conf mi ha dato una soluzione più permanente. La modifica è quella di registrare solo i messaggi che sono classificati come "critici" o più critici di quello, al contrario della categoria "avviso" di logging e tutti più critici di quello. Inoltre, ignoro i messaggi da ftp, mail, local0, local1. Ecco una pasta del mio /etc/asl.conf:

  ## # configuration file for syslogd and aslmanager ## # redirect com.apple.message.domain to /var/log/DiagnosticMessages ? [T com.apple.message.domain] store_dir /var/log/DiagnosticMessages exclude_asldb # authpriv messages are root/admin readable ? [= Facility authpriv] access 0 80 # remoteauth critical, alert, and emergency messages are root/admin readable ? [= Facility remoteauth] [<= Level critical] access 0 80 # broadcast emergency messages ? [= Level emergency] broadcast # save kernel [PID 0] and launchd [PID 1] messages ? [<= PID 1] store # save everything from emergency to notice #? [<= Level notice] store ? [<= Level critical] store # save lpr info level and above #? [<= Level info] [= Facility lpr] store # save all mail, ftp, local0, and local1 messages #? [= Facility mail] store #? [= Facility ftp] store #? [= Facility local0] store #? [= Facility local1] store 

Da un articolo che ho letto un paio di settimane fa: Windows Slow Opening Terminal

/usr/libexec/path_helper è terribilmente lento al caricamento /etc/paths Se rimuovi tutte le voci in /etc/paths e assicura che quegli elementi siano disponibili nel tuo .bash_profile questo risolverà il problema. Mi ha comunque fatto per me.

Se l'applicazione terminal è stata caricata, ma non hai ancora un prompt, allora è la tua shell che prende un po 'di tempo per inizializzare.

Ciò probabilmente significa che hai troppo o qualcosa di molto tempo nel tuo .bashrc ( supponendo che utilizzi bash ).

La mia ipotesi è che nel tempo, qualcosa stia usando un sacco di memory. Quando si avvia un terminal dopo che non viene utilizzato per un po ', è necessario disporre di una memory scambiando il suo contenuto su disco. Se si uccide il process terminal e la riavvia relativamente rapidamente, la memory è ancora disponibile e si avvia rapidamente. Questo dovrebbe accadere anche con altre applicazioni.

È necessario monitorare l'utilizzo della memory con Activity Monitor e vedere se è ansible indicare where si trova.

Una soluzione più permanente da modificare sudo vi /etc/asl.conf è fornita qui .

Aprire /etc/profile e aggiungere la linea PATH="" modo da assomigliare a questo:

 if [ -x /usr/libexec/path_helper ]; then PATH="" eval `/usr/libexec/path_helper -s` fi