plash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Plash] executable objects and cwd


From: Mark Seaborn
Subject: Re: [Plash] executable objects and cwd
Date: Sat, 17 Jun 2006 12:53:20 +0100 (BST)

Toby Murray <address@hidden> wrote:

> Firstly, from some quick experimenting, I can't seem to find a 
> configuration in which an executable object (created with exec-object) 
> is able to call getcwd() successfully.

This is because exec-object doesn't implement setting the cwd.

I have just fixed this in SVN.

If you're interested, the change is:
http://svn.gna.org/viewcvs/plash/trunk/src/exec-object.c?r1=text&tr1=53&r2=text&tr2=129&diff_format=l

> On a related note, how does pola-shell determine whether or not to set 
> the cwd of a child process? Turning on the 'print_fs_tree' option allows 
> one to find out when it does choose to set the cwd.
> (eg. plash-opts /obj1=options  'print_fs_tree'  'on' )

The shell sets up a namespace for the child process.  If the user's
cwd (as a pathname) is visible in that namespace, the shell sets the
cwd for the child.  Otherwise, the child's cwd is left undefined
(which means using any cwd-relative pathname gives an error).

For normal executables, the shell spawns the child process itself, and
it sets the cwd itself.

However, for executable objects, the shell just sends a message to the
executable object.  In this case, the shell passes the cwd pathname as
an argument, and it's up to the executable object to set this cwd in
the process it spawns.


The idea behind having an undefined cwd is that it's better than
silently changing the cwd to, say, the root directory, because that
might cause the program to access the wrong files.


Suppose your cwd is "/home/fred":

> my_getcwd /
> 
> I get the debugging output: "set cwd successfully"

The cwd is set because the namespace created by the shell contains
"/home/fred" -- the namespace is the root directory.

I suppose this message is misleading for executable objects.
I've just changed it to "sending cwd argument":
http://svn.gna.org/viewcvs/plash/trunk/src/shell.c

> if I run
> 
> my_getcwd /somedir
> 
> (where /somedir is the path to the 'getcwd' binary)
> instead it says "leaving cwd unset".

Here the namespace created by the shell for this command only contains
"/somedir".  The namespace doesn't contain "/home/fred" so the cwd is
not set.  The shell doesn't add in defaults like "/usr", "/bin"
etc. when invoking executable objects.  exec-object later unions this
namespace with another namespace that contains "/somedir", but the
shell doesn't know about that.

Mark




reply via email to

[Prev in Thread] Current Thread [Next in Thread]