Ich habe ein seltsames Problem mit meinem neuen MacBook Pro (Ende 2016, Touch Bar).

Es funktioniert einwandfrei und nach einer Weile funktioniert das Öffnen neuer Terminal-Fenster nicht, weil es loginhängt. Ein Neustart behebt das Problem.

Dies scheint ein Problem zu sein, das einige andere Leute hatten, also habe ich bereits alle ihre Lösungen ausprobiert (von 1 und [2] ):

1. Entfernen ~/Library/Preferences/com.apple.Terminal.plist
2. Meine Standard-Shell auf eine andere Shell setzen (von /bin/zshbis /bin/shoder /bin/bash)
3. Das Entfernen oder Reinigen meine .profile, .zprofile... Das funktioniert nicht , und ich kann bestätigen , dass das Problem auftritt , bevor die Schale selbst aufgerufen wird, denn wenn ich echo HEYals erste Zeile meines .zshenvdies nicht einmal erreicht. Es muss logindie Probleme verursachen. Das Bearbeiten /etc/profile, um ein Echo oben hinzuzufügen, zeigt ebenfalls nichts an
4. Das Ändern der Run command:Einstellung in meiner Terminal-Konfiguration in so etwas wie echo foofunktioniert auch nicht (wenn Run inside shellaktiviert oder deaktiviert bleibt, ändert sich nichts).

Weitere Hinweise:

• Wie [2] , ssh-add -Kbesteht keine Tasten zwischen Neustarts, etwas , das ich nie hatte Probleme mit vor.
• Die Konsole zeigt keine verdächtigen Fehler oder Warnungen an.
• Das Öffnen eines neuen TerminalFensters scheint eine tty-Datei ( /dev/ttys<number>) zu erzeugen .
• In diesem Fall spielt es keine Rolle, ob ich Terminal.app oder iTerm.app verwende
• Ich habe eine ziemlich saubere Installation (habe gerade meinen Laptop, habe keine Backups wiederhergestellt, habe nur einige Apps mit brew installund installiert brew cask install).

Das ist wirklich schwer zu debuggen, weil ich es nicht reproduzieren kann und oft kein neues Terminal öffnen kann, um überhaupt herauszufinden, was los ist.

Hat jemand irgendwelche Tipps?

Aktualisieren:

Mit iTerm konnte ich eine Shell erhalten, indem ich den Befehl start auf setze /bin/bash. In dieser Shell sudofunktioniert das allerdings nicht. Es hängt (ohne die Eingabeaufforderung anzuzeigen) ctrl-Cund ctrl-Dmacht keine Arbeit, wenn es hängt.

Die Verwendung einiger anderer Programme funktioniert in dieser Shell ebenfalls nicht: nodeoder /usr/local/bin/nodebeide hängen. Soweit ich das beurteilen kann, befinden sich Programme in /usr/local/bin.

Update 2:

brew list --full-name Ergebnisse in diesen Paketen:

autoconf
automake
blueutil
boost
cabal-install
cairo
cfssl
cmake
coreutils
doxygen
editorconfig
erlang
ffind
ffmpeg
flow
fontconfig
fontforge
freetype
gdbm
gettext
ghc
git
glib
go
gobject-introspection
graphicsmagick
harfbuzz
haskell-stack
highlight
icu4c
influxdb
jemalloc
jpeg
keybase
lame
libevent
libffi
libpng
libtermkey
libtiff
libtool
libuv
libvterm
libxml2
lua
mongodb
msgpack
nginx
node
openssl
openssl@1.1
pango
pcre
pixman
pkg-config
postgresql
protobuf
python
python3
rabbitmq
readline
reattach-to-user-namespace
redis
sqlite
the_silver_searcher
thefuck
tmux
unibilium
unixodbc
wxmac
x264
xvid
xz
yarn
z
zsh
josegonzalez/php/php54
neovim/neovim/neovim

Update 3:

Diese Punkte stimmen mit der Antwort von @ Monomeeth überein:

1. In diesem loginFall wird ein Element im Aktivitätsmonitor angezeigt. (Erzwingen) Beim Beenden wird auch das hängende Terminalfenster geschlossen. Durch manuelles Schließen des Fensters wird der loginVorgang im Aktivitätsmonitor nicht beendet.

