Changing working directory

[mrr]

Ok, I guess most of you know Yakuake! As far as I can see it works like
a charm in fluxbox (as does Guake and Tilda).

My issue is with i3, when I execute it, it fails loading completely with
an error like:
"/bin/cd" not found
And until I kill it, it takes 100% of one processor.

cd is a shell builtin (at least on my debian) so it's no surprise that
it can't find it in the bin directory.
What I'd like, just for testing purpose (and now for the challenge too),
would be to implement my /bin/cd in a shell script maybe using the cd
builtin.
The naive approach (I often begin like that actually!) is to simply call
cd as in:

#!/bin/bash
cd "$@"

But as the shell forks it actually changes only the son's working directory.
Question:
- Is there a simple (or not) way to do it via a script?
- If not (and here we're getting out of Linux theme, feel free to ignore
this if you want), any hint at how to do it in C?

--
mrr

[Whiskers]

Could there be a fundamental incompatibility between a "drop-down
terminal emulator" and a "tiling window manager"? Tiling WMs don't
really embrace the concept of drop-down anything.

There is probably a key-binding within i3 to launch a new 'terminal',
but it may only work with conventional terminal emulators (such as
xterm, rxvt, etc).

--
-- ^^^^^^^^^^
-- Whiskers
-- ~~~~~~~~~~

[Richard Kettlewell]

mrr <mir...@free.fr> writes:
> Ok, I guess most of you know Yakuake! As far as I can see it works
> like a charm in fluxbox (as does Guake and Tilda).
>
> My issue is with i3, when I execute it, it fails loading completely
> with an error like:

I’ve never heard of any of the above things, so I may be missing some
context in what follows.

> "/bin/cd" not found
> And until I kill it, it takes 100% of one processor.
>
> cd is a shell builtin (at least on my debian) so it's no surprise that
> it can't find it in the bin directory.
> What I'd like, just for testing purpose (and now for the challenge
> too), would be to implement my /bin/cd in a shell script maybe using
> the cd builtin.
> The naive approach (I often begin like that actually!) is to simply
> call cd as in:
>
> #!/bin/bash
> cd "$@"
>
> But as the shell forks it actually changes only the son's working directory.
> Question:
> - Is there a simple (or not) way to do it via a script?
> - If not (and here we're getting out of Linux theme, feel free to
> ignore this if you want), any hint at how to do it in C?

1. A process trying to change its own directory by running /bin/cd will
never work. This is just broken. The answer is to fix the broken
program (or possibly its configuration, if it’s just blindly
executing stuff found there).

2. SUS does require that cd be accessible via execve(). See s1.6 of
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html
i.e. the absence of /bin/cd (or /usr/bin/cd or similar) on most Linux
systems is a standards violation, albeit not a very interesting one.

3. SUS also acknowledges that accessing cd via execve() will not
actually change a caller’s working directory. See ‘Application
usage’ in
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cd.html
- as such the executable version (if it exists) is only really usable
for testing whether something is an accessible directory.

4. The only way to make a /bin/cd that actually changed its parent’s
directory would for it to use a debugger (or the underlying ptrace
syscall) to attach to its parent and run chdir() inside it. This
doesn’t seem like a very good idea since anything that relies on a
standards-conforming /bin/cd will stop working properly. It also
won’t work on all processes.

--
http://www.greenend.org.uk/rjk/

[mrr]

On 02/18/2015 01:09 PM, Richard Kettlewell wrote:

> 1. A process trying to change its own directory by running /bin/cd will
> never work. This is just broken. The answer is to fix the broken
> program (or possibly its configuration, if it’s just blindly
> executing stuff found there).
>
> 2. SUS does require that cd be accessible via execve(). See s1.6 of
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html
> i.e. the absence of /bin/cd (or /usr/bin/cd or similar) on most Linux
> systems is a standards violation, albeit not a very interesting one.
>
> 3. SUS also acknowledges that accessing cd via execve() will not
> actually change a caller’s working directory. See ‘Application
> usage’ in
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cd.html
> - as such the executable version (if it exists) is only really usable
> for testing whether something is an accessible directory.
>
> 4. The only way to make a /bin/cd that actually changed its parent’s
> directory would for it to use a debugger (or the underlying ptrace
> syscall) to attach to its parent and run chdir() inside it. This
> doesn’t seem like a very good idea since anything that relies on a
> standards-conforming /bin/cd will stop working properly. It also
> won’t work on all processes.
>

Thanks Richard!

And yes Whiskers, yakuake isn't probably designed for a tilling WM
although i3 is quite tolerant (guake and tilda do work).

For what that's worth here is the exact error message that repeats
forever until using 100% of one processor:

yakuake(23435)/kdecore (KLibrary) findLibraryInternal: plugins should
not have a 'lib' prefix: "libkonsolepart.so"
yakuake(23435)/konsole: "Could not find binary: " "/bin/cd"

