0

Some background: I have a machine with SLES 11 installed. I am running a bash script that one of its lines is /bin/su $USER -c SOME_CMD.

Unfortunately, the SOME_CMD that comes after the -c keeps failing, no matter if USER=root or any different user. However, if /bin/su $USER -c part is omitted then everything runs smoothly. Moreover, I have run the script on RHEL5 and it worked fine.

Anyway, my question is why does it happen? If it is a permissions problems then why when I run this as root with /bin/su and without I get different results?

P.S. apologize if somebody else has asked it before, I have done many googling and got nothing that satisfies.

EDIT Okay, I figured it out, I hope so. Instead of running /bin/su I used /user/bin/sudo -u $MY_USER_1 MY_ENV_VAR="/home/user1" SOME_CMD. I don't understand why I have to use sudo, though. I am used to run a command as a different user using su and not worrying about permissions problems, but I guess it doesn't work like that on SLES 11/SuSE.

Anyhow, thanks to everyone who wanted to or helped me.

John Gardeniers
  • 27,262
  • 12
  • 53
  • 108
n00bInCpp
  • 1
  • 1
  • 3

1 Answers1

1

That's because the correct syntax of the command is

/bin/su -c SOME_CMD USER

See man su.

You shouldn't assign anything to the variable $USER, BTW, because it's a system variable that holds the name of the currently logged in user.

Ansgar Wiechers
  • 4,197
  • 2
  • 17
  • 26
  • First of all, thanks for the answer and the note regarding the `$USER`. However, it doesn't help. I still get different results. Without the /bin/su no error is shown, while when using /bin/su as you told me I get the same "`Corba` communication problems" error message. Any idea why does it do that? – n00bInCpp Sep 03 '12 at 05:56