2. Der Titel des Terminals ist Terminal — login — term big — ttys001 — 89x18 — ⌘1, wo term bigder Name der Einstellungen ist.

3. sudoIm Aktivitätsmonitor wird kein Prozess angezeigt. Ich kann einen sudoProzess erstellen , indem ich iTerm.app öffne (was bash verwendet) und sudo echo okdort laufe . Es kann nicht Beenden sein, aber Force Quit funktioniert und beendet es:

   bash-3.2 $ sudo echo ok Getötet: 9

Update 4:

Wenn es passiert, funktioniert das Ausführen loginvon einer Shell, die noch verfügbar ist , während die loginneueren Shells zu hängen scheinen.

Update 5:

Ich habe kürzlich einen neuen Laptop bekommen (MacBook Pro 2017, keine Touch Bar) und das Problem besteht weiterhin.

Ich habe auch die Shells gewechselt: Ich verwende jetzt fisheine hübsche Vanille-Konfiguration. Ich denke, das schließt die Muschel als Schuldigen aus.

Das Betriebssystem wurde ebenfalls auf 10.13.3 (17D47) High Sierra aktualisiert.

Ich habe versucht, so wenig wie möglich auf diesem Computer zu installieren:

brew list —-full-names

coreutils 8.29
dnsmasq 2.78
faac 1.29.9.2
fdk-aac 0.1.5
ffmpeg 3.4.1
fish 2.7.1
freetype 2.9
gdbm 1.14.1_1
gettext 0.19.8.1
git 2.16.1
highlight 3.42
htop 2.0.2_2
icu4c 60.2
imagemagick 7.0.7-22
jemalloc 5.0.1
jpeg 9b
lame 3.100
libav 12.2
libogg 1.3.3
libpng 1.6.34
libtermkey 0.20
libtiff 4.0.9_1
libtool 2.4.6_1
libuv 1.19.1
libvorbis 1.3.5_1
libvpx 1.7.0
libvterm 681
libyaml 0.1.7
lua 5.3.4_2
luajit 2.0.5
mongodb 3.6.2
msgpack 2.1.5
neovim 0.2.2
node 9.5.0
openssl 1.0.2n
opus 1.2.1
parallel 20180122
pcre 8.41
pcre2 10.30
postgresql 10.2
python 2.7.14_3
python3 3.6.4_2
readline 7.0.3_1
ripgrep 0.7.1
ruby 2.5.0
sqlite 3.22.0
the_silver_searcher 2.1.0
thefuck 3.25_1
unibilium 1.2.1
x264 r2795
xvid 1.3.5
xz 5.2.3
youtube-dl 2018.02.08

Nicht sicher, was das jetzt sein kann. Die einzigen Apps, an die ich denken kann, sind Divvyoder Apptivateda sie beide veraltet scheinen. Dies ist der Schnittpunkt zwischen dem, was auf der alten und der neuen Maschine installiert wurde:

coreutils
ffmpeg
freetype
gdbm
gettext
git
highlight
icu4c
jemalloc
jpeg
lame
libpng
libtermkey
libtiff
libtool
libuv
libvterm
lua
mongodb
msgpack
node
openssl
pcre
postgresql
python
python3
readline
sqlite
the_silver_searcher
thefuck
unibilium
x264
xvid
xz

Update 6:

Hier ist auch ein Screenshot:

Update 7:

