![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
There's no cd program in my system. I suppose that's because what this
program is supposed to do is to change something internal to a
process; the shell in this case.
Is there a way to overcome this? I'd like to run a program that
changes my current working directory. I don't want to do it through my
shell's language.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: clipka
Subject: Re: how to change the cwd of a running shell?
Date: 22 Aug 2009 21:23:57
Message: <4a909a2d@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Daniel Bastos schrieb:
> Is there a way to overcome this? I'd like to run a program that
> changes my current working directory. I don't want to do it through my
> shell's language.
You can /only/ do it through your shell's language.
The current working directory is part of the so-called "environment" of
a process (i.e. a running program) - a collection of various information
that is local to the process; there is exactly one situation where one
process has control over another's environment: A new process will
always start with its environment set to the same values as the process
which started it. Aside from that, no process can tamper with the
environment of another process - so no external program your shell could
possibly start would have the ability to change the shell's working
directory.
You will not find a "cd" command on /any/ Unix machine - it only exists
as a built-in shell command.
(Assuming you're talking about some Unix variant here; but I guess other
multitasking OS will handle the CWD in a similar fashion.)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <4a909a2d@news.povray.org>,
clipka wrote:
[...]
> You will not find a "cd" command on /any/ Unix machine - it only exists
> as a built-in shell command.
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.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Daniel Bastos wrote:
> I hope this can work, somehow.
No. What you want to look at is the command called "source".
If you want to arbitrarily change the shell's behavior, and your program is
called "xyz", then what you want is the commands
% ./xyz ; source ./pdq
and then have your "xyz" program output a file of shell commands (with
setvar and cd and such) to a file called "pdq". Environment variables are
like the working directory - they are copied per-process.
Wow, that was surprisingly easy to find. I expected to spend 10 minutes
coming up with the right google terms, even already knowing how all this
works. Check this out:
http://perl.plover.com/yak/commands/
Note that the "source" command basically says "Here's a shell script - don't
fork before interpreting it." Note also that many bits of this are different
in Windows, DOS, etc. Note also that if it's your program for which you're
setting up the environment this way, you're doing it wrong. (I.e., if you
stick stuff in "environment variables" that change on a per-program basis,
that's not really part of your "environment", and that's exactly why you're
having those troubles. Just as a philosophical point.)
Hope that helps you understand things.
--
Darren New, San Diego CA, USA (PST)
Understanding the structure of the universe
via religion is like understanding the
structure of computers via Tron.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Jim Henderson
Subject: Re: how to change the cwd of a running shell?
Date: 23 Aug 2009 00:55:17
Message: <4a90cbb5@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Sat, 22 Aug 2009 23:27:36 -0400, Daniel Bastos wrote:
> I suppose I can insert an environment variable back to the shell,
> somehow?
Generally no, because the current working directory isn't "set" by the
shell, rather the CWD variable is set by changing the directory. IOW,
it's a "status" value, not a "push" value.
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: clipka
Subject: Re: how to change the cwd of a running shell?
Date: 23 Aug 2009 03:59:20
Message: <4a90f6d8@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/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) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka wrote:
> if it succeeds (exit code != 0),
Technically, exit code == 0 means success, on the grounds that there's only
one success but multiple possible failures. C function calls tend to work
the other way, with one failure and multiple possible successes.
--
Darren New, San Diego CA, USA (PST)
Understanding the structure of the universe
via religion is like understanding the
structure of computers via Tron.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New schrieb:
>> if it succeeds (exit code != 0),
>
> Technically, exit code == 0 means success, on the grounds that there's
> only one success but multiple possible failures. C function calls tend
> to work the other way, with one failure and multiple possible successes.
Darn - indeed, got it wrong way round there. Should have proofread more.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |