I installed debian strech yesterday. I installed fish shell . I change the default shell to fish by the following
su chsh -s 'which fish'
Then again enter the this command
su chsh -s `which fish`
Now after I restart the PC I encountered the following error while using "su"
sathish#localhost ~> su
Password:
Cannot execute which fish: No such file or directory
Did you mean to use regular single-quote chars in your first command? Doing so means your shell is now literally the string which fish rather than the path to the fish command. That explains why your second command reports that it cannot execute "which fish". Even without that mistake it is a really bad idea to change the default shell for your root account. You're just asking for trouble. And I say that as a core fish developer. Unless you are an extremely competent and confident CLI user you should not change the root shell. You can always do exec fish -l after su if you want fish as your root shell.
Related
The below script executing with root user.After switch user Unix function showing error.
test.sh
#!/bin/bash
fn_test()
{
echo "This is function"
}
whoami
fn_test
su - oracle<<EOF
whoami
fn_test #This function not called
EOF
exit 0
O/P
root $ ./test.sh
root
This is function
oracle
-ksh[2]: fn_test: not found [No such file or directory]
You have a confusion on what su actually does: you hope it to just swith user when it does start a new process. You can control it with ps in an interactive session: you see the original shell, the su command, the new shell launched by su and the current ps command.
As a shell function is local to the shell it cannot be used in a (grand) child shell.
The best that you can hope is to pass something through the environment. I know that aliases can be put there unsure for functions. Moreover, this is absolutely shell dependant and might not be portable.
I need to write bash script to startup oracle DB
some command should run with user-root and some of them with user-oracle
How can I make these code as a bash script code
#!/bin/bash
su root
password
rm /var/tmp/.oracle/*
su oracle
lsnrctl start
sqlplus sys as sysdba
startup
But after i run this code ,It ask me root password and dont run other commend after su command.
Thanks.
Each line in a script is a command to execute. If a command reads input, it doesn't normally get it from the script file, it gets it from the script's standard input. If you want it to read from the script, you have to use a here-document:
#!/bin/bash
su root <<EOF
password
rm /var/tmp/.oracle/*
su oracle <<EOF1
lsnrctl start
sqlplus sys as sysdba
startup
EOF1
EOF
However, I'm not sure this will work with su. It probably doesn't read the password from standard input, but forces it to come from the terminal. You probably should be using sudo, which you can configure to not require a password for certain users and scripts.
Or if you use systemd, you should be able to configure a service startup script.
Alright guys, so I try to install rvm in a docker container based on ubuntu:14.04. During the process, I discovered that some people do something like this to ensure docker commands are also run with the bash:
RUN ln -fs /bin/bash /bin/sh
Now The weirdness happens and I hope someone of you can explain it to me:
→ docker run -it --rm d81ff50de1ce /bin/bash
root#e93a877ab3dc:/# ls -lah /bin
....
lrwxrwxrwx 1 root root 9 Mar 1 16:15 sh -> /bin/bash
lrwxrwxrwx 1 root root 9 Mar 1 16:15 sh.distrib -> /bin/bash
...
root#e93a877ab3dc:/# /bin/sh
sh-4.3# echo $0
/bin/sh
Can someone explain what's going on here? I know I could just prefix my commands in the dockerfile w/ bash -c, but I would like to understand what is happening here and if possible still ditch the bash -c prefix in the dockerfile.
Thanks a lot,
Robin
It's because bash has a compatibility mode where it tries to emulate sh if it is started via the name sh, as the manpage says:
If bash is invoked with the name sh, it tries to mimic the startup
behavior of historical versions of sh as closely as possible, while
conforming to the POSIX standard as well. When invoked as an
interactive login shell, or a non-interactive shell with the --login
option, it first attempts to read and execute commands from
/etc/profile and ~/.profile, in that order. The --noprofile option
may be used to inhibit this behavior. When invoked as an interactive
shell with the name sh, bash looks for the variable ENV, expands its
value if it is defined, and uses the expanded value as the name of a
file to read and execute. Since a shell invoked as sh does not
attempt to read and execute commands from any other startup files, the
--rcfile option has no effect. A non-interactive shell invoked with the name sh does not attempt to read any other startup files. When
invoked as sh, bash enters posix mode after the startup files are
read.
Ok I'm about to pull my hair out. I have a perl script that just will not run in the crontab however I have a previously written perl script that runs just fine every day on the same box. I have checked all of the given solutions on this site and others around the web and nothing seems to make a difference. Here is my cron and the first part of my script
55 13 * * * su oracle; cd /u02/oraclebackup;./move_em_bkup.pl >> /u02/oraclebackup/move_em_backup.log > move_em_bkup.dbg 2>$1
It touches the .dbg file but does not put anything in there. There are no errors or anything that I can use to go by.
#!/usr/bin/perl
use Strict;
use Archive::Tar;
use Net::SCP qw/ scp /;
use Net::SCP::Expect;
use DateTime;
Can anybody help?
The command you're running is:
su oracle; cd /u02/oraclebackup; ...
su oracle normally launches an interactive shell under the oracle account (assuming you have permission to do so). I'm not sure what that would do in a non-interactive cron environment, but even assuming it works, the cd /u02/oraclebackup and following sub-commands will be executed after that shell terminates, i.e., under the account that owns the crontab. The su oracle will either block the rest of the command or do nothing.
You can use su -c command to run a command as a specified user. In you case, you'd want something like:
su -c oracle sh -c 'cd /u02/oraclebackup; ...'
Or change su to su - if you need the oracle account's login environment.
Better yet, drop the su and put the whole thing in the oracle account's crontab. You might still need to play some more tricks to get the environment right; cron jobs run with a limited set of environment variables by default.
I've got a shell script which I am trying to run as a specific user. My command looks like this:
su - jetty sh ./runProgram.sh
When I attempt to run this command through the console I get an error saying:
/bin/sh: /bin/sh: cannot execute binary file
I also tried:
su - jetty sh runProgram.sh
And I still get the same error..
It DOES work if I do this:
sh runProgram.sh
But this shell script is meant to be run by a specific user. Any advice on how to get this working??
Try
su - jetty -c sh runProgram.sh
According to su's documentation (info coreutils 'su invocation'), it will by default execute a shell, and the arguments to su are passed as arguments to the shell.
The implication is simply this: su is doing in essence:
/bin/sh *arguments_to_su*
but it does it as another user (the "effective user id")... that's all... So
su - jetty sh ./runprogram.sh
is akin to
(become the user jetty via login or su)
/bin/sh sh ./runprogram.sh
...and the shell will report an error, because the first /bin/sh, called by su, is trying to run the program sh as a shell script, with ./runprogram.sh as its argument. But sh itself is not a shell script, it is a binary (whose job it is is to run shell scripts).
if you were to simply do this:
su - jetty ./runprogram.sh
Then the su command will call /bin/sh with the program ./runprogram.sh as its argument, and jetty as the effective user id, and all should be well. ...SHOULD be well, because since you are doing an su - you are making the shell a login shell and changing to the user's home directory. If runprogram.sh is not in the home directory, you will get an error.
This is why, also, you cannot run for example run a cp command by simply:
su - jetty cp file1 file2
...because, again, after su changes effective user id to jetty it will try this:
/bin/sh cp file1 file2
...and cp is not a shell script. But the -c option works in this case; because you are telling su that you want to run /bin/sh with the -c option to the shell:
su - jetty -c "cp file1 file2"
does the job. Note that you must quote the command, because the entire string is passed to the shell and (I believe) any following arguments are ignored.
Finally, the previous poster's answer doesn't work for me on Linux, it requires the entire command string to be quoted.