Meine Umgebung sieht normalerweise so aus:

Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.k60Nf5UBfq/Render
DISPLAY=/private/tmp/com.apple.launchd.6FMoWPSlJI/org.macosforge.xquartz:0
EDITOR=env VIRTUAL_ENV= nvim -u /Users/john-doe/.config/vim/vimrc -p
GNUTERM=X11
HOME=/Users/romeo
HOMEBREW_NO_EMOJI=1
HOMEBREW_PREFIX=/usr/local
LANG=en_GB.UTF-8
LESS=-RI
LESSHISTFILE=-
LOGNAME=romeo
LS_COLORS=di=00;31:ex=00;37:mi=00;41;30:tw=00;33
MANPATH=/usr/local/opt/coreutils/libexec/gnuman
PAGER=less
PATH=/Users/john-doe/.config/fisherman/re-search:/usr/local/opt/python/libexec/bin:/usr/local/opt/ruby/bin:/usr/local/opt/coreutils/libexec/gnubin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/MacGPG2/bin
PWD=/Users/romeo
SECURITYSESSIONID=186a8
SHELL=/usr/local/bin/fish
SHLVL=1
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.fQn5sHMuZP/Listeners
TERM=xterm-256color
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=400
TERM_SESSION_ID=D2AF7A50-8B41-4793-9201-8304A02C9B29
TMPDIR=/var/folders/15/zcyyfw_x7638z7vfg5zd85z40000gn/T/
USER=romeo
XDG_CACHE_HOME=/Users/john-doe/.cache
XDG_CONFIG_HOME=/Users/john-doe/.config
XPC_FLAGS=0x0
XPC_SERVICE_NAME=0

Wie Sie sicher wissen, handelt es sich bei der Fehlerbehebung um einen Prozess der Beseitigung, der häufig ein wenig Geduld erfordert. Ich würde gerne ein paar Dinge ausprobieren, um dem auf den Grund zu gehen.

1. Bestätigen Sie, dass es während der Anmeldung hängt

Wenn der Prozess, an dem er hängt, tatsächlich während der Anmeldung stattfindet , bedeutet dies, dass der Prozess immer noch darauf wartet, eine Anmeldesitzung zu erstellen. Angenommen, dies ist der Fall, dann hätte es noch nicht versucht, die Shell zu starten.

Um dies zu bestätigen, starten Sie Activity Monitor beim nächsten Auftreten dieses Problems, um zu überprüfen, ob die Shell ausgeführt wird oder ob nur ein Anmeldevorgang angezeigt wird.

Sobald Sie die Gelegenheit dazu hatten, melden Sie sich mit dem, was Sie gefunden haben.

HINWEIS: - Wenn andere Terminals offen sind, überprüfen Sie den entsprechenden Vorgang. Ich vermute, dass der Hängeprozess der Prozess mit der höchsten Prozess-ID (PID) ist.

2. Wie lautet der Titel des Terminals?

Wenn Sie das nächste Mal dieses Problem haben, können Sie den Titel des Terminalfensters notieren und einen Bericht erstellen?

3. Töte sudo

Sie geben an, dass ein Neustart Ihres MBP dieses Problem immer behebt.

Wenn Sie jedoch das nächste Mal dieses Problem haben (möglicherweise nachdem Sie das getan haben, was ich oben unter 1 beschrieben habe), möchten Sie, dass Sie versuchen, sudo über Activity Monitor zu beenden.

Sobald Sie dies versucht haben, lassen Sie uns wissen, was passiert.

4. Versuchen Sie, Ihre .bash * -Dateien zu verschieben

Möglicherweise befindet sich in Ihrem Benutzerverzeichnis (aus verschiedenen Gründen) eine .bash_profile-Datei, die zeitweise Probleme verursacht. Dies ist Ihnen vielleicht nicht einmal bewusst, aber Sie können Automator verwenden, um ein Skript auszuführen, das alle .bash-Dateien findet und verschiebt.

Hier ist ein Beispielskript dafür:

cd ~

mkdir moved
for F in .bash*
do
    mv $F moved
done

Dieses Skript verschiebt alle Dateien, die mit .bash in Ihrem Home-Ordner beginnen, in einen neu erstellten verschobenen Unterordner.

Überprüfen Sie nach dem Ausführen des Skripts diesen Ordner und teilen Sie uns mit, ob sich tatsächlich Dateien darin befinden.

HINWEIS: - Sie können den neuen Unterordner beliebig benennen. Ändern Sie dazu einfach die beiden Vorkommen von " Verschoben" im Skript in die Bezeichnung, die Sie verwenden möchten.

[AKTUALISIEREN]

Noch ein paar Dinge zum Ausprobieren.

5. Versuchen Sie, die * .asl-Dateien zu löschen

Falls noch nicht geschehen, löschen Sie die * .asl-Dateien. Verwenden Sie dazu Folgendes:

