Say I have this .env file:  A=1 B=2 C="3 4 5"   If I run set -x; echo $(cat .env | xargs):   ++ cat .env ++ xargs + echo A=1 B=2 C=3 4 5 A=1 B=2 C=3 4 5   If I run set -x; export $(cat .env | xargs):  ++ cat /tmp/test.env ++ xargs + export A=1 B=2 C=3 4 5 + A=1 + B=2 + C=3 bash: export: `4': not a valid identifier bash: export: `5': not a valid identifier   Then I tried a lot of other tricks to try and keep or add quotes around the C value:  $ set -x; export $(cat /tmp/test.env | xargs printf %q) + set -x ++ cat /tmp/test.env ++ xargs printf %q + export ''\''A=1'\'''\''B=2'\'''\''C=3' 4 '5'\''' bash: export: `'A=1''B=2''C=3': not a valid identifier bash: export: `4': not a valid identifier bash: export: `5'': not a valid identifier   No matter what I do, the C value is always split on spaces.  Edit: To clarify, a solution based on naively sourcing the .env file(most solutions from ) is severely unsafe, if the file contains any string that can be interpreted as command executon. I want my environment files to be interpreted only as key-value data.
31299
I have a tmp.txt file containing variables to be exported, for example:  a=123 b="hello world" c="one more variable"   How can I export all these variables using the export command, so that they can later be used by child processes?
86562
Input 0  echo foo | xargs -L 1 -I '{}' echo '{}'   Output 0  foo   Input 1  echo foo | xargs -I '{}' -L 1 echo '{}'   Output 1  {} foo   Why changing the order of options of xargs changes the output?  Version: xargs (GNU findutils) 4.6.0
83246
I am not able to use - in variables in shell. Is there a way to be able to use it, because I have one script which depends on such named variables:  $export a-b=c -bash: export: `a-b=c': not a valid identifier  $export a_b=c   First throws the given error and second works fine.
37477
There're way too many articles/resources on the web that teaches people HOW to set the environment variable PATH so that they can use the short hand of java or python etc instead of the absolute path in command line interface.  What I'm interested to know is that what's behind the scene when we type in the command and hit enter (similar to ).  Here is my guess:   read the command (parse/preprocess stdin to get the right arguments $@) command lookup command execution (program started, consume memory, stdout/stderr to shell) re-render the emulator by relevant environment variables (e.g. $PS#, $PROMPT, etc)   The part I want to figure out most is the command lookup. Obviously, the $PATH is consumed by some background function and separated by : / ;as delimiters, then what happened? Do we use a hash table (key: basename of the file, value: absolute dirname of the file) to store the binary files under those PATHs, or some other hooks?   NOTE: I originally thought it was hash table as I can use [ -z hash [command] ] to check if a command is available in current env, but when I use hash | grep python I get nothing from the output while which python works as anticipated. (I think the mechanism might be shell specific, but I want to get more insights into it.)
34176
If I run  export TEST=foo echo $TEST   It outputs foo.  If I run  TEST=foo echo $TEST   It does not. How can I get this functionality without using export or a script?
8853
Could you explain the following sentences from Bash manual about $_, especially the parts in bold,  maybe with some examples?      At shell startup, set to the absolute pathname used to   invoke the shell or shell script being executed as passed in the environment   or argument list.      Subsequently, expands to the last argument to the previous   command, after expansion.      Also set to the full pathname used to invoke each   command executed and placed in the environment exported to that command.     When checking mail, this parameter holds the name of the mail file.
23266
I just saw this in an init script: echo $&quot;Stopping Apache&quot;  What is that dollar-sign for? My research so far: I found this in the bash manual:  extquote  If set, $'string' and $&quot;string&quot; quoting is performed within ${parameter} expansions enclosed in double quotes.  This option is enabled by default.   ...but I'm not finding any difference between strings with and without the $ prefix: $ echo &quot;I am in $PWD&quot; I am in /var/shared/home/southworth/qed $ echo $&quot;I am in $PWD&quot; I am in /var/shared/home/southworth/qed $ echo $&quot;I am in ${PWD}&quot; I am in /var/shared/home/southworth/qed $ echo &quot;I am in ${PWD}&quot; I am in /var/shared/home/southworth/qed $ echo 'I am in ${PWD}' I am in ${PWD} $ echo $'I am in ${PWD}' I am in ${PWD} $ echo $'I am in $PWD' I am in $PWD
40465
In shell scripts one specifies language interpreter on shebang(#!) line. As far as I know, it is recommended to use #!/usr/bin/env bash because env is always located in /usr/bin directory while location of bash may vary from system to system. However, are there any technical differences if bash is started directly with /bin/bash or through env utility? In addition, am I correct that if I do not specify any variables for env, the bash is started in unmodified environment?
70662
I've run into some strange behaviour today:  #!/bin/bash set -ex export a=$(cat foo) echo "It's a living thing" b=$(cat foo) echo "This won't make it"   This won't stop on cat foo even though foo does not exist. But without the export, it fails. Why?
103460
I have a text file I'm outputting to a variable in my shell script.  I only need the first 50 characters however.  I've tried using cat ${filename} cut -c1-50 but I'm getting far more than the first 50 characters?  That may be due to cut looking for lines (not 100% sure), while this text file could be one long string-- it really depends.    Is there a utility out there I can pipe into to get the first X characters from a cat command?
46516
When I open up a bash prompt and type:  $ set -o xtrace $ x='~/someDirectory' + x='~/someDirectory' $ echo $x + echo '~/someDirectory' ~/someDirectory   I was hoping that the 5th line above would have went + echo /home/myUsername/someDirectory.  Is there a way to do this?  In my original Bash script, the variable x is actually being populated from data from an input file, via a loop like this:  while IFS= read line do     params=($line)     echo ${params[0]} done &lt;"./someInputFile.txt"   Still, I'm getting a similar result, with the echo '~/someDirectory' instead of echo /home/myUsername/someDirectory.
39077
In my Bash environment I use variables containing spaces, and I use these variables within command substitution. What is the correct way to quote my variables? And how should I do it if these are nested? DIRNAME=$(dirname &quot;$FILE&quot;)  or do I quote outside the substitution? DIRNAME=&quot;$(dirname $FILE)&quot;  or both? DIRNAME=&quot;$(dirname &quot;$FILE&quot;)&quot;  or do I use back-ticks? DIRNAME=`dirname &quot;$FILE&quot;`  What is the right way to do this? And how can I easily check if the quotes are set right?
11493
From      Storing the regular expression in a shell variable is often a useful way to avoid problems with quoting characters that are special to the   shell. It is sometimes difficult to specify a regular expression   literally without using quotes, or to keep track of the quoting used   by regular expressions while paying attention to the shell’s quote   removal. Using a shell variable to store the pattern decreases these   problems. For example, the following are equivalent:  pattern='[[:space:]]*(a)?b' [[ $line =~ $pattern ]]       and  [[ $line =~ [[:space:]]*(a)?b ]]       If you want to match a character that’s special to the regular   expression grammar, it has to be quoted to remove its special meaning.   This means that in the pattern xxx.txt, the . matches any   character in the string (its usual regular expression meaning), but in   the pattern "xxx.txt" it can only match a literal .. Shell   programmers should take special care with backslashes, since   back-slashes are used both by the shell and regular expressions to   remove the special meaning from the following character. The following   two sets of commands are not equivalent:  pattern='\.'  [[ . =~ $pattern ]] [[ . =~ \. ]]  [[ . =~ "$pattern" ]] [[ . =~ '\.' ]]       The first two matches will succeed, but the second two will not,   because in the second two the backslash will be part of the pattern to   be matched. In the first two examples, the backslash removes the   special meaning from ., so the literal . matches. If the string in   the first examples were anything other than ., say a, the pattern   would not match, because the quoted . in the pattern loses its   special meaning of matching any single character.   How is storing the regular expression in a shell variable  a useful way to avoid problems with quoting characters that are special to the shell?  The given examples don't seem to explain that. In the given examples, the regex literals in one method and the values of the shell variable pattern in the other method are the same.   Thanks.
75140
I have the following shell script that sums up all the arguments passed to it (space separated):  sum=0 for arg in "$@"; do     (( sum += arg )) done echo $sum   I have saved it as SumAll.sh. So, its supposed to function as follows:  sh SumAll.sh 2 4 6 8 20   or  bash SumAll.sh 1 -2 3 -3 -1   Both work on my local machine (MacBook), but when I try the same in a linux server, running the script with bash works, but with sh does not work. I get the following error:  sum: '+=': No such file or directory sum: arg: No such file or directory   Why is that? And how do I fix it?
26823
I've hacked on a lot of shell scripts, and sometimes the simplest things baffle me. Today I ran across a script that made extensive use of the : (colon) bash builtin.  The  seems simple enough:   : (a colon)        : [arguments]         Do nothing beyond expanding arguments and performing redirections. The return status is zero.    However I have previously only seen this used in demonstrations of shell expansion. The use case in the script I ran across made extensive use of this structure:  if [ -f ${file} ]; then     grep some_string ${file} &gt;&gt; otherfile || :     grep other_string ${file} &gt;&gt; otherfile || : fi   There were actually hundreds of greps, but they are just more of the same. No input/output redirects are present other than  the simple structure above. No return values are checked later in the script.  I am reading this as a useless construct that says "or do nothing". What purpose could ending these greps with "or do nothing" serve? In what case would this construct cause a different outcome than simply leaving off the || : from all instances?
27326
I saw a lot of posts about it all over the internet but i couldn't make it run as i wanted.  I have an input from the user of a path. If the user will type ~/Desktop/ for example i can't use $ans in grep and other commands because of the tilde.   here is an example of my code. the second line is my main problem right now.  read -p "Enter new path or type 'exit':   " ans file=`grep -x $ans ~/.Log`    Appreciate your help.
79894
Can you explain what this command does:  files=(this_is_filename) for filename in ${files[@]}; do    ls -t1 ../htory/$filename* |     head -1 |     xargs -I fname cp -p fname ../htory2/somefile.CSV done   Especially this part of this command  xargs -I fname cp -p fname ../htory2/somefile.CSV