Below I have an example which confuses me a bit, any help would be appreciated.
I bind a normal command line command (ls) to a new variable. If I echo it it the output is just the command (ls) but if I just use the variable without echo i get the result of the command but why?? Is it because $listdir gets translated to ls so I just get the output? And if I use the echo command it will be interpreted as a string?
router#test:~/scripting$ listdir=ls
router#test:~/scripting$ echo "$listdir"
ls
----- VS ----
router#test:~/scripting$ $listdir
basicLoop.sh fileflood.sh .......
Thank you for any help!
By doing listdir=ls you literally assign a string "ls" to the $listdir variable. So if you run echo $listdir now it will just expand into echo ls, which (as you may have guessed) will just print "ls" onto a screen. If you want to store a result of a command into a variable you can wrap the command in `` or $() (eg. listdir=$(ls) or listdir=`ls`).
jarmusz#emacs~$ listdir=`ls`
jarmusz#emacs~$ echo "$listdir"
dls
docs
music
...
If you want to store just a name of the command and run it later you can do it like this:
jarmusz#emacs~$ listdir=ls
<some other commands...>
jarmusz#emacs~$ echo `$listdir`
dls docs music ...
In this example, echo `$listdir` will expand into echo `ls` and then into echo dls docs music...
When bash is interpreting the commands you feed to it, the first thing it will do is expand any expansions it is given. So when you give it $listdir by the time bash starts to execute the value it is given, all it knows is that it was given the value ls. It does not care where the value came from, only what the value is.
Lets look at the trace given after running set -x, which instructs bash to prints to stderr after expansion and before execution:
$> echo $listdir
+ echo ls
ls
$> $listdir
+ ls
file_0 file_1
As you can see, in the second line, bash will attempt to run the command ls just as if you have explicity called ls or even /usr/bin/ls
Edit
Expansion isn't the first step in in shell evaluation, see #Gordon Davisson's comment for details
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.
This following command prints nothing on my machine
echo `python3.8 -c 'print ("*"*10)'`
whereas
python3.8 -c 'print ("*"*10)'
does. Why?
The first example does command substitution for the argument to echo and is equivalent to the command echo **********. This happens to output a list of directory contents, since ********** seems to be equivalent to *1 and is expanded by the shell.
If you want to prevent the shell to expand **********, you need to quote it:
echo "`python3.8 -c 'print ("*"*10)'`"
which is equivalent to echo "**********".
1don't quote me on that (pun intended)
`expr` means to evaluate the contents between ' as a command and replace it with the result.
`print(*)` is equal to ` * ` which is evaluated as all the files in the current directory
The output really depends on the machine used
Here's my problem, from console if I type the below,
var=`history 1`
echo $var
I get the desired output. But when I do the same inside a shell script, it is not showing any output. Also, for other commands like pwd, ls etc, the script shows the desired output without any issue.
As value of variable contains space, add quotes around it.
E.g.:
var='history 1'
echo $var
I believe all you need is this as follows:
1- Ask user for the number till which user need to print the history in script.
2- Run the script and take Input from user and get the output as follows:
cat get_history.ksh
echo "Enter the line number of history which you want to get.."
read number
if [[ $# -eq 0 ]]
then
echo "Usage of script: get_history.ksh number_of_lines"
exit
else
history "$number"
fi
Added logic where it will check arguments if number of arguments passed is 0 then it will exit from script then.
By default history is turned off in a script, therefore you need to turn it on:
set -o history
var=$(history 1)
echo "$var"
Note the preferred use of $( ) rather than the deprecated backticks.
However, this will only look at the history of the current process, that is this shell script, so it is fairly useless.
I came across an interesting thing in Shell Scripting and not 100% sure why the behaviour is like this
I tried the below script:
#!/bin/sh
CMD="curl -XGET http://../endpoint";
var1=eval $CMD | sed -e 's/find/replace/g';
echo $var1; # Output: printed the value on this line
echo $var1; # Output: blank/no data printed (Why it is blank?)
I had to change the command in variable enclosing with back-tick ` to print the variable as many time as I wanted.
CMD="curl -XGET http://../endpoint";
var1=`eval $CMD | sed -e 's/find/replace/g'`;
echo $var1; # Output: printed the value on this line
echo $var1; # Output: printed the value on this line
Why I have to surround my command with ` to assign it's o/p to the variable in subsequent variable usage?
I have a feeling that it has something to do with the variable-command scope.
Shedding light on my understanding will be appreciated!
UPDATE:
I tried the below command and it is working in my env.
#!/bin/sh
CMD="curl -XGET http://www.google.com/";
var1=eval $CMD | sed -e 's/find/replace/g';
echo $var1; # Output: printed the value on this line
echo "######";
echo $var1; # Output: blank/no data printed (Why it is blank?)
sh/bash allows you to run a command with a variable in its environment, without permanently modifying the variable in the shell. This is great, because you can e.g. run a command in a certain language just one time without having to change your entire user's or system's language:
$ LC_ALL=en_US.utf8 ls foo
ls: cannot access foo: No such file or directory
$ LC_ALL=nb_NO.utf8 ls foo
ls: cannot access foo: Ingen slik fil eller filkatalog
However, this means that when you try to do
var=this is some command
you're trigger this syntax.
It means "run the command is a command and tell it that the variable var is set to this"
It does not assign "this is my string" to the variable, and it definitely does not evaluate "this is a string" as a command, and then assign its output to var.
Given this, we can look at what actually happened:
CMD="curl -XGET http://../endpoint";
var1=eval $CMD | sed -e 's/find/replace/g'; # No assignment, output to screen
echo $var1; # Output: blank/no data printed
echo $var1; # Output: blank/no data printed
There is no scope issue and no inconsistency: the variable is never assigned, and is never written by an echo statement.
var=`some command` (or preferably, var=$(some command)) works because this is valid syntax to assign output from a program to a variable.
The first example isn't doing what you think it is.
Neither echo is printing anything. Make them echo "[$var1]" to see that.
You need the backticks to run the command and capture its output.
Your first attempt was running the $CMD | sed -e 's/find/replace/g'; pipeline with the environment of $CMD containing var1 set to a value of eval.
You also shouldn't be putting commands inside strings (or using eval in general). See http://mywiki.wooledge.org/BashFAQ/001 for more on why.
Can someone help explain the following:
If I type:
a=`ls -l`
Then the output of the ls command is saved in the variable a
but if I try:
a=`sh ./somefile`
The result is outputed to the shell (stdout) rather than the variable a
What I expected was the result operation of the shell trying to execute a scrip 'somefile' to be stored in the variable.
Please point out what is wrong with my understanding and a possible way to do this.
Thanks.
EDIT:
Just to clarify, the script 'somefile' may or may not exist. If it exsists then I want the output of the script to be stored in 'a'. If not, I want the error message "no such file or dir" stored in 'a'
I think because the shell probably attaches itself to /dev/tty but I may be wrong. Why wouldn't you just set execute permissions on the script and use:
a=`./somefile`
If you want to capture stderr and stdout to a, just use:
a=`./somefile 2>&1`
To check file is executable first:
if [[ -x ./somefile ]] ; then
a=$(./somefile 2>&1)
else
a="Couldn't find the darned thing."
fi
and you'll notice I'm switching to the $() method instead of backticks. I prefer $() since you can nest them (e.g., "a=$(expr 1 + $(expr 2 + 3))").
You can try the new and improved way of doing command substitution, use $() instead of backticks.
a=$(sh ./somefile)
If it still doesn't work, check if somefile is not actually stderr'ing.
You are correct, the stdout of ./somefile is stored in the variable a. However, I assume somefile outputs to stderr. You can redirect that with 2>&1 directly after ./somefile.