Well that's a Qt/KDE designed software so no big surprise with
lightdm/i3. (konsole alone doesn't work too).


--
mrr

[mrr]

Actually, if I understand, any process inherit from it's parent a
working directory and it is stored in some of the process environmental
variables.
So if one could access (that's something else!) this variable, that is
the only reference to a current working directory, isn't it?

In definitive, an call to /bin/cd in an execve would usually be pointless?

--
mrr

[Richard Kettlewell]

mrr <mir...@free.fr> writes:
> Actually, if I understand, any process inherit from it's parent a
> working directory and it is stored in some of the process
> environmental variables.
> So if one could access (that's something else!) this variable, that is
> the only reference to a current working directory, isn't it?

The working directory (i.e. that gwtcwd(), chdir(), open(), etc use) is
tracked by the kernel. Environment variables are not involved.

Some programs will additionally store the value in an environment
variable, but that’s not what is actually used.

> In definitive, an call to /bin/cd in an execve would usually be pointless?

Yes.

--
http://www.greenend.org.uk/rjk/

[Whiskers]

KDE projects generally seem to be very interdependent on each other.
Have you installed all the dependencies of yakuake? (You might need
most of the current version of KDE!).

[mrr]

On 02/19/2015 11:41 PM, Whiskers wrote:

>> yakuake(23435)/kdecore (KLibrary) findLibraryInternal: plugins should
>> not have a 'lib' prefix: "libkonsolepart.so"
>> yakuake(23435)/konsole: "Could not find binary: " "/bin/cd"
>>
>> Well that's a Qt/KDE designed software so no big surprise with
>> lightdm/i3. (konsole alone doesn't work too).
>
> KDE projects generally seem to be very interdependent on each other.
> Have you installed all the dependencies of yakuake? (You might need
> most of the current version of KDE!).

Looks quite logical but I don't think that is the source of this problem
because:
- All dependencies listed by apt are installed (and dependencies [of
dependencies]n has to!).
- It does work in fluxbox.

If I create a /bin/cd empty executable file I get:
- In console:
QDBusConnection: session D-Bus connection created before
QCoreApplication. Application may misbehave.
QDBusConnection: session D-Bus connection created before
QCoreApplication. Application may misbehave.
yakuake(8689)/kdecore (KLibrary) findLibraryInternal: plugins should not

have a 'lib' prefix: "libkonsolepart.so"

Not sure about the 'lib' error so "off chance" I created links
konsolepart.so and lkonsolepart.so without effect.

Now Yakuake is running and F12 shows me twice:

Warning: Could not start program '/bin/cd' with arguments '/bin/cd c'.
Warning: Exec format error

And then I can write in the console without answers. It's like a
terminal without shell.

It might take almost nothing to get it working, I will add a shebang and
exit 0 and maybe...
The only 'c' directory I have is in my home folder. Why is it trying
this one, I don't know, maybe some kind of history but I thought by
default It would open ~/.

--
mrr

[Richard Kettlewell]

mrr <mir...@free.fr> writes:
> Looks quite logical but I don't think that is the source of this
> problem because:
> - All dependencies listed by apt are installed (and dependencies [of
> dependencies]n has to!).
> - It does work in fluxbox.
>
> If I create a /bin/cd empty executable file I get:

You’re never going to fix this by trying to create a ‘good enough’
/bin/cd. You need to figure out where it’s coming from and fix that.

The string doesn’t appear in the konsole or yakuake source so it is
almost certainly your local configuration that is broken.

--
http://www.greenend.org.uk/rjk/

[mrr]

Yes, I didn't believe in a /bin/cd making it working but I got
interested by the current working directory and how it was related to a
process.

You helped me learn and I thank you for that!
A
bout yakuake, I'm ashamed to confess that in a conf file the terminal
was configured to launch "/bin/cd c" instead of "/bin/bash"!

Nobody except me can access this computer so I *have* to be the one who
changed that conf. I might have been quite drunk because I don't
remember that. And last time I drank like that is quite far away.

Anyway, yakuake works like a charm, out of the box.

And that the principal, thanks guys! :)

--
mrr

[William Unruh]

On 2015-02-19, mrr <mir...@free.fr> wrote:
> Actually, if I understand, any process inherit from it's parent a
> working directory and it is stored in some of the process environmental
> variables.
> So if one could access (that's something else!) this variable, that is
> the only reference to a current working directory, isn't it?

A child process gets its own copy of the environment and has no access
to the parent's copy. Also the enviroment variable is informative not
determinative. Ie, changing the environment variable does not change the
directory AFAIK.

>
> In definitive, an call to /bin/cd in an execve would usually be pointless?

Yes.
There are system commands which will change the working directory of the
current process.

>

[mrr]

On 02/20/2015 08:46 PM, William Unruh wrote:

>> In definitive, an call to /bin/cd in an execve would usually be pointless?
>
> Yes.
> There are system commands which will change the working directory of the
> current process.

Ok, thank you both, now that's clear.
I was thinking that the cwd was handled in userland and didn't involve
some system call. I find that quite a "heavy" strategy but one could
argue progs doesn't often use those calls.


--
mrr

[Eef Hartman]

mrr <mir...@free.fr> wrote:
> Ok, thank you both, now that's clear.
> I was thinking that the cwd was handled in userland and didn't involve
> some system call.

As "chdir" is a man(2) function it IS a system call (2 = system calls, 3
= C library):
CHDIR(2) Linux Programmer's Manual

NAME
chdir, fchdir - change working directory

(part skipped)
DESCRIPTION
chdir() changes the current working directory of the calling
process to the directory specified in path.

fchdir() is identical to chdir(); the only difference is that
the directory is given as an open file descriptor.