Skript zum Ändern des Computernamens/Hostnamens, was zu einem bizarren Verhalten des Terminals führt

Ich habe ein Skript (meistens geliehen), mit dem scutilComputer basierend auf Werten in einer CSV-Datei umbenannt werden. Es vergleicht die Seriennummer mit einem Computernamen, legt eine Variable fest und benennt dann ComputerName, HostName, und LocalHostNamemit der Variablen um. Als Referenz wird der Name seinSFO-C2900-MBP

Hier ist das Skript:

#!/bin/bash 

echo "-----Starting-----"

# Get serial from ioreg and assign
serial="$(ioreg -l | grep IOPlatformSerialNumber | sed -e 's/.*\"\(.*\)\"/\1/')" 

#Initialize compName to null
compName=''

#Loop through CSV looking for a match
while IFS=',' read ser loc; do
    if [ "$serial" == "$ser" ]; then
        compName=$loc
        echo "Serial Matched with name: $compName"
    fi
done < /Volumes/Macintosh\ HD/Users/Shared/Configuration/names.csv

#If compName is not null, use scutil to rename. Otherwise user must manually rename
if [[ -z $compName ]]; then
    echo "This computer was not found on the list, you must manually rename it."
else
    echo "Setting Host Name to $compName"
    scutil --set HostName $compName

    echo "Setting Computer Name to $compName"
    scutil --set ComputerName $compName

    echo "Setting Local Host Name to $compName"
    scutil --set LocalHostName $compName

fi

echo "-----Finished Renaming-----"

Daraus ergeben sich zwei Dinge:

1) Ein Fehler wird ausgegeben, wenn das Skript versucht, Folgendes umzubenennen LocalHostName:SCPreferencesSetLocalHostName() failed: Invalid argument

2) Das Terminal wird nach dem Beenden/Neustart/usw. Folgendes tun: Das Terminal mit Fragezeichen über Ordner, auch fehlender HostnameTerminal zeigt ein Fragezeichen über dem Ordner, außerdem fehlt der Hostname

Das manuelle Festlegen dieser Werte über das Terminal scutil --set {def}funktioniert einwandfrei und stellt das normale Verhalten des Terminals wieder her.

Ich habe folgendes versucht:

  • Entfernen der LocalHostName-Zeilen aus dem Skript
  • Festlegen des LocalHostName-Werts auf eine Variable, die im Skript und nicht in der CSV-Datei festgelegt ist

Meistens ist das Problem des Skripts, was es vor allem mit Terminal macht - ich kann das LocalHostName-Problem umgehen. Seltsamerweise scutil --get {def}gibt Terminal die richtigen Werte aus, wenn Sie diese ausführen.

