This question already has answers here:
How to store curly brackets in a Bash variable
(2 answers)
Closed 4 years ago.
I'm trying to use this variable
MediaExt="*.{mp4,mkv,avi}"
in this command
mv ${MediaSource}/${MediaExt} ${UploadDir}
but it doesn't seem to work.
Could someone help me, please? Thanks!
A command in bash is parsed in several passes. The pass that decides whether globbing (expanding *, or *.{mp4,mkv,avi}) should be performed, is occurring before the pass that expands the variables. Once the variables are expanded, there are candidate for globbing, but the decision that no globbing is required has already been made
It will work if you write the expression as:
mv ${MediaSource}/*.{mp4,mkv,avi} ${UploadDir}
You'll probably find some advise that you can use eval. Please don't!
This:
eval mv ${MediaSource}/${MediaExt} ${UploadDir}
will execute as you intended, but eval can be dangerous if you don't control the values of the variables. For example, if UploadDir could be set to:
UploadDir="somedirectory; rm -rf ~"
then eval will execute your request as two statements and remove all your files.
Related
This question already has answers here:
When to wrap quotes around a shell variable?
(5 answers)
Closed 3 months ago.
I was getting errors passing in a command and when I put quotes around that things worked just fine. Just curious how that works.
Double quotes around $# (and similarly, ${array[#]}) prevents globbing and word splitting of individual elements, while still expanding to multiple separate arguments.
See: https://github.com/koalaman/shellcheck/wiki/SC2068
This question already has answers here:
How to execute a bash command stored as a string with quotes and asterisk [duplicate]
(5 answers)
Closed 2 years ago.
I want to compose a command in a shell script like this:
#!/bin/sh
APPLICATION="date"
PARAMETER="-d '2020-01-01 1:23'"
CMD="${APPLICATION} ${PARAMETER}"
${CMD}
The 'PARAMETER' is supposed to hold parameters that need to be quoted themself. Unfortunately it does not work like this. Escaping them via PARAMETER="-d \"2020-01-01 1:23\"" also does not work.
After you've build CMD up, it is just string. It contains what can be interpreted by you as a command, but the shell sees it as a bare string.
If you want the string to reinterpret it, you need to eval it:
eval "$CMD"
However, eval is often considered evil.
This question already has answers here:
When to wrap quotes around a shell variable?
(5 answers)
Closed 3 years ago.
I have a command I want to run:
sbt "testOnly com.example.testClass"
which needs to be ran with the quotes. However, what I really want to do is be able to pass the argument in a variable, while keeping the quotes.
This does not work:
TEST_CMD="\"testOnly com.example.testClass\""
sbt $TEST_CMD
This does work:
TEST_CMD="\"testOnly com.example.testClass\""
eval sbt $TEST_CMD
I read http://mywiki.wooledge.org/BashFAQ/050 and now I understand why the first doesn't work, and I've also learned that eval can be insecure and should be avoided (this is just an internal Jenkins job, would it ever be an issue?).
Also in the article, it mentioned adding the command to an array first, so I tried:
args=("\"testOnly com.example.testClass\"")
sbt "${args[#]}"
but that also does not run correctly. What's the best way to do this? Is it really that bad to use eval in my case?
Quote the variable expansion rather than the assignment.
TEST_CMD="testOnly com.example.testClass"
sbt "$TEST_CMD"
This question already has answers here:
Brace expansion with variable? [duplicate]
(6 answers)
Closed 5 years ago.
How do I expand a brace expansion that originally come from a string variables ? Note that the string variable is a requirement.
#!/usr/bin/env bash
TEXT_DIRS='opt/*/{doc,gtk-doc}'
My intention is reading a bash source from zsh, or maybe other language as well such as Perl or Python. Get the configuration from /etc/makepkg.conf, as below.
DOC_DIRS=(usr/{,local/}{,share/}{doc,gtk-doc} opt/*/{doc,gtk-doc})
It is all, for just, learning purpose.
Is that possible, to expand from string ?
The tricky thing here is that once Bash resolves the environment variable, it doesn't make another pass to process its contents again. You'd have to evaluate the content of the variable in another pass of the shell ( eg another shell command).
Here's one way to do that:
bash-4.4# TEXT_DIRS='/usr/*/{bin,src,lib}'
bash-4.4# bash -c ls\ $TEXT_DIRS
ls: /usr/*/src: No such file or directory
/usr/local/bin:
/usr/local/lib:
Here, I'm dynamically generating a shell command that I then evaluate to handle the 2nd expansion. (I took the liberty of changing the paths to something that would match on typical systems, so make sure to change it back if you try to test).
Dynamically generating code is always dangerous, if you can't trust the input. That's essentially how command injection attacks work. But use of eval in your own shell with trusted input is more or less "safe", though I rarely find myself using it unless in a contrived scenario like yours, or some of my own worse ideas.
This question already has answers here:
Setting an argument with bash [duplicate]
(2 answers)
Closed 5 years ago.
I have to use a bash script (I'm not familiar with bash) for submitting a HPC job. The job-submission script template sets the command and options and then combines them in the end:
input="file_name"
name="simulation1"
application=my_app
options="in=$input.h5 out=$name.h5 param1=foo"
cmd="$application $options"
this all works okay, i.e. eval $cmd executes
my_app in=$input.h5 out=$name.h5 param1=foo
until I need the character '>' in the options. In particular, I want to add the option absrad="mass>1?H:0", but if I simply set
options="in=$input.h5 out=$name.h5 param1=foo absrad=mass>1?H:0"
then bash truncates that at the '>', so that eval $cmd executes
my_app in=$input.h5 out=$name.h5 param1=foo absrad=mass
instead. How to fix that such that eval $cmd executes
my_app in=$input.h5 out=$name.h5 param1=foo absrad="mass>1?H:0"
EDIT. Note that this is similar to, but not a duplicate of this post, where a single-quoted argument is the problem. Moreover, the answers there only consider solutions using an array for the options. I would like alternatives w/o array.
You could always use an array for options:
declare -a options=("in=$input.h5" "out=$name.h5" "param1=foo" "absrad=\"mass>1?H:0\"");
declare -a cmd=(my_app "${options[#]}");
Then when you want to expand cmd the following should give you the correct expansion:
"${cmd[#]}"
Additionally, this gets rid of the need to use eval, which I tend to avoid whenever possible.