|
![](/i/fill.gif) |
Daniel Bastos schrieb:
> That makes sense. I will then give the shell the information, and have
> it execute. I suppose I can insert an environment variable back to the
> shell, somehow? For instance,
>
> ./setvar var value
>
> %echo $var
> value
>
> I hope this can work, somehow.
As Darren and Jim have pointed out already, the way via environment
variables suffers from the same problem as the working directory itself:
They're part of the process environment (hence the name ;-)).
In Unix, there are two (well, three) standard ways to get information
out of a program to the calling shell:
(1) exit code:
This is an integer value returned by every program, usually used to
indicate success (=zero) or failure (=nonzero, the particular value
often indicating the reason for the failure), which a standard shell
will typically expose via the $? (pseudo-) environment variable; most
shells also feature built-in flow-control commands that take a command
to be executed and directly evaluate the exit code, such as:
if foo
then
...
else
...
fi
(i.e. execute foo, and depending on its exit code do diffent things) or
other shorthand forms, such as:
foo && bar
meaning "try executing foo; if it succeeds (exit code != 0), execute bar
as well".
(2a) standard output stream:
This is /the/ standard method of getting bulk data out of a program
(again, this is why it's called that way). Virtually all shells will
have some way of doing smart things with the data (usually text) some
program sends to its standard output:
- Display it (this is the default)
- Redirect it to the standard input stream of another program
("piping"); this is often used with filter or conversion program (grep
or sed, for instance) - which in turn send the results to their own
standard out, which can be processed further by a third command... The
syntax would be:
foo | bar | ...
- Store (or append) it to a file:
foo > bar.txt
foo >> bar.txt
- Store it in an environment variable(!):
bar=`foo`
bar=$(foo)
both instructing the shell to "execute foo, and store its output in your
environment variable bar" (the second is bash syntax; I don't know
whether it is supported by other common shells as well).
(2b) standard error stream:
This is just like standard output, except that it's intended as a
separate channel for diagnostic information (including - but not
necessarily limited to - error messages), so that it can be
distinguished from "proper" output.
So to come back to your sample script:
> ./setvar var value
>
> %echo $var
> value
this can be easily done using:
var=`echo value`
echo "changing to directory '$var'"
cd "$var"
which will output "changing to directory 'value'" and do exactly that.
Or your program foo might output "dir=value" somewhere in its output
stream, which you could then evaluate using:
var=`foo | grep -e '^dir=' | sed -e 's/^dir=//'`
echo "changing to directory '$var'"
cd "$var"
The first line instructs the shell to run "foo", hand its output over to
the command "grep" instructing it to output only lines starting with
"dir=", pass grep's output on to the command "sed" instructing it to
substitute any leading "dir=" with an empty string (i.e. strip all
leading "dir="), and ultimately store the resulting output in the
shell's environment variable "var".
Post a reply to this message
|
![](/i/fill.gif) |