I have newly installed a remastered ubuntu 12.10. after installation I ran a script to make a standard user and do some other works. now when I log into the new standard user and open terminal, it only shows a $ mark and doesnt show username#hostname$.
it can return whoami but doesnt return anything for echo $HOSTNAME
the interesting thing is when I run bash, everything is ok, but when I run dash(which is default in ubuntu) I see the problem.
I've tried dpkg-reconfigure dash but nothing changed.
can anyone guess what is happened to my system!
thank you in advance.
I suggest to use bash instead of dash since the former is far better for interactive use.
The shell for the new user is probably set to /bin/dash, you just have to create the new user specifing the shell you want using the --shell option for the adduser command.
To change the shell for an alredy created user you can use the command chsh.
Related
I have a Perl program on server_B which uses Perl DBI and 5.010 and runs fine from the server_B terminal. I run it from a shell script which first prepares some arguments and then passes them to the Perl program, all works fine.
I need to run a shell script on server_A that will execute that script on server_B. This is because the Perl program creates several files that I want to SFTP back over to server_A. This is the script I'm running on server_A:
ssh server_B <<- EOF
perl/update.sh
EOF
There is some strange behavior which I'm trying to understand:
The script (update.sh) on server_B runs mysql, which is not installed on server_A (which is why I have to do this whole thing.) If I try to run it on server_B as-is, I can call mysql just like that. But when I run the above script (on server_A) to ssh into server_B and run that script, it doesn't recognize mysql unless I change the file (on server_B) to call the full path /opt/mysql/client/bin/mysql (even though that file is already on server_B with mysql installed) Does this mean server_B is picking up on the PATH variable from server_A instead of using my PATH variable from server_B? Is it trying to run my programs from server_A on the files on server_B? How and why??
If I make the change above it executes the script, but when it hits Perl it says
Perl v5.10.0- required - this is only v5.8.8
Again, 5.10 works fine on server_B but the version of Perl on server_A is 5.8.8.
So I got rid of use 5.010; because it actually wasn't necessary, but then I have a similar problem with my modules (DBI and DBD::mysql). I get:
Can't locate DBI.pm in #INC (#INC contains.. [my Perl PATH from server_A])
at perlfile.pl line 4
I was expecting the ssh heredoc call to update.sh (from server_A) to run exactly as update.sh does if I call it on server_B, but instead it seems like it's trying to use my programs from server_A on server_B, which I find weird. Can anyone help me understand why it's happening? I feel like I'm misunderstanding something fundamental about how ssh works.
server_A is AIX with ksh
server_B is AIX with bash
Edit - since some of you voted to the effect that I haven't done my research, here's what else I've tried. I didn't mention because I don't understand them fully, these are just guesses based on other SO posts & hunches. It'd be disingenuous if I gave the impression I knew what I was talking about.
If this is a duplicate, which question should I be looking at? If this is a "just read the manual situation", which one? What should I look for?
Read man ssh looking for clues related to environment variables, didn't find anything I understood
Tried running with -t
Tried running with -t -t
Did log in remotely with ssh and manually running it - this DOES work
Sourced my .bash_profile in the update script
Tried to re-assign PATH as the remote server's PATH when ssh
Tried using a different delimiter for the heredoc
Tried < instead of <<
Tried without the "-"
Edit 2 with Saigo's help below I determined that when in interactive ssh, if I echo $PATH I do get the target server's $PATH, but in a shell script I don't. That led me to this:
https://serverfault.com/questions/643333/different-bash-path-variables-when-using-ssh-script-vs-interactive-ssh
where I found out that scripted ssh doesn't call .bashrc, but interactive ssh does. So it looks like I was on the right track trying to source .bash_profile inside the scripted SSH heredoc, just need .bashrc not .bash_profile - however I don't have a .bashrc on the target server. I do have .profile but when I source that, I get an error stating it's for interactive bash sessions only. So now I'm just trying to find whatever file would contain my $PATH variable because it's apparently not .bashrc as there isn't one in there.
Edit 3 - tried hard-coding the PATH variable into a file and sourcing that and even then when I echo $PATH I get the origin server's PATH variable. It is reading the file in correctly, I also assigned another test variable and echoed that as part of the script. I tried sourcing /etc/profile and no luck.
I found a solution that works perfectly. I wasn't able to get it to work with ~/.bashrc, ~/.bash_profile, or ~/.ssh/rc but still not sure why it's not picking up my environment variables even with sourcing these.
Since it works when I manually ssh in and then run the commands one-by-one, I used these arguments to run ssh in a forced interactive login.
ssh server_B bash --login -i "~/perl/update.sh"
See these for more:
https://superuser.com/questions/564926/profile-is-not-loaded-when-using-ssh-ubuntu
https://unix.stackexchange.com/questions/46143/why-bash-unable-to-find-command-even-if-path-is-specified-properly
Hope this is useful for someone in the future. Thank you for your assistance Saigo.
How can I determine the default shell program in Emacs?
On an Ubuntu machine when I go to term mod (M-x term) or Emerge, it tries to run /bin/bash
On anther machine, Emacs tries to run /bin/false and I want to fix this problem.
Could you please help me to fix this issue?
That looks like a user configuration issue - Emacs is most likely using the default shell and it's a common way to prevent users from getting shell access by setting the shell to /bin/false or /bin/nologin (or variations thereof).
The remedy is to get the sysadmin to give you shell access as in a proper shell configured for your user account instead of /bin/false.
Thanks to Steve Howard, The problem can be solved by changing SHELL to /bin/bash
After some search about it I created a ~/.hushlogin file and it worked, but only for new windows. Is there a way to make it work for new tabs too?
On Mavericks, creating the empty file ~/.hushlogin removes the line “Last login”, for new windows and new tabs.
On my Mac it works.
Solution
This is running OS X 10.8.3. I haven't tested it on other versions, but so long as Terminal has the above option, then it should work.
In Terminal.app, go to Preferences->Settings and select the profile you're using. Go to the 'Shell' tab and under the 'Startup' heading, check 'Run command:' and enter into the box:
login -fpql your-username /bin/bash
Substitute your-username with your actual Unix username. If you use a shell other than the default bash shell, replace /bin/bash with the full path to that shell (yes, even if you've already set it in Preferences->Startup.)
Make sure 'Run inside shell' is unchecked.
If you have the "Prompt before closing: Only if there are processes other than login shell and:" option selected, add "login" and "bash" to the list of processes it will not prompt for.
Make sure you have a ~/.bashrc file, since this will be the file bash uses on startup from now on rather than ~/.bash_profile. I just have one file reference the other using this method. You also need to be sure it sources /etc/profile.
Explanation
We want to run login with the -q option to tell it to supress the "Last login" message, even in the absence of a .hushlogin file. (As noted above, login will only look in cwd for that file, not your home directory, so you'd need a .hushlogin file in every directory you'd open a shell to, for that method to work.)
The problem is Terminal runs something like login -pfl your-username /bin/bash -c exec -la bash /usr/local/bin/bash when you create a new shell (I'm using homebrew's version of bash, hence the weird bash path at the end,) which lacks the -q flag.
Unfortunately, there's no way to directly change the arguments Terminal uses, so we just trampoline a new login session with login -pfql from Terminal's default login -pfl session. Inelegant, but it works.
We need to have the -q option and the path to bash to keep the "New windows/tabs open with: Same Working Directory" option working. If you don't care about that option, you can remove that flag and argument, and probably avoid the .bashrc stuff above.
you could just add a clear to your .bash_profile
Adding ~/.hushlogin is fine unless you want to open a new tab in the same folder, or open Terminal from Finder on the exact folder, in that case it won't work.
Changing a running command to another login is something I would like to avoid because of the strange unnecessary scheme login -> login -> zsh. You can see it in Activity Monitor, but also it will show up when you are quitting interactive programs (like, python repl) in the message that python, login and zsh are running.
Putting clear in ~/.zshrc is not ideal since on mac it just prints a lot of newlines (and if you scroll back, you'll see them).
The best way that I found up to this point is adding printf '\33c\e[3J' to ~/.zshrc (or in Terminal/Preferences/Profiles/Shell/Startup/Run command with Run inside shell checked). I chose beginning of ~/.zshrc file since startup command is running after it and if the ~/.zshrc file is heavy you can briefly see Last Login message before printf is executed.
This might be OS version dependent. On Terminal 2.3 (on 10.8), touching the file ~/.hushlogin suppresses the 'last login' message for new tabs as well as new windows. That is, it Works For Me.
Just in case it helps to work out what's going on (and in case you don't know), note that the 'last login' message is in principle coming from login(1), and not the shell. Or, more precisely, if a shell is invoked in a particular way (including starting it with the -l option), then bash will "act as if it had been invoked as a login shell" (zsh may have a similar feature, though I can't find it right now). Now, it could be that when Terminanl opens up a new tab in your OS X version, the shell is effectively simulating opening a login shell, and maybe getting this detail wrong. But if you have the 10.8 version of bash/zsh (namely 3.2.48 / 4.3.11), then I don't know what might be amiss.
A simple solution without changing anything related to login would be just to add the clear command in the end of your ~/.bashrc or ~/.zshrc file. It will clear the terminal in initialization from any initialization prints. It works for me very well.
On my MacOS Big Sur 11.1 it works.
I have installed DB2 in my ubuntu 10.04 and meanwhile it has created 2 new users. and to run the db2 i have to switch to the new user created by the DB2.
But this new user's terminal has less features i.e. it donot automatically complete the directory or filename by hitting tabs, can't use up/down/left/right arrow keys. and not colorful like my actual terminal in my default user of ubuntu.
Please Help.
Thanks in advance:)
Change the users shell to /bin/bash, instead of /bin/sh.
# usermod -s /bin/bash YourDB2User
Since some time now, both Debian and Ubuntu uses dash to provide /bin/sh, which doesn't have all the features like bash, but provides a more accurate interpretation of the bourne shell, from what I understand.
this new users should not do anything except executing the command/demon, so they dont need a terminal. they should have as little rights as possible - thats part of the trick. if you want to execute a command as this user, try sudo -u(newuser) command
I'm using Ubuntu 9.04 x64 and,
I have a file startup.rb in which I call sudo bash, so that I always have a root console to do administrative tasks without typing password after every 15 minutes or so.
This script is called by another script Startup.rb, and content of both files are like this -
File ~/Startup.rb
#!/usr/bin/ruby
system "gnome-terminal --maximize -x ruby ~/startup.rb"
File ~/startup.rb
#!/usr/bin/ruby
`sudo some-repetitive-administrative-task`
....
....
`sudo bash` #Not using `sudo -i`, since that makes `pwd` -> /root
I have included the ~/Startup.rb file in Startup Applications list.
Now the problem is that, in the terminal of sudo bash, if I type something and expect some output, I don't get any. So if I write echo hello world, I don't get any output. Which leads me to believe that the standard output (stdout) of the sudo bash command is not the console.
So, I want to know why is this happening? How may I know the current stdout path? Or how can I restore stdout back to my current console?
-- thanks
You're using an inapproriate method to run system commands from Ruby. Try this instead:
#!/usr/bin/ruby
system 'bash'
The syntax you're using (with the backticks) captures the standard output of the command and returns it in a string. That's why you don't see it on the terminal.
Here's a nice review of the different ways to run commands from Ruby: 6 Ways to Run Shell Commands in Ruby.
If you are only interested in an easier way to run administrative tasks as root, there might be a few other things you might consider.
$sudo -s
This will give you a shell in which you can submit commands as your sudo'd self (assuming that sudo has been setup so that you can run a shell via sudo).
Another thing you can do, though not always recommended or considered good form in Ubuntu is to create a root account:
$sudo passwd root
then you can login as root and administer things that way.
I know this doesn't answer your specific question about ruby, but I hope you find it helpful.