I have one variable, which is coming from some where like:
VAR1='hhgfhfghhgf"";2Ddgfsaj!!!$#^$\'&%*%~*)_)(_{}||\\/'
Now i have command like this
./myscript.sh '$VAR1'
I am getting that $VAR1 from some diff process and when I display it look exactly as its above.
Now that command is failing as there is already single quote inside variable. In the process where I use it it is expanded at that point, which causes that error.
I have control over myscript.sh but not above command.
Is there any way I can get variable inside my script?
What you are saying is not possible to failing when passing to your script. Might your script has processing issue (or a command where this argument will passing into it) which cannot expand the variable correctly. You can either use printf with %q modifier to escape all special characters then pass it to your script:
./myscript.sh "$(printf '%q\n' "$VAR1")"
... or do the same within your script before you wanted to pass to some other commands:
VAR2="$(printf '%q\n' "$VAR1")"
Related
I'm using WSL (Ubuntu 18.04) on Windows 10 and bash.
I have a file filename.gpg with the content:
export SOME_ENV_VAR='123'
Now I run the following commands:
$ $(gpg -d filename.gpg)
$ echo $SOME_ENV_VAR
'123' <-- with quotes
However, if I run it directly in the shell:
$ export SOME_ENV_VAR='123'
$ echo $SOME_ENV_VAR
123 < -- without quotes
Why does it behave like this? Why is there a difference between running a command using $() and running it directly?
Aside: I got it working using eval $(gpg -d filename), I have no idea why this works.
Quotes in shell scripts do not behave differently from quotes in shell commands.
With the $(gpg -d filename.gpg) syntax, you are not executing a shell script, but a regular single command.
What your command does
It executes gpg -d filename.gpg
From the result, it takes the first (IFS-separated) word as the command to execute
It takes every other (IFS-separated) words, including words from additional lines, as its parameters
It executs the command
From the following practical examples, you can see how it differs from executing a shell script:
Remove the word export from filename.gpg: the command is then SOME_ENV_VAR='123' which is not understood as a variable assignment (you will get SOME_ENV_VAR='123': command not found).
If you add several lines, they won't be understood as separated command lines, but as parameters to the very first command (export).
If you change export SOME_ENV_VAR='123' to export SOME_ENV_VAR=$PWD, SOME_ENV_VAR will not contain the content of variable PWD, but the string $var
Why is it so?
See how bash performs expansion when analyzing a command.
There are many steps. $(...) is called "command substitution" and is the fourth step. When it is done, none of the previous steps will be performed again. This explains why your command does not work when you remove the export word, and why variables are not substituted in the result.
Moreover "quote Removal" is the last step and the manual reads:
all unquoted occurrences of the characters ‘\’, ‘'’, and ‘"’ that did
not result from one of the above expansions are removed
Since the single quotes resulted from the "command substitution" expansion, they were not removed. That's why the content of SOME_ENV_VAR is '123' and not 123.
Why does eval work?
Because eval triggers another complete parsing of its parameters. The whole set of expansions is run again.
From the manual:
The arguments are concatenated together into a single command, which is then read and executed
Note that this means that you are still running one single command, and not a shell script. If your filename.gpg script has several lines, subsequent lines will be added to the argument list of the first (and only) command.
What should I do then?
Just use source along with process substitution.
source <(gpg -d filename.gpg)
Contrary to eval, source is used to execute a shell script in the current context. Process substitution provides a pseudo-filename that contains the result of the substitution (i.e. the output of gpg).
I know I have to take the path first and then run the code like export :$PATH but how do i feed the name of the program to the script?
I have tried to use the command line arguments and try to execute it but it's a dead end.
You can access the first command line argument in the variable "$1", the second with "$2", etc.
To iterate over all the arguments, use
for arg in "$#"; do
do_something_with "$arg"
done
I'm struggling with passing a shell command. Specifically, I have written a shell file that the user will run. In it, another shell file is written based on the user inputs. This file will then be passed to a command that submits the job.
Now in this internal shell file I have a variable containing a function. However, when I run the user shell script I can't get this function to pass in a way that the internal shell file can use it.
I can't share my work but I'll try to make an example
#User shell script
cat >test.txt <<EOF
#a bunch of lines that are not relevant
var=`grep examples input.txt`
/bin/localfoo -${var}
EOF
# pass test.txt to localfoo2
/bin/localfoo2 /test.txt
When I run the 'User Shell Script' it prints that grep can't find the file, but I don't want grep to be evaluated. I need it to be written, as is, so that when the line '/bin/localfoo2 /test.txt' is read, grep is evaluated.
I've tried a number of things. I've tried double back ticks, i've tried using 'echo $(eval $var)'. But none of the methods I've found through googling have managed to pass this var in a way that will accomplish what I want.
Your help is much appreciated.
You can try with single quote (').
You have to put the single quote in before the grep command and end of the grep command like below.
#User shell script
cat >test.txt <<EOF
#a bunch of lines that are not relevant
var='`grep examples input.txt`'
/bin/localfoo -${var}
EOF
# pass test.txt to localfoo2
/bin/localfoo2 /test.txt
I did not understand where you have to execute that grep command.
If you want to execute the grep command inside the localfoo script, I hope this method will help.
I'm looking for a way to access the full command from shell script, e.g.
Assume I have a script called test.sh. When I run it, the command line is passed to ruby as is (except the script itself is removed).
$ test.sh print ENV['HOME']
Is equivalent to
$ ruby -e "print ENV['HOME']"
When you run:
test.sh print ENV['HOME']
...then, before test.sh is started, the shell runs string-splitting, expansion, and similar processes. Thus, what's eventually run is (assuming no glob expansion):
execvp("test.sh", {"test.sh", "print", "ENV[HOME]"});
If you have a file named ENVH in the current directory, the shell may treat ENV['HOME'] as a glob, expanding it by replacing the glob expression with the filename, and thus running:
execvp("test.sh", {"test.sh", "print", "ENVH"});
...in any event, what exists on the other side of the execv*-series call done to run the new program has no information which was local to the original shell -- and thus no way of knowing what the original command was before parsing and expansion. Thus, it is impossible to retrieve the original string unless the outer shell is modified to expose it out-of-band (as via an environment variable).
This is why your calling convention should instead require:
test.sh "print ENV['HOME']"
or, allowing even more freedom from shell quoting/escaping syntax, passing program text via stdin, as with:
test.sh <<'EOF'
print ENV['HOME']
EOF
Now, if you want to modify your shell to do that, I'd suggest a function that exposes BASH_COMMAND. For instance:
shopt -s extdebug
expose_command() {
export SHELL_COMMAND="$BASH_COMMAND"
return 0
}
trap expose_command DEBUG
...then, inside test.sh, you can refer to SHELL_COMMAND. Again, however: This will only work if the calling shell had that trap configured, as within a user's ~/.bashrc; you can't simply put the above content in a script and expect it to work, because it's only the interactive shell -- the script's parent process -- that has access to this information and is thus able to expose it.
I am not much familiar with shell script. I want to modify a script but it's giving me error "No such file or directory" after I change it.
But that command works over the command prompt.
Here is the line which causes problem. (Even not sure how below command spawns a process.)
_T_COMMAND_=1 "valgrind ---tool=memcheck --trace-children=yes command"
same thing works if I run command as
$valgrind ---tool=memcheck --trace-children=yes command
Any idea?
Don't put the command in double quotes.
_T_COMMAND_=1 valgrind ---tool=memcheck --trace-children=yes command
The general syntax is simply
[var=value ...] cmd [args]
which will set the environment variable var to value for the duration of cmd. You can set several variables in this way.
Alternatively, set the variable and export it; then it will remain set for the remainder of the current shell's lifetime, and be exposed to subprocesses (that's what the export does).
_T_COMMAND_=1
export _T_COMMAND_
valgrind ---tool=memcheck --trace-children=yes command
Similarly, valgrind processes its options, then runs the specified command (with any options) as a subprocess.
A single command in double quotes is harmless, because the shell will strip the quotes before the kernel sees the argument. A string with spaces in double quotes will be preserved as a single argument, while without quotes, it becomes multiple arguments. Behold:
bash$ perl -le 'print "<<$_>>" for #ARGV' "foo bar" baz quux
<<foo bar>>
<<baz>>
<<quux>>
or just as well, add harmless but no doubt rather confusing double quotes around everything which isn't already quoted:
bash$ "perl" "-le" 'print "<<$_>>" for #ARGV' "yowza"
<<yowza>>
The shell parses this into
<<perl>>
<<-le>>
<<print "<<$_>>" for #ARGV>>
<<yowza>>
and removes the (outer) quotes in the process.