sudo rm -rf /private/var/log/asl/*.asl

HINWEIS: - Dies kann einige Zeit dauern, da eine neue Shell erstellt wird. Wenn Sie fertig sind, stellen Sie sicher, dass Sie das Terminal vollständig verlassen, damit die Änderungen wirksam werden.

6. Abgesicherter Modus

Bemerken Sie einen Unterschied im Verhalten, wenn Sie Ihren MBP im abgesicherten Modus starten? So starten Sie im abgesicherten Modus:

1. Fahren Sie Ihren Mac vollständig herunter
2. Starten Sie Ihren Mac neu
3. Drücken Sie sofort die ShiftTaste und halten Sie sie gedrückt
4. Lassen Sie die ShiftTaste los, wenn Sie das Anmeldefenster sehen (HINWEIS: Wenn Sie FileVault aktiviert haben, müssen Sie sich möglicherweise zweimal anmelden).
5. Versuchen Sie nach dem Start von MBP, Terminal zu verwenden, und prüfen Sie, ob Sie das Problem noch replizieren können.
6. Wenn Sie fertig sind, können Sie den abgesicherten Modus beenden, indem Sie Ihren MBP wie gewohnt neu starten

7. Öffnen Sie das Verzeichnis

In Ihrem Fall trifft dies wahrscheinlich nicht zu, da Sie es nicht erwähnen. Wenn Sie jedoch mit einem Open Directory-Netzwerk verbunden sind, kann dies auch zu Problemen führen. Normalerweise würde dies nur ein Warten von 10 bis 15 Sekunden bedeuten, aber ich habe Berichte über Terminal-Anmeldungen gesehen, die in dieser Situation fünf oder mehr Minuten in Anspruch nehmen.

Dies scheint genau das Richtige für Sie zu sein, wenn Sie die maximale Anzahl von Prozessen pro Benutzer (oder möglicherweise die maximale Anzahl von Prozessen) überschreiten.

Auf einer Standard-MacOS-Installation erhalten Sie 709 pro Benutzer ( ulimit -u) und maximal 1064 Prozesse ( sysctl -a | grep maxp).

Eine einfache Möglichkeit, diese zu erhöhen, besteht darin, Server.app aus dem App Store zu installieren und anschließend neu zu starten. Sie können den Leistungsmodus auch für höhere Grenzwerte festlegen.

Da Sie Ihr Setup (Betriebssystemversion und Build) nicht beschrieben haben, finden Sie hier einige Tipps. Überprüfen Sie, ob SIP die Fähigkeit zum Ändern von Dateien einschränkt, wenn Sie einige ältere Artikel zum Ändern der Grenzwerte lesen, ohne auf die Installation des Servers zurückgreifen zu müssen. App:

• Wie erhöhe ich "ulimit -u" (maximale Benutzerprozesse)?
• http://blog.dekstroza.io/ulimit-shenanigans-on-osx-el-capitan/
• https://support.apple.com/de-de/HT3854
• https://support.apple.com/de-de/HT4022
• /server/15564/where-are-the-default-ulimits-specified-on-os-x-10-5

Das sehe ich auch schon seit einigen Monaten. Sehr frustrierend. Das einzige, was das Problem behebt, ist ein Neustart.

• Mitte 2015 MBP (keine Touchbar)
• MacOS 10.12.6 Beta

Manchmal bleibt die Anmeldung nach der Interaktion mit tmux hängen.

Ich habe alle empfohlenen Ansätze erfolglos ausprobiert.

Ich bin mir nicht sicher, ob es damit zusammenhängt, aber a lsof -p LOGIN_PIDzeigt eine ziemlich große Datei /private/var/db/dyld/dyld_shared_cache_x86_64hfür den nicht reagierenden Anmeldevorgang.

29.08.2017 Aktualisierung:

Immer noch das Problem. Manchmal, wenn der Computer in einen schlechten Zustand gerät, habe ich offene Terminalfenster, die bereits erfolgreich angemeldet sind und die ich zum Debuggen verwenden kann.

Viele Befehle werden nicht richtig ausgeführt, aber sie weisen alle ein Muster auf, bei dem Probleme beim Schreiben auftreten (ich denke, zu groß). Wenn ich zum Beispiel renne ls -al, sehe ich ls: write errorstderr emittiert. Wenn ich laufe ls -al > /dev/null, wird nichts nach stderr gedruckt.

Es ist wichtig, das eigentliche Problem und nicht nur das Symptom zu behandeln. Probieren Sie die folgenden Vorschläge aus und aktualisieren Sie sie, damit Sie auch weitere Abhilfemaßnahmen vorschlagen können.

1. Welcher Benutzer besitzt das Terminal? :
   Mein erster Verdacht ist, dass dies mit der Einrichtung Ihres Kontos zusammenhängt. Wenn das Terminal versucht, auf die Ressourcen oder Verzeichnisse zuzugreifen, die nur der Administrator verwenden kann (wenn Ihr Konto kein Administratorkonto ist), kann dies zum Einfrieren des Status führen, sodass Sie nicht auf das Terminal zugreifen können. Gehen Sie also vor und stellen Sie sicher, dass eine Terminalsitzung für Ihren Benutzer und nicht für einen anderen Benutzer lokal ist. Die Tatsache, dass Sie keinen Sudo-Prozess erstellen können, weist mich in diese Richtung.

2. Typ Control-Z oder Command-Z:
   Diese Steuertastenfolge unterbricht ein Programm, das möglicherweise ausgeführt wird, und gibt Ihnen eine Shell-Eingabeaufforderung. Jetzt können Sie den Befehl jobs eingeben, um den Namen des Programms zu finden, und das Programm mit fg neu starten oder mit kill beenden.

3. Drücken Sie Befehl-C :
   Dies wird unterbrochen, wenn das Terminal versucht, ein Programm im Hintergrund auszuführen. Probieren Sie es ein paar Mal. Beachten Sie, wenn Sie eine Ausgabe sehen

4. Typ Control-Q :
   Wenn die Ausgabe mit Control-S gestoppt wurde, wird sie neu gestartet.

5. Erhalten Sie eine alternative Shell :
   Wenn Sie ein paar Tage lang eine andere Shell ausprobieren möchten, kann deren Verhalten Ihnen manchmal dabei helfen, das Problem mit Terminal zu verstehen, wenn es auf eine bestimmte Art und Weise funktioniert. Überprüfen Sie diese Links unten auf Alternativen

https://git-scm.com/downloads/guis
https://computers.tutsplus.com/tutorials/beyond-terminal-4-os-x-terminal-alternatives--mac-56217

Hilft Folgendes zu wissen, falls nicht bereits erwähnt:

• Wie initiieren Sie die Terminalsitzung? Geht das über Spotlight oder ein Desktopsymbol oder auf eine andere Weise?

• Was macht das Terminal, wenn es hängt? Ist es in der Mitte der Ausführung eines Befehls (jedes Mal derselbe Befehl, bevor er hängt) oder hängt es nur von dem Moment an, an dem Sie eine Terminal-Sitzung / ein Terminal-Fenster starten.

• Wofür verwenden Sie normalerweise Ihr Terminal? Wenn ein Großteil Ihrer Verwendung nur für git-bezogene Befehle bestimmt ist, würde ich die Verwendung von "Something like Github for Mac" vorschlagen, da Sie die meisten Aufgaben von dort aus erledigen können.

Ich würde versuchen, SIP zu deaktivieren und die Anmeldung zu verfolgen, um die Grundursache zu ermitteln (Informationen zum Deaktivieren und erneuten Aktivieren von SIP finden Sie unter http://osxdaily.com/2015/10/05/disable-rootless-system-integrity-protection-mac -os-x / )

$ csrutil status
System Integrity Protection status: disabled.
$ cp /usr/bin/login /tmp
$ sudo dtruss /tmp/login

Als ich versuchte, Ihnen ein Beispiel zu geben, fand ich heraus, dass die Dinge viel einfacher sind, als ich dachte. Sie müssen SIP nicht deaktivieren, sondern müssen nur die Anmeldung kopieren.

dtuss gibt die Systemaufrufe zurück und gibt möglicherweise einen Hinweis darauf, wo etwas schief geht.

cp /usr/bin/login .
sudo ls

Geben Sie Ihr Passwort ein. Dann mach

sudo dtruss -d -e ./login 2> dtruss_login.txt

Geben Sie Ihren Benutzernamen ein und drücken Sie die Eingabetaste

Geben Sie Ihr Passwort ein und drücken Sie die Eingabetaste

Geben Sie 'exit' ein und drücken Sie die Eingabetaste

und schließlich lade dtruss_login.txt hoch, zB auf https://gist.github.com/

Sie können den Inhalt der Datei wie folgt in die Zwischenablage kopieren

cat dtruss_login.txt | pbcopy

Ein Beispiel für eine Anmeldung finden Sie hier: https://gist.github.com/wolframteetz/49c5188c9dfe68a3841fa18496679579

Die zweite Ganzzahl in jeder Zeile gibt die Zeit an, die der Anruf gedauert hat.

Natürlich wäre es großartig, wenn Sie dies ausführen könnten, wenn die Anmeldung hängt, aber wenn ich Sie richtig verstehe, ist dies unmöglich. Vielleicht haben Sie oder jemand anderes eine Idee, wie Sie die Anmeldung "weiterleiten", wenn das Terminal hängt ?

Der loginBefehlsquellcode wurde von Apple veröffentlicht. Die Website ist MacOS 10.13.3 Source . Der einzige erforderliche Download ist system_cmds-790.30.1. Nach dem Herunterladen kann das Projekt einfach so geändert werden, dass nur der loginBefehl erstellt wird. Das geänderte Projekt und der loginBefehl wurden in GitHub unter davidanderson61 / system_cmds-10.13.3 gespeichert .

Die Idee hier ist, zu ändern login, um Debug-Informationen in die Konsole zu schreiben. Dies würde dazu beitragen, festzustellen, warum der loginBefehl hängt. Die Änderungen können von jedem vorgenommen werden, der teilnehmen möchte. Ich nahm an, das wäre ich gewesen.

Installieren Sie den Debug- loginBefehl.

1. Wählen Sie die neueste Version von der Website davidanderson61 / system_cmds-10.13.3 / releases .

2. Laden Sie den Debug- loginBefehl in Ihren DownloadsOrdner herunter . Klicken Sie mit der rechten Maustaste unter "Assets" auf login"Verknüpfte Datei herunterladen unter" und wählen Sie dann "Speichern".

3. Deaktivieren Sie teilweise den Systemintegritätsschutz (SIP). Der Befehl ist unten angegeben. Bevor Sie den Befehl eingeben , müssen Sie zunächst mit macOS Recover und dann mit einem Terminal-Fenster booten .

   csrutil  enable  --without  fs

4. Geben Sie den folgenden Befehl ein, um den ursprünglichen loginBefehl zu speichern . Falls login.orignalbereits vorhanden, können Sie diesen Schritt auslassen.

   sudo  mv  /usr/bin/login  /usr/bin/login.original

5. Geben Sie die folgenden Befehle ein, um den Debug- loginBefehl zu kopieren und die entsprechenden Berechtigungen festzulegen.

   sudo  cp  ~/Downloads/login  /usr/bin/login
   sudo  chmod  104555  /usr/bin/login

6. Aktivieren Sie den Systemintegritätsschutz (SIP). Geben Sie den folgenden Befehl ein. Danach sollten Sie neu starten.

   sudo  csrutil  clear

Konfigurieren Sie die Konsolenanwendung

Im Folgenden werden die Schritte beschrieben, um die Konsolenanwendung so zu konfigurieren, dass nur Nachrichten des loginBefehls angezeigt werden.

1. Öffnen Sie die Konsolenanwendung.

2. Fügen Sie eine PIDSpalte hinzu, wie unten gezeigt.

   

3. Geben Sie loginin das Suchfeld ein.

   

   Drücken Sie die returnTaste, während das Suchfeld den Fokus hat . Das Suchfeld sollte sich wie folgt ändern.

   

4. Wechseln Sie Anyzu Process, wie unten gezeigt.

   

5. Liste Wechseln Containszu Equals, wie unten gezeigt.

   

6. Wählen Sie die SaveSchaltfläche. Wenn Sie zur Eingabe von "Suche speichern unter:" aufgefordert werden, geben Sie ein Loginund wählen Sie Save.

   

Die Ergebnisse sollten wie folgt aussehen. Wenn Sie das nächste Mal die Konsolenanwendung öffnen, müssen Sie nur die Schaltfläche "Anmelden" auswählen.

Blinddarm

Wie das GitHub-Repository erstellt wurde.

1. Klicken Sie auf die system_cmds.xcodeprojin Xcode geöffnete Datei.
2. Wählen Sie in der Menüleiste Source Control->Create Git Repositories....
3. Wählen Sie in der Menüleiste Product->Scheme->New Scheme.... Wählen Sie loginals Nächstes Ziel und Name aus.
4. Wählen Sie in der Menüleiste Project->Build.
5. Beenden Sie Xcode.
6. Melde dich bei GitHub an und erstelle ein neues Repository.
7. Klicken Sie oben auf der Seite "Schnelleinrichtung" Ihres GitHub-Repositorys auf, um die Remote-Repository-URL zu kopieren.

8. Geben Sie für ein Terminalanwendungsfenster den folgenden Befehl ein. Durch <remote repository URL>die im vorherigen Schritt kopierte URL ersetzen .

   git  remote  add  origin  <remote repository URL>

9. Öffnen Sie das Projekt in Xcode und wählen Sie in der Menüleiste Source Control->Push....

Wie das erste Release erstellt wurde

1. Geben Sie in einem Terminalanwendungsfenster die folgenden Befehle ein.

   git  tag  -a  v1.0  -m  "Original source code"
   git  push  origin  v1.0

2. Kopieren Sie den erstellten loginBefehl in Ihren DownloadsOrdner.

3. Erstellen Sie in Ihrem GitHub-Konto eine neue Version als v1.0. ~/Downloads/loginAls Binärdatei anhängen .

Ich hatte dieses Problem auch beim Ausführen der sbt-Konsole in Emacs. Immer, wenn ich die sbt-Konsole verließ, indem ich das Fenster einfach abbrach, anstatt zuerst "nett" aus der sbt-Konsole auszusteigen, blieb ein Java-Prozess hängen, selbst nachdem das Fenster geschlossen wurde, und irgendwie wurde verhindert, dass neue Terminalsitzungen erstellt wurden. Ich habe den Java-Prozess vom Aktivitätsmonitor aus erzwungen, und das hängende Terminal wurde sowohl in Emacs als auch in einem neuen Tab gestartet.

Jetzt muss ich nur noch mit dem Befehl exitoder ctrl-d(oder ctrl-c ctrl-din Emacs term/multi-term) beenden und dann das Fenster schließen.

1. Überprüfen Sie, ob Ihr Prozess wirklich während hängt login
2. Schauen Sie sich den Activity Monitor an und achten Sie auf rootProzesse (z. B. Nano, Emacs, Vim), die Sie möglicherweise initiiert haben und die nicht ordnungsgemäß beendet wurden (Absturz, einfach das Terminal beendet usw.) und die noch ausgeführt werden.
3. Beenden Sie diesen Prozess (diese Prozesse) und der Login sollte sofort funktionieren.

Nur meine zwei Cent.

Ich habe das Terminus-Paket für Sublime Text installiert, mit dem ich Terminal in meinem Texteditor ausführen kann.

Durch das sofortige Schließen von Sublime Text konnte mein Terminal wieder arbeiten.

FWIW, ich hatte das gleiche Problem. Es würde sich nach dem Neustart auflösen, aber ich wollte mir die Zeit sparen, die ich dafür mehrmals am Tag benötige. Es begann, nachdem eine bestimmte nodeJS-Umgebung verwendet wurde. Daher wechselte ich in die Aktivitätsüberwachung und stellte fest, dass ein Knotenprozess ausgeführt wird. Das Beenden dieser Instanz hat das Problem für mich gelöst. Wenn also jemand, der dies erlebt hat, kürzlich damit begonnen hat, lokal mit Node oder Npm zu arbeiten, könnte dies Ihr Problem sein.

Durch das Töten einer streunenden NVIM-Instanz wurde das für mich behoben. Ich gehe davon aus, dass dies nicht nvim-spezifisch ist, aber etwas, was nvim in meinem Fall tat, verursachte Probleme. Ich würde nach einer fehlenden verwaisten Terminal-App im Aktivitätsmonitor suchen und diese töten, wenn Sie eine finden.