It is often said that variables should be double quoted when used.  In the following example I want to have the command echo "You can't see me" in a variable and run it in such a way that the output is You can't see me. This is the end goal.  $ cmd="echo \"You can't see me\"" $ echo "$cmd" echo "You can't see me" $ $cmd "You can't see me" $ "$cmd" echo "You can't see me": command not found   So $cmd ran and it included double quotes which I did not want to have, and following the recommendation of double quoting the variables led to an error.  Does the recommendation have exceptions despite the fact that resources say that they always should be used?  I know how I can get the result that I want by running eval "$cmd" (or without the double quotes), or by an appropriate transformation on the output after running $cmd (without double quotes), but how do I avoid this issue?
7095
$ ls -l /tmp/test/my\ dir/ total 0   I was wondering why the following ways to run the above command fail or succeed?  $ abc='ls -l "/tmp/test/my dir"'  $ $abc ls: cannot access '"/tmp/test/my': No such file or directory ls: cannot access 'dir"': No such file or directory  $ "$abc" bash: ls -l "/tmp/test/my dir": No such file or directory  $ bash -c $abc 'my dir'  $ bash -c "$abc" total 0  $ eval $abc total 0  $ eval "$abc" total 0
393
For bash script, I can use "$@" to access arguments. What's the equivalent when I use an alias?
7071
I changed the /etc/environment to add more directories to the PATH variable. But looks like $PATH in double quotes were not expanded and I could find any command from the shell and /usr/bin/command-not-found is run.  $ cat /etc/environment  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games" PATH="$PATH:/home/user/technical/java/maven/bin" JAVA_HOME="/home/user/technical/java/jdk7"   so from the tty,  $ echo $PATH $PATH:/home/user/technical/java/maven/bin   why did not the expansion happen?
14165
I'm working with a bash script trying to stop it from attempting to replace variables inside my heredoc. How do set a heredoc to either A) escape the variable names instead of parsing them or B) return the entire string untouched?  cat &gt; /etc/nginx/sites-available/default_php &lt;&lt;END server {     listen 80 default;     server_name _;     root /var/www/$host; &lt;--- $host is a problem child } END   As is, when I it finishes injecting it into a file I'm left with this:  server {     listen 80 default;     server_name _;     root /var/www/; }
12613
I often see tutorials on the web or posts on this site which make heavy use of the following characters at the command line. Often it seems that they are used for pretty similar purposes. What are the differences between them when used on the command line or for shell programming? For what purpose do I use which of them?  " " double quotes  ' ' single quotes  ` ` backticks
17216
This will be an easy one, but in my memories, when shell scripting, using double quotes would allow expanding globbing and variables.  But in the following code:  #!/bin/sh  echo *.sh echo "*.sh" echo '*.sh'  echo $LANG echo "$LANG" echo '$LANG'   I get this result:  bob.sh redeployJboss.sh *.sh *.sh en_US.utf8 en_US.utf8 $LANG   So single quoting prevent glob AND variable expansion but double quoting allows only variable expansion and no globbing?  Can I glob in any quoting pattern?
28702
If you've been following unix.stackexchange.com for a while, you should hopefully know by now that leaving a variable unquoted in list context (as in echo $var) in Bourne/POSIX shells (zsh being the exception) has a very special meaning and shouldn't be done unless you have a very good reason to.  It's discussed at length in a number of Q&amp;A here (Examples: , , , )  That has been the case since the initial release of the Bourne shell in the late 70s and hasn't been changed by the Korn shell (one of ) or bash which mostly copied the Korn shell, and that's how that has been specified by POSIX/Unix.  Now, we're still seeing a number of answers here and even occasionally publicly released shell code where variables are not quoted. You'd have thought people would have learnt by now.  In my experience, there are mainly 3 types of people who omit to quote their variables:   beginners. Those can be excused as admittedly it's a completely unintuitive syntax. And it's our role on this site to educate them. forgetful people. people who are not convinced even after repeated hammering, who think that surely the Bourne shell author did not intend us to quote all our variables.   Maybe we can convince them if we expose the risk associated with this kind of behaviours.  What's the worst thing than can possibly happen if you forget to quote your variables. Is it really that bad?  What kind of vulnerability are we talking of here?  In what contexts can it be a problem?
104419
I have a script myscript.sh  #!/bin/sh  echo $1 $2   which is used something like ...  ./myscript.sh foo bar   which gives me an output of ...  foo bar     but how can i make this script include custom command options? for example ...  ./myscript.sh -a foo and corespond to $1   and  ./myscript.sh -b bar and corespond to $2
9335
The old advice used to be to double-quote any expression involving a $VARIABLE, at least if one wanted it to be interpreted by the shell as one single item, otherwise, any spaces in the content of $VARIABLE would throw off the shell.  I understand, however, that in more recent versions of shells, double-quoting is no longer always needed (at least for the purpose described above).  For instance, in bash:  % FOO='bar baz' % [ $FOO = 'bar baz' ] &amp;&amp; echo OK bash: [: too many arguments % [[ $FOO = 'bar baz' ]] &amp;&amp; echo OK OK % touch 'bar baz' % ls $FOO ls: cannot access bar: No such file or directory ls: cannot access baz: No such file or directory   In zsh, on the other hand, the same three commands succeed.  Therefore, based on this experiment, it seems that, in bash, one can omit the double quotes inside [[ ... ]], but not inside [ ... ] nor in command-line arguments, whereas, in zsh, the double quotes may be omitted in all these cases.  But inferring general rules from anecdotal examples like the above is a chancy proposition.  It would be nice to see a summary of when double-quoting is necessary.  I'm primarily interested in zsh, bash, and /bin/sh.
115993
Stéphane Chazelas gave two examples in   $ a=1+1; echo "$((a * 3)) $(($a * 3))" 6 4  $ a=a=b++ b=1 bash -c 'echo "$((++a)) $b"' 2 2   I understand there is indirect expansion for variable expansion in arithmetic expressions. But I can't figure out    how do a and $a in the first example  result in such a difference?  My confusion comes from that in arithmetic expressions, parameter expansion of a variable doesn't need ${}, just write the variable directly. how is the arithmetic expression in the second example evaluated?   Thanks.
47782
I am trying out the command  $ b=5; echo `$b`; -bash: 5: command not found   but it does not print 5 as it is supposed to. What am I missing here?   seems to say that ` evaluates the commands within and replaces them with the output.
30221
Suppose I want a bash command to do something extra.  As a simple example, imagine I just want it to echo "123" before running.  One simply way to do this would be to alias the command.  Since we still need the original, we can just refer to it by its exact path, which we can find using which.  For example:  $ which rm /bin/rm $ echo "alias rm='echo 123 &amp;&amp; /bin/rm'" &gt;&gt; .bashrc   This was easy because I was able to look up the path to rm using which.  However, I am trying to do this with exit, and which doesn't seem to know anything about it.  $ which exit $ echo $? 1   The command did not output a path, and in fact it returned a non-zero exit code, which which does when a command is not in $PATH.  I thought maybe it's a function, but apparently that's not the case either:  $ typeset -F | grep exit $ echo $? 1   So the exit command is not defined anywhere as a function or as a command in $PATH, and yet, when I type exit, it closes the terminal.  So it clearly is defined somewhere but I can't figure out where.  Where is it defined, and how can I call to it explicitly?
52319
I want to set an environment variable from the command prompt and then be able to access it globally (for instance, I should see it by going to System -> Environment Variables).    When I use the set command, it isn't accessible in a new cmd session.  set NEWVAR=SOMETHING echo %NEWVAR%   Related questions:
58385
Can I use variables inside {} expansion without appealing to eval? If so, how?  This doesn't work:  $ touch 1.foo 1.bar $ ls 1.{foo,bar} 1.bar  1.foo $ extensions=foo,bar $ ls 1.{$extensions} ls: cannot access 1.{foo,bar}: No such file or directory   It works with eval:  $ eval ls 1.{$extensions} 1.bar  1.foo
118424
I'm used to bash's builtin read function in while loops, e.g.:  echo "0 1       1 1       1 2       2 3" |\ while read A B; do     echo $A + $B | bc; done   I've been working on some make project, and it became prudent to split files and store intermediary results. As a consequence I often end up shredding single lines into variables. While the following example works pretty well,  head -n1 somefile | while read A B C D E FOO; do [... use vars here ...]; done   it's sort of stupid, because the while loop will never run more than once. But without the while,  head -n1 somefile | read A B C D E FOO; [... use vars here ...]   The read variables are always empty when I use them. I never noticed this behaviour of read, because usually I'd use while loops to process many similar lines. How can I use bash's read builtin without a while loop? Or is there another (or even better) way to read a single line into multiple (!) variables?  Conclusion  The answers teach us, it's a problem of scoping. The statement   cmd0; cmd1; cmd2 | cmd3; cmd4   is interpreted such that the commands cmd0, cmd1, and cmd4 are executed in the same scope, while the commands cmd2 and cmd3 are each given their own subshell, and consequently different scopes. The original shell is the parent of both subshells.
3810
I'm looking to get the result of a command as a variable in a Windows batch script (see  for the bash scripting equivalent).  A solution that will work in a .bat file is preferred, but other common windows scripting solutions are also welcome.
33860
I read that it is a best practice to double quote all of your variable expansions in Bash. I also read that one cannot use a shell glob (wildcard(*)) right after a double quoted variable expansion. These situations conflict when one wants use the value of a regex pattern, expanded out of a variable.   The reason I would sometimes want to combine regex with a wildcard is to keep my regex minimal, neater, in my personal taste.  My particular problem  I downloaded phpmyadmin into my document root directory and unzipped it, but I fail to rename it with mv by a regex pattern I put in a variable, and available when expanding its variable. Here's the exact trace:  userName@compName:/var/www/html# ll total 11336 drwxr-xr-x  3 root root     4096 Feb 14 07:04 ./ drwxr-xr-x  3 root root     4096 Feb 14 06:56 ../ -rw-r--r--  1 root root      612 Feb 14 06:57 index.nginx-debian.html drwxr-xr-x 12 root root     4096 Dec 23 08:50 phpMyAdmin-4.7.7-all-languages/ -rw-r--r--  1 root root 11589684 Dec 23 14:08 phpMyAdmin-latest-all-languages.zip userName@compName:/var/www/html# echo $pma [pP][hH][pP][mM][yY][aA][dD][mM][iI][nN] userName@compName:/var/www/html# mv "$pma"*/ phpmyadmin/ mv: cannot stat '[pP][hH][pP][mM][yY][aA][dD][mM][iI][nN]*/': No such file or directory   If I'll unquote the variable expansion to ${pma} I would indeed be able to combine the variable expansion and the regex, as in ${pma}*, but it is important to me to follow the best practice without exceptions, if I can.  My question  How could I keep the variable expansion double quoted, but still using the extracted value with a wildcard?