Very Computer

"Point", that is, as in the `.' command, aka `source'.  What's it for?

<RANT-MODE>

"Read and execute commands from the FILENAME argument in the current
shell context.", accoring to the bash.info.  "Current shell context"?
Huh?  

In the bash man page, we get "Read and execute commands from filename in
the current shell environment and return the exit status of the last
command executed from filename."  What the flowerpot full of flying
fuchsias is a "current shell environment" supposed to be?

Going to Newham's and Rosenblatt's "Learning the Bash Shell", we discover
that "_source_ executes the commands in the specified file, ...".
Wonderful?  Why not just type the file's name, and save the 7 characters
involved in typing "source "?  This book is supposed to be a tutorial
book.  (I heartily recommend any beginners to choose some other book
instead.  It would appear it's authors didn't understand `.' when they
wrote their book.  It's not the only thing they seemed not to
understand.)

Well, I found out the answer to this question on Tuesday.  If you call a
script with `.' (or `source'), variables set within the script stay set
when the script finishes.  Otherwise, the changes are lost.  On Tuesday,
I had written a script with several lines like:

export BUILD_BASE = /home/AM/foo/me/bar/dev/start/here/thingy/base

, because it was kind of tedious to type them all by hand, time after
time.  Of course, it didn't work.  At least not until it was called
pointedly.  Are there any other good reasons for using `.'?

Look at the way "export" is defined in these three places, and that's not
much more help.  Essential to a description of "export" is a statement
that the value given a variable is only exported to scripts called from
the current one, and that it's value is lost at the end - it's a sort of
"internal export" only.

"Learning the Bash Shell" is hopeless here.  It merely says "Any variable
can become an environment variable.  First it must be defined as usual;
then it must be _exported_ with the command:  `export varnames'".  

The bash info page is a bit better, saying "Mark each NAME to be passed
to child processes in the environment.".  But what about child processes
which _aren't_ in the environment?  ;-(

<\RANT_MODE>

So - Are there any books/web pages which clearly describe `.', `source'
and `export' without first requiring it's reader to have a mental model
of environments and contexts and suchlike first?  It'd be nice to hear
about them.

--
Alan Mackenzie (Munich, Germany)

(like "aa"), remove half of them (leaving, say, "a").

 > So - Are there any books/web pages which clearly describe `.', `source'
 > and `export' without first requiring it's reader to have a mental model
 > of environments and contexts and suchlike first?  It'd be nice to hear
 > about them.

Since the difference between `. file' and `file' is that the shell
command file is executed in a different environment, no.

See the Command Execution Environment page of the Bash manual.

--
Kevin Rodgers

Quote:>"Point", that is, as in the `.' command, aka `source'.  What's it for?

><RANT-MODE>

....

Well, you already found what is the point of the point - good work on that!
In a way your rant is a deserved one - but on the other hand the issue is
that of not having enough background information.

Quote:>The bash info page is a bit better, saying "Mark each NAME to be passed
>to child processes in the environment.".  But what about child processes
>which _aren't_ in the environment?  ;-(

Er, you're misreading here (not that the original sentence is written
too clearly).

Quote:>So - Are there any books/web pages which clearly describe `.', `source'
>and `export' without first requiring it's reader to have a mental model
>of environments and contexts and suchlike first?  It'd be nice to hear
>about them.

I hope the following helps -- also to understand the one sentence quoted
above.

In Unix systems, when a process creates (forks) another process, the
newly created (child) process inherits its environment (environment
variables, current directory, executing process) from the creating
(parent) process. This is the only place where one process directly
affects the environment of another - and after process creation each
process is solely responsible for its own environment.

Normally, when you run a script from the shell, the script is executed
in a separate process, and thus any changes to the environment (again;
environment variables, current directory, executing process) in the
child process will not affect the parent process. However, there was
also the need to be able to execute scripts so that the scripts would
have the power to affect environment of current shell - and from this
need comes the '.'/source command - it will not run the script in
a subshell, but will execute commands from the script within the
current shell (and thus, current process).

As for deciphering the sentence from bash info documentation; split
it into "what":
- Mark each NAME to be passed to child processes
and "how":
- NAMEs are passed in the environment

So, it's not processes that are or are not in the environment; that
concept doesn't make sense; it's NAMEs that can be local shell variables,
or environment variables.
--
Wolf  a.k.a.  Juha Laiho     Espoo, Finland

         PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)