Shell Variables and Scripting in Bash

undefined
 
CSE 374
Programming Concepts & Tools
 
Hal Perkins
Winter 2017
Lecture 4 – Shell Variables, More Shell Scripts
 
UW CSE 374 Winter 2017
 
1
 
Where we are
 
We understand most of the bash shell and its
“programming language”. Final pieces we’ll consider:
Shell variables
Defining your own
Built-in meanings
Exporting
Arithmetic
For loops
End with:
A long list of gotchas (some bash-specific; some
common to shells)
Why long shell scripts are a bad idea, etc.
 
2
 
UW CSE 374 Winter 2017
 
Shell variables
 
We already know a shell has state: current working directory,
streams, users, aliases, history.
I
t
s
 
s
t
a
t
e
 
a
l
s
o
 
i
n
c
l
u
d
e
s
 
s
h
e
l
l
 
v
a
r
i
a
b
l
e
s
 
t
h
a
t
 
h
o
l
d
 
s
t
r
i
n
g
s
.
Always strings even if they are “123” – but you can do math
Features:
Change variables’ values: foo=blah
Add new variables: foo=blah or foo=
Use variable: ${foo}    (braces sometimes optional)
Remove variables: unset foo
See what variables “are set”: set
Omitted feature: Functions and local variables   (see manual)
Roughly “all variables are global (visible everywhere)”
Only assignment is similar to mainstream “real” programming
languages
 
3
 
UW CSE 374 Winter 2017
 
Why variables?
 
Variables are useful in scripts, just like in “normal”
programming.
“Special” variables affect shell operation. 3 most (?)
common:
PATH
PS1
HOME
Some variables make sense only when the shell is
reading from a script:
$#, $n (where n is an integer), $@, $*, $?
 
4
 
UW CSE 374 Winter 2017
 
Export
 
If a shell runs another program (perhaps a bash script), does the
other program “see the current variables that are set”?
i.e., are the shell variables part of the initial environment of
the new program?
It depends.
export foo – yes it will see value of foo
export -n foo – no it will not see value of foo
Default is no
If the other program sets an exported variable, does the outer
shell see the change?
No.
Somewhat like “call by value” parameters in conventional
languages
Remember, each new program (and shell) is launched as a
separate process with its own state, environment, etc.
 
5
 
UW CSE 374 Winter 2017
 
Arithmetic
 
Variables are strings, so k=$i+$j is not addition
But ((k=$i+$j)) is (and in fact the $ is optional here)
So is  let k="$i + $j”
The shell converts the strings to numbers, silently
using 0 as necessary
 
6
 
UW CSE 374 Winter 2017
 
For loops
 
Syntax:
for v in w
1
 w
2
 ... w
n
do
 
body
done
Execute body n times, with v set to w
i
 on i
th
iteration(Afterwards, v=w
n
)
Why so convenient?
Use a filename pattern after in
Use list of argument strings after in: "$@
Not “$*” – that doesn’t handle arguments with
embedded blanks the way you (usually) want
 
7
 
UW CSE 374 Winter 2017
 
Quoting
 
Does x=* set x to string-holding-asterisk or string-holding-
all-filenames?
If $x is *, does ls $x list all-files or file named asterisk?
Are variables expanded in double-quotes? single-quotes?
Could consult the manual, but honestly it’s easier to start a
shell and experiment. For example:
x="*"
echo x
echo $x
echo "$x"    
(Double quotes suppress some substitutions)
echo ’$x’     
(Single quotes suppress all substitutions)
...
 
8
 
UW CSE 374 Winter 2017
 
Gotchas: A very partial list
 
1.
Typo in variable name on left: create new variable
oops=7
2.
Typo in variable use: get empty string –  ls $oops
3.
Use same variable name again: clobber other use
HISTFILE=uhoh
4.
Spaces in variables: use double-quotes if you mean
“one word”
5.
Non-number used as number: end up with 0
6.
set f=blah: apparently does nothing (assignment in
csh)
7.
Many, many more…
 
UW CSE 374 Winter 2017
 
9
 
Shell programming revisited
 
How do Java programming and shell programming
compare?
The shell:
“shorter”
convenient file-access, file-tests, program-execution,
pipes
crazy quoting rules and syntax
also interactive
Java:
none of the previous gotchas
local variables, modularity, typechecking, array-
checking, . . .
real data structures, libraries, regular syntax
Rough rule of thumb: Don’t write shell scripts over 200
lines?
 
10
 
UW CSE 374 Winter 2017
 
Treatment of strings
 
Suppose foo is a variable that holds the string hello
 
 
 
 
 
 
Moral: In Java, variable-uses are easier than string-
constants
Opposite in Bash
Both biased toward common use
 
11
 
UW CSE 374 Winter 2017
 
More on shell programming
 
Metapoint: Computer scientists automate and end up
accidentally inventing (bad) programming languages. It’s
like using a screwdriver as a pry bar.
HW3 in part, will be near the limits of what seems
reasonable to do with a shell script (and we’ll end up
cutting corners as a result)
There are plenty of attempts to get “the best of both
worlds” in a scripting language: Perl, Python, Ruby, . . .
Personal opinion: it raises the limit to 1000 or 10000 lines?
Gets you hooked on short programs.
Picking the bash shell was a conscious decision to
emphasize the interactive side and see “how bad
programming can get”.
Next: Regular expressions, grep, sed, others.
 
UW CSE 374 Winter 2017
 
12
 
Bottom line
 
