I'm trying to set a fake date via bash script
I'm using the following commands:
#!/bin/bash
echo 'myPass' | sudo -s 'date -s "1 NOV 2011 09:00:00"'
But I'm getting command error.
What is the right way to do it ?
sudo does not read the password from standard input by default, but from the terminal itself, so you cannot pipe your password into sudo this way. You need to use the -S option to read from standard input.
echo "myPass" | sudo -S date -s "1 NOV 2011 09:00:00"
(note that you don't need to use the -s (lowercase) option; sudo can run date directly without starting an intervening shell).
Exposing your password like this, however, is a security risk. It would be better to configure sudo to allow you (or anyone who is intended to run this script) to run
this particular date command without a password.
For sudo, the first parameter without a dash is the command to execute, the following parameters are the arguments to give to that command. If you wrap the command and its arguments together in quotes (e.g. "echo foo"), then sudo tries to execute the command "echo foo" instead of the command "echo" with parameter "foo". Hence, you need to omit the outermost quotes:
sudo date -s "1 NOV 2011 09:00:00"
Related
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.
Why the output file from this is owned by root and not w3svcsadm?
sudo -u w3svcsadm echo "TEST ran" > /home/your/emaildigest/TEST_$( date +%Y%m%d%H%M%S ).output
I'm running into some issues with cron, and I believe this is the key to my problems.
Using the -u flag with sudo executes the command 'echo "TEST ran"' as the user w3svcasadm, but that command isn't the thing doing the work of outputting to a file, which is done by the '>' operator. By the time bash is using that operator, it's already switched back to the user running the shell. If that user is root, then the file will be created under root. In your script, you could use "su w3svcsadm" to switch the shell user before executing that command, then you wouldn't have to use that -u flag at all.
I want to run multiple commands automatically like sudo bash, ssh server01, ls , cd /tmp etc at server login..
I am using Remote command option under SSH in putty.
I tried multiple commands with delimiter && but not working.
There is a some information lacking in your question.
You say you want to run sudo bash, then ssh server01.
Will sudo prompt for a password in your remote server?
Assuming there is no password in sudo, running bash will open another shell waiting for user input. The command ssh server01 will not be run until that bash shell is exited.
If you want to run 2 commands, try first simpler ones like:
ls -l /tmp ; echo "hi there"
or if you prefer:
ls -l /tmp && echo "hi there"
Does this work?
If what you want is to run ssh after running bash, you can try :
sudo bash -c "ssh server01"
That is probably because the command is expected to be a program name followed by parameters, which will be passed directly to the program. In order to get && and other functionality that is provided by a command line interpreter such as bash, try this:
/bin/bash -c "command1 && command2"
I tried what I suggested in my previous answer.
It is possible to run 2 simple commands in putty separated by a semicolon. As in my example I tried with ls and echo. The remote server runs them and then the session closes.
I also tried to ssh to a remote server that is configured for not asking for a password. In that case, it also works, I get connected to the 2nd server and I can run commands on it. Upon exit, the 2 connections are closed.
So please, let us know what you actually need / want.
You can execute two consecutive commands in PuTTY using a regular shell syntax. E.g. using ; or &&.
But you want to execute ssh server01 in sudo bash shell, right?
These are not two consecutive commands, it's ssh server01 command executed within sudo bash.
So you have to use a sudo command-line syntax to execute the ssh server01, like
sudo bash ssh server01
I'm having trouble with the following bash script:
#!/bin/bash
myPassword="foobar"
su - postgres <<-'EOF'
echo $myPassword # nil
EOF
echo $myPassword # foobar
How can I access or pipe the contents of $myPassword from within the postgres user session?
Tried it with and without export with not luck.
You're using 'EOF' for the heredoc marker. So no substitution happens. Remove the quotes around that if you want variable substitution inside the block. See Heredocs And Herestrings.
You could also keep what you have, but use the -p (or -m or --preserve-environment) option of su which might work better for you.
(I'm sure there's no need to remind you that keeping passwords in scripts is unsafe. And a process's environment can be inspected with sufficient privileges, so it's not a great place for passwords either.)
you probably need to escape \$mypassword so that it doesn't get resolved in the original script before calling su
also, you can pass -c to su in order to pass something from the environment to the spawned shell:
user1:~$ X=foo su -c "bash -c \"whoami && echo \$X\"" user2
Password:
user2
foo
This su command should work:
myPassword="foobar"
su postgress -c "echo $myPassword"
i want to do something like:
schroot -c name -u root "export A=3 && export B=4"
but I get the error:
Failed to execute “export”: No such file or directory
In other words, I want to be able to programmatically execute shell commands inside the schroot environment. What is the right way to get this behavior?
I recommend:
schroot -c name -u root sh -c "export A=3 && export B=4"
or better:
schroot -c name -u root -- sh -c "export A=3 && export B=4"
This runs the shell with the '-c' option telling it (the shell) to read the following argument as the command (script) to be executed. The same technique works with other analogous commands: 'su', 'nohup', ...
The -- option terminates the arguments to schroot and ensures that any options on the rest of the command line are passed to and interpreted by the shell, not by schroot. This was suggested by SR_ in a comment, and the man page for schroot also suggests it should be used too (search for 'Separator'). The GNU getopt() function by default permutes arguments, which is not wanted here. The -- prevents it from permuting the arguments after the --.
schroot -c name -u root -- export A=3 && export B=4
Ensuring that /etc/schroot/schroot.conf has
run-exec-scripts=true
run-setup-scripts=true
You could try
schroot -c name -u root "/bin/bash -c 'export A=3; export B=4'"
but this is the first time i've heard of schroot. And the exports look like they're useless...even running the double-quoted stuff directly from the command line, it seems the child shell doesn't want to affect the parent's environment.