Getting an "unexpected operator" error when logging in on a new account

-sh 29 [: tty: unexpected operator 

This has nothing to do with operator accounts: it is talking about a syntax error in a conditional expression. Unfortunately this is a bit obscure because of the history of the Bourne/POSIX shell.

Background

The classic way to make conditional constructs ("if this is true, do that") in a Bourne/POSIX-style shell is the if ... then ... [else ...] fi syntax. For example, to test if /usr/local/lib/someutility is executable before actually trying to run it, you would do something like this:

if [ -x /usr/local/lib/someutility ] then /usr/local/lib/someutility some-parameters else echo "Installation error: /usr/local/lib/someutility is not executable." >&2 exit 1 fi 

The plain if command does not actually know how to test if something is executable or not: it actually executes its arguments as a separate command, and checks if the return code is zero (= test successful/true) or not (= test failed/false).

The [ is actually a separate command: it has the alternate name test. Modern shells might implement it internally for better performance, but for POSIX compatibility, it must also exist as an executable binary at /bin/[ or /usr/bin/[. It even has a man page: try man [ or man test on your system.

The [ (or test) command interprets the arguments given to it, performs the requested test, and exits with a corresponding return code.

The ] is a bit of syntactic sugar for humans: the [ command might use it as an "end-of-arguments" marker, or just ignore it completely. The if command does not care about the square brackets being paired or not: all it cares about is the return code.

The actual answer

The error message seems to indicate that on line 29 of whatever login script it's executing (maybe /etc/profile, maybe some /etc/profile.d/*.sh file, maybe $HOME/.profile in the user's home directory) has an erroneus if [ ... construct that looks like this:

if [ tty <...something...> ] 

Here, the tty <...something...> ] part is passed as an argument to the [ command, but as you can see from man [, it does not know about a test named tty. The error message refers to the argument that would specify the test to do as an operator, in the sense of arithmetic or logical operators.

If the error message happens only with new user accounts, then the error might be in the template login script files provided for new user accounts: the templates are located in /etc/skel/ directory. See ls -la /etc/skel: remember that you'll need the -a option for ls to show any files whose names begin with a dot, like .profile.

I would assume that the intention was something along the lines of "do something that produces some output, but only if the session is actually connected to a (true or pseudo) TTY device", or in other words, seems like a regular interactive login session. This is a good practice on login scripts, as login scripts will also occasionally be called in non-interactive contexts, e.g. when using scp or rsync to transfer files between hosts. In such a situation, extra output might mess up the file transfer.

If that is the case, the tty command will produce a return code 0 if the session is connected to a TTY device, and 1 otherwise. So the [ command should not be used with it at all, and the correct syntax would be:

if tty -s then # do something that produces output fi 

But this is actually excessively backwards-compatible at the expense of functionality. In any POSIX-compatible shell, you should be able to do this instead:

case $- in *i*) # do something that produces output ;; esac 

This directly tests whether the shell session is actually interactive or not (which is what you want to know when deciding whether to display output or not) instead of trying to infer it indirectly from the presence/absence of a TTY device connection.