I have the following lines in my .bashrc which I would like to get executed upon logging in through ssh.
csh
source /x/y/.cshrc
source /x/y/z/sourceme
But the problem is that only the first command is being executed correctly.
(csh prompt is coming up)
The following source command is not effected.
I noticed that there are some errors which are thrown from bash (not csh) for the 'source' command
I read somewhere that this may be due to .bashrc getting executed multiple times. And source commands trying to get executed in bash itself rather than csh.
I want all the three commands to be executed one after other upon log-in. how can I do that? I tried .bash_profile .bash_login etc. Also I don't have write access to /etc/profile
The "commands" are interpreted by the bash shell. They aren't bytes to be fed to the terminal. What happens is that csh runs interactively, and once it exits bash will source the two (presumably csh) script files.
It looks like you're simply trying to change your shell to csh (why, I have no idea). Have you tried using chsh for that?
If you want to run these commands in csh, move them to your .cshrc.
A word of caution, though; using csh for absolutely anything raises the question, do you really think you know what you are doing? Why?
source is a "bashism", that is to say it won't work in other shells. Use . instead.
Related
I have a bash script where I make a few changes to the .bashrc. I then want to run the bashrc from my script so I've been running
source ~/.bashrc
to avoid having to reload my shell. The problem I've been seeing is that it's only being set in the subshell bash is running in.
Can I do anything from my script so that the source command is run in the parent shell?
What you could do, if you really wanted to: Provide a shell function which checks whether .bashrc has been modified, and if it is the case, sources this file. Let#s call this function check_reload. Then define your PS1 as
PS1='$(check_reload) .....'
With this setup, your .bashrc will be reloaded before you get a new command line.
While this should solve your problem, I personally would not do it: I consider the information in .bashrc fairly static, and I would not use a script to modify it, but do it manually with a text editor. But of course everyone can do this as he likes....
according to less manual,
!command Execute the shell command with $SHELL.
I have an alias pbcopy='nc localhost 2224'
I tested but get
!pbcopy
/bin/bash: pbcopy: command not found
!done (press RETURN)
What I tried
put alias in .bash_profile, .bashrc, .profile, none of them works
!source .bash_profile in less. not working
!alias pbcopy='nc localhost 2224'
I really need some help to understand this.
aliases are not commands.
Your shell is likely not loading them.
And if it is loading them they aren't available in non-interactive shells by default so they still won't work without you explicitly turning aliases on.
Either create that as a shell function or as a shell script in your $PATH.
It is also almost certainly the case that each !cmd invocation is started in a new shell so you cannot carry assignments, variables, functions, etc. from one to the next.
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.
I am quite the novice and I messed something up awhile back. I do not know what I did, but now whenever I start up a new terminal I constantly have to export LIBRARY_PATH=/opt/local/lib. This is the default path for OSX I thought, and I think I might have voided it somehow.
It has just become so annoying to type that every time I want to run something like a gsl library, where are the default paths for bash on osx set? Thanks for any help you can offer.
You can add it to ~/.bash_profile
ยง Invocation
When bash is invoked as an interactive login shell, or as a non-interactive shell
with the --login option, it first reads and executes commands from the file
/etc/profile, if that file exists. After reading that file, it looks for
~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and
executes commands from the first one that exists and is readable.
Ok, I hope this question makes some sense but what is the difference between a bash shell and a bash terminal? Example. When I first open up terminal I have a prompt with my current dir and my user name. In the terminal window header it says -bash- , when I type echo $SHELL I get bash. So by default the shell is bash. Where my confusion comes into play is when I type bash. My prompt then goes to bash-3.2$.Obviously it's a different mode. Are ther any major differences? I have read the man page with no answer. I understand what a bash shell is but just do not get the difference. Thanks for the clarity in advance.
There is no difference, they are both instances of the bash shell.
The reason you are seeing a different prompt is that your initial login shell sources ~/.bash_profile where presumably you have your prompt set. When you type bash it invokes another shell but because this one isn't a login shell, it doesn't source ~/.bash_profile and so you get the default prompt.
If you were call bash -l, (which invokes bash as if it were a login shell) I bet you would see that your original prompt remains