4

I have a script (mostly borrowed) which utilizes scutil to rename computers based off of values in a CSV file. It matches the serial number to a computer name, sets a variable, and then renames the ComputerName, HostName, and LocalHostName with the variable. For reference, the name will be SFO-C2900-MBP

Here's the script:

#!/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-----"

Two things are happening from this:

1) An error is thrown when the script attempts to rename the LocalHostName: SCPreferencesSetLocalHostName() failed: Invalid argument

2) The Terminal, after quit/reboot/etc, will do the following: Terminal showing Question Mark over folder, also missing hostname Terminal showing Question Mark over folder, also missing hostname

Setting these values manually through terminal using scutil --set {def} work fine and restore Terminal to its normal behavior.

I have tried the following:

  • Removing the LocalHostName lines from the script
  • Setting the LocalHostName value to a variable set inside the script and not the CSV file

Mostly, the script's issue is what it does to Terminal more than anything - I can work around the LocalHostName issue. Weirdly enough, when you run scutil --get {def} on those, Terminal outputs the correct values.

  • Have you considered quoting your $compName variable on the off chance it's being interpreted as an option? Try: scutil --set LocalHostName "$compName" – Ian C. May 28 '15 at 20:29
  • @IanC. Nope, same problem on the scutil --set LocalHostName line. I'd like to add too that the disappearance of the name in Terminal is fixed by scutil --set HostName being run manually via Terminal instead of the script. – smoooosher May 28 '15 at 20:35
  • And you're calling your script with sudo <name of the script> right? – Ian C. May 28 '15 at 21:02
  • @IanC. Yep, same result either way – smoooosher May 28 '15 at 21:45
  • 1
    @smoooosher @MorganR One idea to check if a strange character is getting embedded into the variable value: try adding the line echo $compName | od -c to the script after the "loop through the CSV" section. (To experiment with what od does, try eg echo foo | od -c in Terminal...) – Ashley Jun 3 '15 at 19:34
4
+50

In the comments, @MorganR wondered if the code that reads from the CSV file was including a strange character within $compName.

One way to test for odd, perhaps non-printable characters is to use od. It has an obscure name (stands for "octal dump"), but it is useful. It shows the detail of each character in an input stream.

I usually start by using -c argument, which causes od to output each character detail as "C-style escaped characters"... there are other arguments to output as hex, octal (still occasionally useful!), etc.

For example (notice the normally invisible \n is shown):

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

So, if that makes sense, my suggestion is: try adding the line echo $compName | od -c to the script after the "loop through the CSV" section.

In the comments, the issue has turned out to be an unexpected \r character. I think the likely cause for this is that the CSV file has CRLF (=\r\n) line endings (was it created on a Windows system perhaps?), but the read ser loc command in the script is expecting just LF (=\n).

  • Sorry, my first bounty. Didn't know there was an extra step beyond accepting the answer. It's all yours now :) – smoooosher Jun 5 '15 at 20:42
0

I have completed the same with below string :

compName=${loc::9};

which actually removes 9th character of the stored variable .

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .