1
$ sudo su - user1 -c 'echo $DOMAIN_HOME'
/app/user1/DOMAINHOME

This looks fine, right? However, let's dig a little deeper:

$ sudo su - user1 -c 'echo $DOMAIN_HOME' | tee test.out
$less test.out

ESC]P0000000ESC]P8A9A9A9ESC]P1DC143CESC]P9FF0000ESC]P2008000ESC]PA00FF00ESC]P3aa9943ESC]PBFFD700ESC]P41E90FFESC]PC87CEFAESC]P5706c9aESC]PD826ab1ESC]P6FFA500ESC]PEF0F8FFESC]P7FFFFFFESC]PFFFFFFFESC[HESC[2JESC[HESC[2J/app/user1/DOMAINHOME

This is causing my scripts to fail.

They are color codes that are sourced by .bashrc which is sourcing colors for xterm. After doing a little research, the last section [HESC[2JESC[HESC[2J is what clears the terminal prior to outputting the path.

I've been pulling my hair out trying to figure out why these are showing up. Any Ideas?

Note: When logged in as user1, it echoes the variable just fine.

2

Since you're using "su -" the shell being executed is pretending like it's a login shell (executing the system's /etc/profile, the user's profile, such as .profile or .bash_profile, and so on). One of those scripts is generating the escape sequence (the Esc]P string) and printing that result to stdout. It shouldn't do that.

What it should be doing is checking to see if the shell is interactive, and then -- and only then! -- it should generate the escape sequence.

The best way to check for an interactive shell is to check the value of "$-" and see if it contains the letter i -- if it does, the shell is interactive, and if it doesn't, the shell is not. I typically use something like this:

case "$-" in
*i*)  # Here if the shell is interactive
      ;;
*)    # Here otherwise
      ;;
esac

You'll need to determine what is generating that escape sequence. Common culprits are echo, tput, and and other commands that are supposed to modify the terminal's settings. I did some Google'ing but can't find that particular escape sequence, so I can't provide any clues as to where/what to look for.

Of course, why are you using su - at all? Just use sudo -u user1 and eliminate an extra step (your requirements might include executing user1's .profile though; I don't know and you didn't say).

  • I tried the case statement in its own script while logged in as user1 and the shell doesnt show to be interactive. I tried it on a few other users and got the same result. – Motorahead May 6 '15 at 17:08
  • I've read over this a few times and am having a trouble understanding. The - executes the users .profile. So the users .profile isnt checking if stdin is a terminal? Should the terminal be interactive or noninteractive? And what would the solution be? – Motorahead May 6 '15 at 23:54
  • I've tried to clarify my answer better. :) – Azhrei May 7 '15 at 21:59
  • Thankyou :) There are variables being referenced in the user's .profile as a part of the script, so I do need to use "su -". However, I did make some progress by finding the culprit. There is another file sourced in the .profile that is setting the terminal colors to a more readible format. I commented it out and the only esc sequence left (that was still poping up) was the clearing of the terminal when .bash_logout is executed on exit. – Motorahead May 13 '15 at 21:07
  • I think removing the custom terminal colors and clearing the .bash_logout would only band-aid the problem. It looks like all of my user sessions are non-interactive. I'm still learning and am unfamiliar with the differences between interactive and non-interactive. I'll research it now, but could that be the problem? – Motorahead May 13 '15 at 21:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.