Should rc unset PWD?

[kreuter]

rc doesn't update PWD the way other shells do; I'm not asking that it do so. However, if an rc process inherits PWD and changes directory, any programs run under rc will inherit an incorrect PWD. I propose that an rc process simply unset PWD when it starts. (But only when it starts, so that a user might maintain PWD in custom cd/pushd/popd functions if they want to.)

Explanation: I have an ancient habit of preferring PWD over getcwd() in programs when I need a pathname for the working directory, because PWD typically contains or derives from previously-supplied user input, while getcwd()'s result can be different from anything the user wants to see or use. (In my programs, such pathnames are usually for diagnostic messages. I should probably always check if the PWD names the same directory as ".", but I'm sure I haven't done so consistently over the years. Anyhow I'd rather the environment variable be unset than incorrect.)

Note: I believe this is orthogonal to whether rc might maintain a $pwd variable, and with what semantics that has. (Drazen Borkovic's fork does this, but it looks like that fork leaves PWD alone, i.e., prone to have a stale value.)

[oliwer]

I agree that maintaining a correct $PWD is important since many programs out there rely on it.

But only when it starts , so that a user might maintain PWD in custom cd/pushd/popd functions

So you mean rc should unset $PWD only when run as a login shell? In that case, you could simply add PWD=() to your .rcrc file. Or do you mean this should be hardcoded into rc?

[kreuter]

First, to clarify: I'm not asking that rc maintain a value for PWD [*], but that rc give its children no PWD.

Second, I did truly mean to suggest rc unset PWD whenever it starts, not only as a login shell. Suppose the user's login shell is not rc, and they run an rc script that cd's: its subsequent children will inherit a PWD that disagrees with the cwd.

[*] I would not object if rc maintained PWD using the POSIX shell's rules, but those rules are complicated and presumably not to everyone's liking; they're also easy enough to do in one's .rcrc for anybody who cares. However, I do not see much value maintaining a PWD with a different semantic than POSIX shell's, e.g., simply setting PWD to the result of getcwd(). That pathname will refer to the cwd, but not always as the pathname I want to see: I still use NFS file servers and automounters, and after cd $home/src/foo, I would prefer to see /home/me/src/foo rather than, say, /net/file-server.vpn.my-domain/path/to/sources/foo. That is, the benefit of the POSIX shell's rules about PWD is that it represents information the user actually input in the past, which information isn't retrievable or reconstructible if it's been discarded. So that's why I'm not asking for rc to maintain a PWD at all: ISTM that no-PWD and POSIX-PWD are different sorts of local optima, and anything else is less good.

(See also https://plan9.io/sys/doc/lexnames.html for more on the issues of directories with multiple names. IIUC, Plan 9 actually did solve this problem by having the OS remember a causal history for how the process got to its cwd; so Duff's rc never needed to maintain a pwd variable.)

[oliwer]

That makes sense. But in my case, I maintain $PWD using custom cd and pwd functions in my .rcrc, and I want subshells to inherit $PWD.

What could work instead, is for rc's builtin cd to unset $PWD (instead of unseting it at startup). This way, we only unset it when it needs to be, and custom cd functions can set the correct $PWD.

[rakitzis]

If anything I would prefer to generalize this. Making custom behavior for PWD feels like a one-off, and opens the door to other custom behaviors. What about fn init, if defined, which will run at startup of any shell (interactive or non-interactive)? fn prompt already serves as a de-facto fn init for interactive shells.

[kreuter]

@oliwer I hadn't consciously thought about subshells, but for clarity, I would not consider forking a subshell to be a moment rc starts. I suppose that was ambiguous; sorry about that!

@rakitzis I think I see what you mean about treating PWD as a one-off, but unsetting PWD seems to me to be a small variant on the already-existing "alias" treatment rc has for PATH, HOME, and CDPATH. rc doesn't use those 3 variables (except perhaps at startup), and could leave them alone; but this would cause undesirable behavior in children. Similarly, leaving PWD unchanged can also cause undesired behavior in children, so wants some sort of (not identical) handling. At least, that's how I look at it.

Maybe it'd be easier to evaluate the suggestion with an implementation in hand?

kreuter@f13ccc6

Whatever you conclude, thank you for your time spent considering this issue.