Tag Info

New answers tagged


This might works : #!/bin/bash su - user2 -c 'echo "$0" "$@"' -- "$@" Use simple quotes ' to pass the command argument to su so you don't have to escape the double quotes ". References : Escaping bash function arguments for use by su -c - Stack Overflow bash - Passing arguments to su-provided shell - Unix & Linux Stack Exchange


dd if=boot1h of="/dev/r$temp1" status=none The status= flag controls which info to suppress outputting to stderr; 'noxfer' suppresses transfer stats, 'none' suppresses all dd (coreutils) 8.21


I assumed your problem is the su-pam file and the pam_rootok module. #%PAM-1.0 auth sufficient pam_rootok.so auth include system-auth The sufficient clause short-cuts the authentication process. So system-auth never gets included, which means the pam_group module is never activated for this session. Then, sigh I read ...


The reason this is failing is that, by default, ssh does not create a terminal (a pty) on the target machine. This means that su cannot prompt for a password, so it fails. (sudo would also fail to prompt, for the same reason, unless given the -S flag - as pointed out by @Scott.) You can tell ssh to create a terminal (pty) on the remote system, so that su ...


Is it possible to use sudo before the command you want to execute? Like instead of: su whatever command do: sudo whatever command


.bashrc is executed only by interactive shells, not by scripts┬╣. It's the wrong place to define environment variables. See Alternative to .bashrc and the Ubuntu wiki. You can tell bash to read .bashrc explicitly. Of course you'll have to execute bash, not sh which could be a different shell: sudo -i -u username bash -c '. `~/.bashrc; echo "$MY_ENV"' But ...


root@hostname # su - oracle could not open session root@hostname # grep oracle.*nofile /etc/security/limits.conf oracle - nofile unlimited set nofile in limits.conf to some number instead of unlimited: root@hostname # vi /etc/security/limits.conf root@hostname # grep oracle.*nofile /etc/security/limits.conf oracle - ...


The default shell for root on OS X is /bin/sh. Its sh is also a version of bash, but when invoked with the name sh Bash: 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 as a non-interactive shell with the --login ...


The root user will try to execute the .bashrc file instead of the .bash_profile since you are not invoking a login shell. From the bash manual man bash: ~/.bash_profile The personal initialization file, executed for login shells ~/.bashrc The individual per-interactive-shell startup file Note the ~ where the .bashrc file needs ...


Because it is not considered as a "login shell" (which is invoked directly from login, or sshd) but simple "interactive shell". See here for example: https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html So force su using login option i.e. with -l option: su -l Or put your environment into .bashrc file.


su -c bash Make an alias if that's too much typing for you. You've correctly analyzed that a plain su doesn't load any initialization file, so either you need to change the configuration or you need to change the command.


I personally use that on my Mac and it's also working on my Ubuntu Server. But I edited two files. In the .profile of root I put PS1="\[\033[1;31m\]\u\[\e[m\]@\h \[\e[0;32m\]\w\[\e[m\] \$ " # Root and in the .bash_profile of my personal user I put PS1="\[\033[1;32m\]\u\[\e[m\]@\h \[\e[0;32m\]\w\[\e[m\] \$ " # User The effect is the following : You ...

Top 50 recent answers are included