My question:
After the following lines in my script, the script ends unexpectedly. I am trying to enter chroot inside of a bash script. How can I make this work
I am writing a script that installs Gentoo
echo " Entering the new environment"
chroot /mnt/gentoo /bin/bash
source /etc/profile
export PS1="(chroot) ${PS1}"
chroot command will start new child bash process, so rest of your script will not be executed until you quit from child bash process.
So instead of /bin/bash just run your script in chroot:
chroot /mnt/gentoo myscript.sh
myscript.sh:
#!/bin/bash
echo " Entering the new environment"
source /etc/profile
export PS1="(chroot) ${PS1}"
I do this in a script:
read direc <<< $(basename `pwd`)
and I get:
Syntax error: redirection unexpected
in an ubuntu machine
/bin/bash --version
GNU bash, version 4.0.33(1)-release (x86_64-pc-linux-gnu)
while I do not get this error in another suse machine:
/bin/bash --version
GNU bash, version 3.2.39(1)-release (x86_64-suse-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
Why the error?
Does your script reference /bin/bash or /bin/sh in its hash bang line? The default system shell in Ubuntu is dash, not bash, so if you have #!/bin/sh then your script will be using a different shell than you expect. Dash does not have the <<< redirection operator.
Make sure the shebang line is:
#!/bin/bash
or
#!/usr/bin/env bash
And run the script with:
$ ./script.sh
Do not run it with an explicit sh as that will ignore the shebang:
$ sh ./script.sh # Don't do this!
If you're using the following to run your script:
sudo sh ./script.sh
Then you'll want to use the following instead:
sudo bash ./script.sh
The reason for this is that Bash is not the default shell for Ubuntu. So, if you use "sh" then it will just use the default shell; which is actually Dash. This will happen regardless if you have #!/bin/bash at the top of your script. As a result, you will need to explicitly specify to use bash as shown above, and your script should run at expected.
Dash doesn't support redirects the same as Bash.
Docker:
I was getting this problem from my Dockerfile as I had:
RUN bash < <(curl -s -S -L https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer)
However, according to this issue, it was solved:
The exec form makes it possible to avoid shell string munging, and
to RUN commands using a base image that does not contain /bin/sh.
Note
To use a different shell, other than /bin/sh, use the exec form
passing in the desired shell. For example,
RUN ["/bin/bash", "-c", "echo hello"]
Solution:
RUN ["/bin/bash", "-c", "bash < <(curl -s -S -L https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer)"]
Notice the quotes around each parameter.
You can get the output of that command and put it in a variable. then use heredoc. for example:
nc -l -p 80 <<< "tested like a charm";
can be written like:
nc -l -p 80 <<EOF
tested like a charm
EOF
and like this (this is what you want):
text="tested like a charm"
nc -l -p 80 <<EOF
$text
EOF
Practical example in busybox under docker container:
kasra#ubuntu:~$ docker run --rm -it busybox
/ # nc -l -p 80 <<< "tested like a charm";
sh: syntax error: unexpected redirection
/ # nc -l -p 80 <<EOL
> tested like a charm
> EOL
^Cpunt! => socket listening, no errors. ^Cpunt! is result of CTRL+C signal.
/ # text="tested like a charm"
/ # nc -l -p 80 <<EOF
> $text
> EOF
^Cpunt!
do it the simpler way,
direc=$(basename `pwd`)
Or use the shell
$ direc=${PWD##*/}
Another reason to the error may be if you are running a cron job that updates a subversion working copy and then has attempted to run a versioned script that was in a conflicted state after the update...
On my machine, if I run a script directly, the default is bash.
If I run it with sudo, the default is sh.
That’s why I was hitting this problem when I used sudo.
In my case error is because i have put ">>" twice
mongodump --db=$DB_NAME --collection=$col --out=$BACKUP_LOCATION/$DB_NAME-$BACKUP_DATE >> >> $LOG_PATH
i just correct it as
mongodump --db=$DB_NAME --collection=$col --out=$BACKUP_LOCATION/$DB_NAME-$BACKUP_DATE >> $LOG_PATH
Before running the script, you should check first line of the shell script for the interpreter.
Eg:
if scripts starts with /bin/bash , run the script using the below command
"bash script_name.sh"
if script starts with /bin/sh, run the script using the below command
"sh script_name.sh"
./sample.sh - This will detect the interpreter from the first line of the script and run.
Different Linux distributions having different shells as default.
I have a script that I am trying to submit to a SGE cluster (on Redhat Linux). The very first part of the script defines the current folder from the full CWD path, as a variable to use downstream:
#!/usr/bin/bash
#
#$ -cwd
#$ -A username
#$ -M user#server
#$ -j y
#$ -m aes
#$ -N test
#$ -o test.log.txt
echo 'This is a test.'
result="${PWD##*/}"
echo $result
In bash, this works as expected:
CWD:
-bash-4.1$ pwd
/home/user/test
Run script:
-bash-4.1$ bash test.sh
This is a test.
test
When I submit the job to the cluster:
-bash-4.1$ qsub -V test.sh
and examine the log file:
This is a test.
Missing }.
Does anyone know why the job submission is saying "Missing } " when it works right from the command-line? I'm not sure what I'm missing here.
Thanks.
The posix standard for batch schedulers requires them to ignore the #! line and instead use either a shell configured into the cluster or one selected by the -S option of qsub. The default is usually csh. So adding something like #$ -S /usr/bin/bash into the script will cause it to be interpreted by bash.
Alternatively you could convince the cluster admin to change the queues to unix_behavior from posix_compliant.
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.
When I run the script command it loses all the aliases from the existing shell which is not desired for people using lots of aliases. So, I am trying to see if I can automatically source the .profile again to see if it works without the user have to do it.
Here below is the code:
#!/bin/bash -l
rm aliaspipe
mkfifo aliaspipe
bash -c "sleep 1;echo 'source ~/.bash_profile' > aliaspipe ;echo 'alias' > aliaspipe ;echo 'exec 0<&-' > aliaspipe"&
echo "starting script for recording"
script < aliaspipe
Basically I am creating a named pipe and the making the pipe as stdin to the script program, trying to run the source command and then close the stdin from pipe to the terminal stdin so that I can continue with the script.
But when I execute, the script is exiting after I execute "exec 0<&-",
bash-3.2$ exec 0<&-
bash-3.2$ exit
Script done, output file is typescript
Not sure why the exit is called and script is terminated. If I can make the script move the stdin from pipe to terminal then it should be fine.
You can get script to execute a bash login shell by telling it to do so explicitly.
# Gnu script (most Linux distros)
script -c "bash -l"
# BSD script (also Mac OS X)
script typescript bash -l
That will cause your .bash_profile to be sourced.
By the way, redirections are not stacks. When you write exec 0<&-, you're closing standard input, and when bash's standard input is closed, it exits.