I have the following bash code which I want to run within a perl script. As a bash script the code runs without any error. But in the perl script it gives the error: Bad name after bash' at ./061_rewrite_aws.pl line 48.
system(' 'bash' '-c' <<'END_SHELL_CODE';
AWS_Base="/run/user/1000/gvfs/smb-share:server=192.168.0.205,share=zmd-backup"
pushd /home/zmd/AWS/AWS_DataDirs
cp -R $AWS_Base/* ./
popd
'END_SHELL_CODE' ');
Assistance will be appreciated
I think there's just some quoting errors with that line of perl.
system takes a list of strings as arguments, so I changed that quoting to be a list of strings.
Right now I think perl is parsing that line and expecting bash to be the name of some variable.
The here-doc formatting was off. I think the ; after END_SHELL_CODE on the first line, and having END_SHELL_CODE in single quotes at the end didn't work with perl's formatting, so I removed that.
Something like this worked for me:
system('bash', '-c', <<'END_SHELL_CODE'
AWS_Base="/run/user/1000/gvfs/smb-share:server=192.168.0.205,share=zmd-backup"
pushd /home/zmd/AWS/AWS_DataDirs
cp -R $AWS_Base/* ./
popd
END_SHELL_CODE
);
Related
i am writing a shell script practice.sh. I want to give my first argument $1 from command line to ls command in script.e.g
if I run my script in terminal $bash practice.sh *.mp3
the argument *.mp3
I want to use for ls command
#!/bin/bash
output=$ls $1
it doesn't work
any help?
The obvious answer for what you say you want is just
#!/bin/bash
ls "$1"
which will run ls, passing it (just) the first argument to the script.
However, you also say you want to run this like: practice.sh *.mp3 which runs the script with many arguments (not just one) -- the *.mp3 will be expanded to be all the of the .mp3 files in the current directory. For that, you likely want something more like
#!/bin/bash
ls "$#"
which will pass all of the arguments to your script (however many there are) to the ls command.
These scripts will just run ls with its stdout connected to whatever your script has its stdout connceted to, so the output will (likely) just appear on your terminal. If you instead want to capture the output of the ls command (so you can do something else with it), you need something like
#!/bin/bash
output=$(ls "$#")
which will run ls with all the arguments, and capture the output in the variable $output. You can then do things with that variable.
Use shell expansion to record the output of the command in the variable output:
output=$(ls $1)
This will record the output of the command ls $1 in the variable output.
You can then use echo $output to print out your output.
You can read more about shell expansion in the GNU Bash reference manual.
In one of my Bash scripts, there's a point where I have a variable SCRIPT which contains the /path/to/an/exe, and what the script ultimately needs to do, is executing that executable. Therefore the last line of the script is
$($SCRIPT)
so that $SCRIPT is expanded to /path/to/an/exe, and $(/path/to/an/exe) executes the executable.
However, running shellcheck on the script generates this error:
In setscreens.sh line 7:
$($SCRIPT)
^--------^ SC2091: Remove surrounding $() to avoid executing output.
For more information:
https://www.shellcheck.net/wiki/SC2091 -- Remove surrounding $() to avoid e...
Is there a way I can rewrite that $($SCRIPT) in a more appropriate way? eval does not seem to be of much help here.
$($SCRIPT) indeed does not do what you think it does.
The outer $() will execute any commands inside the parenthesis and execute the result string.
The inner $SCRIPT will expand to the value of the SCRIPT variable and execute this string while splitting words on spaces/
If you want to execute the command contained into the SCRIPT variable, you just write as an example:
SCRIPT='/bin/ls'
"$SCRIPT" # Will execute /bin/ls
Now if you also need to handle arguments with your SCRIPT variable command call:
SCRIPT='/bin/ls'
"$SCRIPT" -l # Will execute /bin/ls -l
To also store or build arguments dynamically, you'd need an array instead of a string variable.
Example:
SCRIPT=(/bin/ls -l)
"${SCRIPT[#]}" # Will execute /bin/ls -l
SCRIPT+=(/etc) # Add /etc to the array
"${SCRIPT[#]}" # Will execute /bin/ls -l /etc
It worked for me with sh -c:
$ chrome="/opt/google/chrome/chrome"
$ sh -c "$chrome"
Opening in existing browser session.
It also passed the ShellCheck without any issues.
with bash, just use $SCRIPT:
cat <<'EOF' > test.sh
SCRIPT='echo aze rty'
$SCRIPT
EOF
bash test.sh
produce:
aze rty
I'm trying to write a program that takes a file's name, and puts the date on it. So I'm trying to get substrings for the filename itself, and the extension.
I'm new to BASH so maybe I'm missing something here, but following online guides, it seems like this should work-
#!/bin/bash
echo "Type filename in this dir"
read filename
file=`filename%.*`
end=`filename##*.`
today=`date +%d-%m-%y`
dated="${file}_${today}.${end}"
cat $filename > $dated
But the computer returns these errors-
./fileDater.sh: line 5: filename%.*: command not found
./fileDater.sh: line 6: filename##*.: command not found
I'm using an Ubuntu Subsystem on Windows 10, if that's important.
It seems you've got some confusion about bash substitution; You're trying to execute a command sub-shell instead (eg. `variable##*.`) — it should be using ${ ... } .
#!/bin/bash
echo "Type filename in this dir"
read -r filename
file=${filename%.*}
end=${filename##*.}
today=$(date +%d-%m-%y)
dated="${file}_${today}.${end}"
cat "$filename" > "$dated"
I haven't tried your script, although I believe that is your main issue.
EDIT: Regarding the use of backticks (`...`)
In the form of `COMMAND` it's more or less obsolete for Bash, since it has some trouble with nesting ("inner" backticks need to be escaped) and escaping characters.
Use $(COMMAND) instead — it's also POSIX!
↳ Bash Hackers Wiki - Command Substitution
I am pulling my hair out try to get a script to work on cygwin. Here's the latest version of the script I am trying to run:
$ cat start_vm_2.sh
#!/bin/sh
VMRUN='/cygdrive/c/\"Program Files (x86)\"/VMware/VMware\ VIX/vmrun"'
echo "VMRUN is [$VMRUN]"
ARGS='-T ws start \"C:\\Users\\red\\Documents\\Virtual Machines\\myvm-dev-006 \(2\)\\myvm-dev-006 \(2\).vmx\"'
echo "ARGS is [$ARGS]"
And this is the error message I get:
$ ./start_vm_2.sh
VMRUN is [/cygdrive/c/\"Program Files (x86)\"/VMware/VMware\ VIX/vmrun"]
ARGS is [-T ws start \"C:\\Users\\red\\Documents\\Virtual Machines\\myvm-dev-006 \(2\)\\myvm-dev-006 \(2\).vmx\"]
./start_vm_2.sh: line 8: /cygdrive/c/\"Program: No such file or directory
You should run it as bash instead and store your arguments as arrays. Also, do not add literal quotes to your spaces:
#!/bin/bash
VMRUN="/cygdrive/c/Program Files (x86)/VMware/VMware VIX/vmrun"
echo "VMRUN is [$VMRUN]"
ARGS=(-T ws start 'C:\Users\red\Documents\Virtual Machines\myvm-dev-006 (2)\myvm-dev-006 (2).vmx')
echo "ARGS is [${ARGS[*]}]"
"$VMRUN" "${ARGS[#]}"
Run bash script.sh.
this might be your problem... I was having the same issue until I figured out my script had Windows special characters (cat -e script.ksh)... so I did a dos2unix to the file and it started to flow as I wanted
Hope this is useful
I'm trying to read commands from a text file and execute each line from a bash script.
#!/bin/bash
while read line; do
$line
done < "commands.txt"
In some cases, if $line contains commands that are meant to run in background, eg command 2>&1 & they will not start in background, and will run in the current script context.
Any ideea why?
if all your commands are inside "commands.txt", essentially, you can call it a shell script. That's why you can either source it, or run it like normal, ie chmod u+x , then you can execute it using sh commands.txt
I don't have anything to add to ghostdog74's answer about the right way to do this, but I can cover why it's failing: The shell parses I/O redirections, backgrounding, and a bunch of other things before it does variable expansion, so by the time $line is replaced by command 2>&1 & it's too late to recognize 2>&1 and & as anything other than parameters to command.
You could improve this by using eval "$line" but even there you'll run into problems with multiline commands (e.g. while loops, if blocks, etc). The source and sh approaches don't have this problem.