Haben Sie darüber nachgedacht, Ihre $compNameVariable zu zitieren, falls sie als Option interpretiert wird? Versuchen:scutil --set LocalHostName "$compName"
@IanC. Nein, gleiches Problem auf der scutil --set LocalHostNameLeitung. Ich möchte auch hinzufügen, dass das Verschwinden des Namens in Terminal behoben wird, indem es scutil --set HostNamemanuell über Terminal anstelle des Skripts ausgeführt wird.
Und Sie nennen Ihr Skript mit sudo <name of the script>Recht?
@IanC. Yep, gleiches Ergebnis in beide Richtungen
Legt das Skript den HostName und den ComputerName fest? Nur nicht der LocalHostName?
@MorganR richtig. Außerdem wird die Änderung des Hostnamens aus irgendeinem Grund nicht korrekt registriert. ZB wenn Sie scutil --get HostNamees ausführen, wird es angezeigt, aber Terminal funktioniert nicht richtig, bis Sie es scutil --set HostNamemit der richtigen Variable ausführen, selbst nach dem Neustart.
Sehr eigenartig. Ich habe ein einfaches Bash-Skript geschrieben, das die gleiche Aufgabe erfüllt wie Sie, aber anstatt eine CSV-Schleife zu durchlaufen, habe ich grep und awk verwendet, um den Computernamen vom SN zu isolieren. Ich kann es unten posten, wenn Sie möchten? Vielleicht wird beim Durchlaufen einer CSV-Datei ein seltsames Zeichen erkannt, das Ihr Problem verursacht. Wenn dies jedoch der Fall wäre, würde ich mir vorstellen, dass sowohl das Festlegen von HostName als auch von ComputerName ebenfalls fehlschlagen würde.
@MorganR Sicher! Der Grund, warum wir die CSV-Datei verwenden, liegt jedoch darin, dass unsere Computernamen auf Asset-Tag-Informationen basieren, die das Skript anhand der Seriennummer des Systems mit einer Liste bekannter Computernamen abgleicht.
@smoooosher @MorganR Eine Idee, um zu überprüfen, ob ein seltsames Zeichen in den Variablenwert eingebettet wird: Versuchen Sie, die Zeile echo $compName | od -cnach dem Abschnitt "Schleife durch die CSV" zum Skript hinzuzufügen. (Um mit odwas zu experimentieren, versuchen Sie es zB echo foo | od -cim Terminal ...)
@Ashley Du. Sind. Toll. An das Feld in der CSV-Datei wurde ein \r angehängt, wodurch die Umbenennung fehlschlug. Using odzeigte das Problem und dann sedentfernte ich das irrelevante Zeichen. Bitte posten Sie Ihre Antwort als Antwort und ich werde akzeptieren :)
Großartig! Sehr gerne helfen können. Ich habe eine Antwort geschrieben. Übrigens finde ich, dass @MorganR hier auch etwas Anerkennung verdient, aber leider sehe ich im Kopfgeldsystem keine Möglichkeit, dies zu tun ...
Ah, ich dachte, es wäre so etwas, aber ich hatte keine Ahnung, wie ich es überprüfen sollte - kein Grund, sich schuldig zu fühlen, @Ashley! Ich bin froh, dass das Problem gelöst ist.

Antworten (2)

In den Kommentaren fragte sich @MorganR, ob der Code, der aus der CSV-Datei liest, ein seltsames Zeichen in enthielt $compName.

Eine Möglichkeit, auf ungerade, vielleicht nicht druckbare Zeichen zu testen, ist die Verwendung von od. Es hat einen obskuren Namen (steht für "octal dump"), ist aber nützlich. Es zeigt die Details jedes Zeichens in einem Eingabestrom.

Normalerweise beginne ich mit -cargument, was dazu führt, dass odjedes Zeichendetail als "Escape-Zeichen im C-Stil" ausgegeben wird ... es gibt andere Argumente, die als Hex, Oktal (noch gelegentlich nützlich!) usw. ausgegeben werden können.

Zum Beispiel (beachten Sie, dass das normalerweise Unsichtbare \nangezeigt wird):

$ echo "foo" | od -c
0000000    f   o   o  \n                                                
0000004

Also, wenn das Sinn macht, ist mein Vorschlag: Versuchen Sie, die Zeile echo $compName | od -cnach dem Abschnitt "Schleife durch die CSV" zum Skript hinzuzufügen.

In den Kommentaren hat sich herausgestellt, dass es sich bei dem Problem um einen unerwarteten \rCharakter handelt. Ich denke, die wahrscheinliche Ursache dafür ist, dass die CSV-Datei CRLF (= \r\n) Zeilenenden hat (wurde sie vielleicht auf einem Windows-System erstellt?), aber der read ser locBefehl im Skript erwartet nur LF (= \n).

Entschuldigung, mein erstes Kopfgeld. Wusste nicht, dass es einen zusätzlichen Schritt gibt, um die Antwort zu akzeptieren. Jetzt gehört alles dir :)

Ich habe das gleiche mit der folgenden Zeichenfolge abgeschlossen:

compName=${loc::9};

was tatsächlich das 9. Zeichen der gespeicherten Variablen entfernt.