More on Shell

---

Environment variables

Like global vars for all programs.
Note any environment vars that are declared within a program are local to that program only.

env
printenv
set 			may display shell functions too


var=value               set environment variable
echo var                print the string "var"
echo $var               print value of environment variable


echo $home              get into the habit of using these
                        instead of the actual hard-coded values,
                        - makes scripts more portable
echo path is $path
echo $user
echo `hostname`
echo `arch`             on DCU Linux you get i686
                        on DCU Solaris you get sun4
			recall backquotes

Example of using arch (for C shell): You share the same files across a number of UNIX systems on different hardware. You collect binaries for each platform, but keep them in separate directories underneath your   $home/bin directory. Then you set the path in your .cshrc file:

set path = ( $home/bin/`arch` ... )

---

Strings and echo

echo                    print something on screen, followed by new line
echo -n                 print with no new line

printf                  print with no new line
printf "\n"             print with new line

echo "string"
echo 'string'

	It is useful to have 2 choices for quotes.
	If using one for something else, surround with the other.
	e.g. To search for single quote in file:

	grep ' file        syntax error (why?)
	grep "'" file      surround with quotes and it works
	grep '"' file      to search for the double quote itself




The 2 quotes are not exactly equal:

echo "--$HOME--"       --/users/group/humphrys--
echo '--$HOME--'       --$HOME--
echo '--'$HOME'--'     --/users/group/humphrys--

---

File wildcards

*                       all files
.*                      all hidden files

 "Hidden" in the sense that tools like ls won't list them by default.
 You can write your own tools of course to always list them by default.
 Not actually hidden in the security sense.

 Done for convenience not strict security, like write-protecting your own files
 (which is itself a kind of security since it stops some accidents).
 Doing things to  *  like  rm *  won't affect the  .*  files.
 Like the way  C:\Windows\  won't let you see the files first time.

 In fact  .*  files are probably only in your home directory,
 and your user files are strictly in sub-directories
 so the 2 never meet.
 Like how you strictly separate the files in  C:\Windows\
 from those in  C:\My Documents\

Q. Even on a 1-user system, why separate OS files from user files?

echo *                  echo all files
echo f*                 all files beginning with f
echo */*                files in next layer
*/*/*                   etc.

Important to realise it is the shell that interprets "*" and passes the result to echo or ls or your program. It is not actually echo or ls itself that parses it.

grep string *

# grep does not understand *

# but that's fine because grep does not actually RECEIVE *
# what happens is:
# the shell EXPANDS * to a list of files and passes these to grep
# so grep actually receives:

grep string f1 f2 .. fn

To see that it is the shell that expands it, assign it to an environment variable. Try these:

x=*
echo $x
echo "$x"

x="*"
echo $x
echo "$x"
 
x=`echo *`
echo $x
echo "$x"

Q. Why have the shell interpret "*"? Why not just pass "*" as argument to progs?