Never do something manually if writing a script would
save you time
Never write a script if you need a large, robust piece
of software
Some programming languages try to give the “best of
both worlds” – you now have seen two extremes that
don’t (Java and bash)
 
13
 
UW CSE 374 Winter 2017
Slide Note
Embed
Share

Explore the realm of shell variables and scripting in the context of bash programming. Learn about variable manipulation, exporting, arithmetic operations, for loops, and common pitfalls in long shell scripts. Gain insights into the significance of variables in scripting and their impact on shell operations within the environment.

  • Shell Variables
  • Bash Scripting
  • Variable Manipulation
  • Script Execution
  • Bash Programming

Uploaded on Aug 22, 2024 | 4 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. CSE 374 Programming Concepts & Tools Hal Perkins Winter 2017 Lecture 4 Shell Variables, More Shell Scripts UW CSE 374 Winter 2017 1

  2. Where we are We understand most of the bash shell and its programming language . Final pieces we ll consider: Shell variables Defining your own Built-in meanings Exporting Arithmetic For loops End with: A long list of gotchas (some bash-specific; some common to shells) Why long shell scripts are a bad idea, etc. UW CSE 374 Winter 2017 2

  3. Shell variables We already know a shell has state: current working directory, streams, users, aliases, history. Its state also includes shell variables that hold strings. Always strings even if they are 123 but you can do math Features: Change variables values: foo=blah Add new variables: foo=blah or foo= Use variable: ${foo} (braces sometimes optional) Remove variables: unset foo See what variables are set : set Omitted feature: Functions and local variables (see manual) Roughly all variables are global (visible everywhere) Only assignment is similar to mainstream real programming languages UW CSE 374 Winter 2017 3

  4. Why variables? Variables are useful in scripts, just like in normal programming. Special variables affect shell operation. 3 most (?) common: PATH PS1 HOME Some variables make sense only when the shell is reading from a script: $#, $n (where n is an integer), $@, $*, $? UW CSE 374 Winter 2017 4

  5. Export If a shell runs another program (perhaps a bash script), does the other program see the current variables that are set ? i.e., are the shell variables part of the initial environment of the new program? It depends. export foo yes it will see value of foo export -n foo no it will not see value of foo Default is no If the other program sets an exported variable, does the outer shell see the change? No. Somewhat like call by value parameters in conventional languages Remember, each new program (and shell) is launched as a separate process with its own state, environment, etc. UW CSE 374 Winter 2017 5

  6. Arithmetic Variables are strings, so k=$i+$j is not addition But ((k=$i+$j)) is (and in fact the $ is optional here) So is let k="$i + $j The shell converts the strings to numbers, silently using 0 as necessary UW CSE 374 Winter 2017 6

  7. For loops Syntax: for v in w1w2... wn do body done Execute body n times, with v set to wi on ith iteration(Afterwards, v=wn) Why so convenient? Use a filename pattern after in Use list of argument strings after in: "$@ Not $* that doesn t handle arguments with embedded blanks the way you (usually) want UW CSE 374 Winter 2017 7

  8. Quoting Does x=* set x to string-holding-asterisk or string-holding- all-filenames? If $x is *, does ls $x list all-files or file named asterisk? Are variables expanded in double-quotes? single-quotes? Could consult the manual, but honestly it s easier to start a shell and experiment. For example: x="*" echo x echo $x echo "$x" (Double quotes suppress some substitutions) echo $x (Single quotes suppress all substitutions) ... UW CSE 374 Winter 2017 8

  9. Gotchas: A very partial list 1. Typo in variable name on left: create new variable oops=7 2. Typo in variable use: get empty string ls $oops 3. Use same variable name again: clobber other use HISTFILE=uhoh 4. Spaces in variables: use double-quotes if you mean one word 5. Non-number used as number: end up with 0 6. set f=blah: apparently does nothing (assignment in csh) 7. Many, many more UW CSE 374 Winter 2017 9

  10. Shell programming revisited How do Java programming and shell programming compare? The shell: shorter convenient file-access, file-tests, program-execution, pipes crazy quoting rules and syntax also interactive Java: none of the previous gotchas local variables, modularity, typechecking, array- checking, . . . real data structures, libraries, regular syntax Rough rule of thumb: Don t write shell scripts over 200 lines? UW CSE 374 Winter 2017 10

  11. Treatment of strings Suppose foo is a variable that holds the string hello Java foo foo foo = hi foo + oo library call Bash $foo foo foo=hi ${foo}oo silent and implicit Use variable (get hello ) The string foo Assign variable Concatenation Convert to number Moral: In Java, variable-uses are easier than string- constants Opposite in Bash Both biased toward common use UW CSE 374 Winter 2017 11

  12. More on shell programming Metapoint: Computer scientists automate and end up accidentally inventing (bad) programming languages. It s like using a screwdriver as a pry bar. HW3 in part, will be near the limits of what seems reasonable to do with a shell script (and we ll end up cutting corners as a result) There are plenty of attempts to get the best of both worlds in a scripting language: Perl, Python, Ruby, . . . Personal opinion: it raises the limit to 1000 or 10000 lines? Gets you hooked on short programs. Picking the bash shell was a conscious decision to emphasize the interactive side and see how bad programming can get . Next: Regular expressions, grep, sed, others. UW CSE 374 Winter 2017 12

  13. Bottom line Never do something manually if writing a script would save you time Never write a script if you need a large, robust piece of software Some programming languages try to give the best of both worlds you now have seen two extremes that don t (Java and bash) UW CSE 374 Winter 2017 13

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#