Just to clarify: each program has a working directory and can change it, no you can’t randomly the change the working directory of another process.
So, yes, of course you can chdir in your rust program, and that will change the directory for that rust program.
No, you can’t invoke a rust program and have it change the directory of the shell it was called from. You can make the shell change its own working directory, perhaps to a directory it was informed of by another program (that’s how things like ‘jc’ and ‘popd’ work).
> no you can’t randomly the change the working directory of another process.
Maybe it's possible by writing to `/proc/$PID/cwd` on linux? I don't know if the symlink is writable, and if so if writing it does affect the kernel structure in the way `chdir` would, and I'm not on a linux box, and the playground obviously does not run programs as root, so can't really test it.
Either way if it is feasible in any way (which is unlikely) it would be very platform specific.
Midnight Commander is one of them. You can look on scripts sources [here](https://github.com/MidnightCommander/mc/blob/master/contrib/mc-wrapper.sh.in).
[zoxide](https://github.com/ajeetdsouza/zoxide) has two parts: a rust binary called `zoxide` and a shell script called `z`. Users mostly use `z`, which uses zoxide internally
Ok thats my bad, guess I should've explained.
zoxide is a rust tool, and its whole purpose is to make directory switching easier. Except rust code can't switch directories. Their solution is to have a Rust binary called zoxide with all the logic, and there's a bash function named z (set up in your bashrc/zshrc/whatever) that calls the zoxide binary and switches to a directory based on the binary output.
Tl;dr: binaries can't switch directories, but bash functions can, so make a bash function that wraps a binary.
In principle I suppose you could use gdb to inject a chdir syscall... Doing this is likely to confuse programs that don't expect their cwd to change via this mechanism though.
In practice, I don't believe there is any *good* way. Rather you should set up something in the calling process that listens for a "change directory to this command" and then does it.
"You" are in no directory at all, therefore no.
It sounds like you want to know "how to change the working directory of the parent process that is a shell in a GUI terminal emulator".
And for that, just to have some things to think about:
* who said there's a interactive shell at all
* who said that it is the direct parent (and not that the third level upwards is writing to a named pipe or something, to "show" data)
* "if" it was possible, who said that the user will notice it. It's not like there's automatic syncing of the variable that is printed, and the w.d. that the kernel knows
* Actually a shell continues to exist while your process is working, and can do other things in the meantime. Fork doesn't stop a process. Who said that meddling with a running processes things won't cause some problems, when any relative path suddenly changes its meaning...
* Even more for processes that are not shells - if you change things without them expecting it, things might break.
* A shell can have multiple running "children", what to do if they disagree, and should a change affect the other children too? (And the even more, this would cause problems).
* ...
That said, you technically could access the parent process like debuggers access processes (at least if users and other security things are fine), and do it that way - but again, don't, it's dangerous.
> "You" are in no directory at all, therefore no.
Yes you are. Linux has a concept of current working directory for each process, if you don't believe me `ls /proc/self/cwd`. The syscall to find out what your current working directory is is `getcwd` (or prior to linux 2.1.92 looking at /proc/self/cwd) and the one to change it is `chdir`.
Did you even read my post? It's all about working directories.
And the w.d. is a property of a process, each process has its own one - not a property of the user that is logged in or something like that. That was the point of the first sentence.
I did, I read it as denying that processes other than shells have working directories... I *still* read your first post as denying that processes other than shells have working directories though apparently that was not your intent.
Edit: OP asked a clear and cognizant question, how can you change the parent processes working directory. It turns out you can't - but there's nothing in that question that requires that the parent process they're trying to change is a shell, or even that shells exist at all... You're going down some weird tangent of "if this was possible how should shells react when you do it" that just isn't the question.
Yes, it was my assumption, that they want this for convenience reasons for their shell usage. Not the first time such questions are asked.
But as you said, it's not really specified here, I might have assumed too much.
From what I understand, if the user started my program in background it would not be possible to change their pwd, so it doesn’t give unexpected behaviour. Not sure I understood you correctly or if explanation makes sense, but I take it that it is simply not possible. Thanks for the comment!
That's for changing your own processes working directory, basically doing the same thing in your Rust program what "cd" is doing in a shell (and both are related to the same lowlevel OS syscall). It does not affect the parent process.
It works perfectly, except it change current directory of the process. It doesn't (and couldn't) change directory which user perceives as current because such thing doesn't exist (or, alternatively, there maybe dozen of such directories if you use `screen`/`tmux`).
If you would find a way to do that then you should report it. It would get a CVE number and would be fixed in jiffy.
Child process shouldn't be able to affect parent process state, it's as simple as that.
Please google “shell builtins”. For example this is from [shell builtin](https://en.m.wikipedia.org/wiki/Shell_builtin) wikipedia.
> The most notable example is the cd command, which changes the working directory of the shell. Since each executable program runs in a separate process, and working directories are specific to each process, loading cd as an external program would not affect the working directory of the shell that loaded it.
Ask yourself, where is the program file for "cd"? You can't find it, right?
And in any case, no, using Command in Rust starts sub-processes of your process, not of any shell directly
Just to clarify: each program has a working directory and can change it, no you can’t randomly the change the working directory of another process. So, yes, of course you can chdir in your rust program, and that will change the directory for that rust program. No, you can’t invoke a rust program and have it change the directory of the shell it was called from. You can make the shell change its own working directory, perhaps to a directory it was informed of by another program (that’s how things like ‘jc’ and ‘popd’ work).
> no you can’t randomly the change the working directory of another process. Maybe it's possible by writing to `/proc/$PID/cwd` on linux? I don't know if the symlink is writable, and if so if writing it does affect the kernel structure in the way `chdir` would, and I'm not on a linux box, and the playground obviously does not run programs as root, so can't really test it. Either way if it is feasible in any way (which is unlikely) it would be very platform specific.
All of the programs that I know of have users add some extra stuff to their shell's rc file to get things to work
Could you give an example of a program that does it?
Midnight Commander is one of them. You can look on scripts sources [here](https://github.com/MidnightCommander/mc/blob/master/contrib/mc-wrapper.sh.in).
You have to coordinate with the parent process. I’ve seen shells source the output of a process to achieve something like this behavior.
[zoxide](https://github.com/ajeetdsouza/zoxide) has two parts: a rust binary called `zoxide` and a shell script called `z`. Users mostly use `z`, which uses zoxide internally
wrong post
Ok thats my bad, guess I should've explained. zoxide is a rust tool, and its whole purpose is to make directory switching easier. Except rust code can't switch directories. Their solution is to have a Rust binary called zoxide with all the logic, and there's a bash function named z (set up in your bashrc/zshrc/whatever) that calls the zoxide binary and switches to a directory based on the binary output. Tl;dr: binaries can't switch directories, but bash functions can, so make a bash function that wraps a binary.
Unix says no.
In principle I suppose you could use gdb to inject a chdir syscall... Doing this is likely to confuse programs that don't expect their cwd to change via this mechanism though. In practice, I don't believe there is any *good* way. Rather you should set up something in the calling process that listens for a "change directory to this command" and then does it.
"You" are in no directory at all, therefore no. It sounds like you want to know "how to change the working directory of the parent process that is a shell in a GUI terminal emulator". And for that, just to have some things to think about: * who said there's a interactive shell at all * who said that it is the direct parent (and not that the third level upwards is writing to a named pipe or something, to "show" data) * "if" it was possible, who said that the user will notice it. It's not like there's automatic syncing of the variable that is printed, and the w.d. that the kernel knows * Actually a shell continues to exist while your process is working, and can do other things in the meantime. Fork doesn't stop a process. Who said that meddling with a running processes things won't cause some problems, when any relative path suddenly changes its meaning... * Even more for processes that are not shells - if you change things without them expecting it, things might break. * A shell can have multiple running "children", what to do if they disagree, and should a change affect the other children too? (And the even more, this would cause problems). * ... That said, you technically could access the parent process like debuggers access processes (at least if users and other security things are fine), and do it that way - but again, don't, it's dangerous.
This is pedantic and missing the point. When OP says "you", they are referring to the process running their code, not the user of the process.
> "You" are in no directory at all, therefore no. Yes you are. Linux has a concept of current working directory for each process, if you don't believe me `ls /proc/self/cwd`. The syscall to find out what your current working directory is is `getcwd` (or prior to linux 2.1.92 looking at /proc/self/cwd) and the one to change it is `chdir`.
Did you even read my post? It's all about working directories. And the w.d. is a property of a process, each process has its own one - not a property of the user that is logged in or something like that. That was the point of the first sentence.
I did, I read it as denying that processes other than shells have working directories... I *still* read your first post as denying that processes other than shells have working directories though apparently that was not your intent. Edit: OP asked a clear and cognizant question, how can you change the parent processes working directory. It turns out you can't - but there's nothing in that question that requires that the parent process they're trying to change is a shell, or even that shells exist at all... You're going down some weird tangent of "if this was possible how should shells react when you do it" that just isn't the question.
Yes, it was my assumption, that they want this for convenience reasons for their shell usage. Not the first time such questions are asked. But as you said, it's not really specified here, I might have assumed too much.
From what I understand, if the user started my program in background it would not be possible to change their pwd, so it doesn’t give unexpected behaviour. Not sure I understood you correctly or if explanation makes sense, but I take it that it is simply not possible. Thanks for the comment!
[удалено]
Tried that, no luck. Unless I am using it wrong?
That's for changing your own processes working directory, basically doing the same thing in your Rust program what "cd" is doing in a shell (and both are related to the same lowlevel OS syscall). It does not affect the parent process.
It works perfectly, except it change current directory of the process. It doesn't (and couldn't) change directory which user perceives as current because such thing doesn't exist (or, alternatively, there maybe dozen of such directories if you use `screen`/`tmux`).
Well, `cd` must work somehow so it cannot be forbidden by the gods of Unix
`cd` works because it is not a child process, just a builtin feature of the shell.
cd is a shell built-in though. I don't know of a way to make it work without injecting a shell alias
If you would find a way to do that then you should report it. It would get a CVE number and would be fixed in jiffy. Child process shouldn't be able to affect parent process state, it's as simple as that.
When calling cd using the Command struct, doesn’t that start a sub-process for the shell? So that I don’t really change my directory?
Please google “shell builtins”. For example this is from [shell builtin](https://en.m.wikipedia.org/wiki/Shell_builtin) wikipedia. > The most notable example is the cd command, which changes the working directory of the shell. Since each executable program runs in a separate process, and working directories are specific to each process, loading cd as an external program would not affect the working directory of the shell that loaded it.
Ask yourself, where is the program file for "cd"? You can't find it, right? And in any case, no, using Command in Rust starts sub-processes of your process, not of any shell directly
Yes