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

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

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

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

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

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

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

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