I need wget to be always used with --no-check-certificate option. This can be accomplished by typing the following line in a Unix terminal:
alias wget='wget --no-check-certificate'
However, when I execute shell scripts .sh that include wget command, the original wget is used not the aliased one. How can I resolve this issue?
You have to ensure your alias is defined, where the Shell-script is also sourcing it. If you are using Bash and the Shell-script is using /bin/bash as interpreator, putting into file .bashrc might bei a good idea.
However, --no-check-certificate is in about 99.9% of all cases a very bad idea as SSL is there for a reason.
Also I recommend not to overwrite common commands with custom aliases as this might change behavior of tools a script is relying on in unexpected way. I really recommend to fix up the environment so you don't need this dirty hack.
Related
I have several bash aliases set in my .bashrc but they generate errors every time I open a new terminal. Each time a new terminal opens, two bash: cd: too many arguments will appear. The aliases work as intended, but I would like to solve the errors anyway. Here are the aliases in question:
alias .1="cd .."
alias .2="cd ../.."
alias .3="cd ../../.."
alias .4="cd ../../../.."
alias .5="cd ../../../../.."
alias .=".1" #Trouble maker
alias ..=".2"
alias ...=".3"
alias ....=".4"
alias .....=".5"
I have narrowed it down to alias .=".1" as the culprit creating the errors. I understand the . is its own command and I am slapping an alias on top of it. I am not sure this is the issue or not, but I have noticed when I remove this line the errors disappear. Furthermore, running the alias on the CLI itself does not generate the same errors... only when in the .bashrc does it generate the errors.
Things I have tried:
Quotations on both sides of =
Changing alias .=".1" to alias .="cd .."
Adding a space before alias command in an attempt to suppress output
Aliasing . means you are changing how subsequent shell commands include other shell scripts. Since . and source do the same thing in bash you might be able to fix this by making sure that they're only using source. Look in .bash_profile for instance. Bash looks at a variety of files while it is starting and .bashrc is probably getting read by .bash_profile and something in there is trying to . some other file.
But really, why? Can you just add a dot to each of these and be ok with it? The .. directory is one level up so that could make it easier to remember. Changing things like this that are fundamental to how the shell operates and glues together multiple scripts is going to keep tripping you up.
The alias that is causing the error is: alias .=".1". The single period is a synonym for the source command, which reads in and executes commands from the file you pass as its argument.
What you're essentially doing (unintentionally), is trying to change the behavior of the source command using an alias.
I've got a makefile for installing my personal repo of config files, part of which is compiling my emacs scripts:
compile:
emacs -batch --eval "(progn (load \"~/.emacs\") (byte-recompile-directory \"~/.emacs.d\" 0))"
The problem is, on OSX, I have an alias called "emacs" that points to the Emacs.app binary for use in a terminal, this is defined in my ~/.bash_profile.
Now, no matter what I do, I can't seem to get the shell that Make is calling to read a startup file to load that alias, so that compilation step always fails.
Does anyone know how to do this?
.bash_profile is only read by interactive login shells. Exported environment variables set in it are inherited through the process environment, which means that these settings are generally available to all programs the user starts (if bash is indeed the login shell, of course).
No such inheritance happens for aliases, though. Bash supports exported functions, but that's an obscure feature which can easily break other programs (for example, those which assume that environment variable values do not contain newlines). If you go that route, you may have to use .bashrc instead, to make sure that these functions are exported by interactive bash shells which are not login shells.
I expected the easiest solution is to put a directory like $HOME/bin on the PATH (in .bash_profile or .bashrc, whatever works best) and put an emacs wrapper script into that directory which invokes the actual binary using exec /path/to/Emacs.app "$#" (or maybe just a symbolic link would do).
That is very strange. Aliases are not exported to sub-shells, and the .bash_profile script is only run by interactive shells: make doesn't invoke an interactive shell (by default). So, it's hard to understand how the shell make invokes would see that alias based on the information you've provided.
Maybe you set the BASH_ENV shell variable somewhere? You should never do that, unless you really know what you're doing.
Maybe you reset make's .SHELLFLAGS variable to force a login shell? You shouldn't to that either.
Anyway, you can try using command which avoids aliases etc. Unfortunately make doesn't know this is a shell-built in, so you have to convince it to run a shell. This will be fixed in the next release of GNU make but Apple will never ship that.
compile:
command emacs -batch --eval "(progn (load \"~/.emacs\") (byte-recompile-directory \"~/.emacs.d\" 0))" && true
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.
This is my script to automate the git push of my static blog.
When I run each command one by one in the Terminal, it works. Do I need to add delays, maybe it's going too fast. The pelican command (static website generator) takes quite a lot of time (2 seconds). Is the rest of the script crashing during that?
#!/bin/sh
dropbox
cd blog
pelican . -s /Users/Paul-Arthur/Desktop/Desktop/Dropbox/blog/pelican.conf.py -t subtle
cd output
git add .
git commit -m 'commit'
git push
Updated: Sorry, yeah dropbox is a custom command in my bash_profile (this is not the problem, it works I know ;) ).
Sadly, when I click my script, it executes (but does not work) extremely quickly so I cannot see the errors.
Here is the output from the calepin command. The errors are normal and I expect it to run with that. Do you think that this is the problem? If so what can I do?
familys-imac:blog Paul-Arthur$ pelican . -s /Users/Paul-Arthur/Desktop/Desktop/Dropbox/blog/pelican.conf.py -t subtle
ERROR: Skipping ./articles/aboutme.md: impossible to find informations about 'title'
ERROR: Skipping ./articles/static_sites.md: impossible to find informations about 'title'
familys-imac:blog Paul
It might be due to the « cd » command, since it's not a command, it is a builtin from the shell, and doesn't act like a command.
To debug it, try adding «pwd» command inside your script before and after the «cd» line, to be sure the working directory has change.
It could also be due to the shell you are using, in the shebang (first line of your script), you are using the /bin/sh script. Is it the good one ? When you do it in your shell, you are maybe using another like bash, dash, zsh etc.
To determine that, type that in your current shell :
which `echo $0`
You will get an answer like :
/bin/bash
or something like this. Use this in your shell script :
#!/bin/bash
And try again your script.
Good luck with your project.
I would like to know if there is a (simple) solution to the following issue:
When I log in with ssh to a specific host, I would like to automatically execute a (bash)script on that host. This way I could -for example- load my aliases on that host.
Definitively the bashrc script is not executed; The ssh configuration files do not seem to help in this issue either.
Any suggestions?
Thanks in advance!
BTW: The host is running on Gentoo
If .bashrc isn't being run, try .profile, which has a similar function. Different shells use different startup scripts at different times, so knowing when to run things is useful.
On many systems where you have a choice of which shell to use, you are put through ~/.profile only. This way there is no need to find out (and no probably wrong guessing) which shell you're running in and which profile to actually load (.bashrc, .cshrc, .kshrc etc.) and which ones to avoid loading.
The easiest solution in your case would be to create a link (a symbolic one if you prefer visibility) to your favourite shell's startup script as in ln -s ~/.bashrc ~/.profile. If you don't intend to ever using anything other than bash, you're set.