Should es manage PWD?

[jpco]

Right now, es doesn't know or care about the PWD environment variable. This violates the POSIX standard, but es doesn't really care about POSIX compatibility, and it seems like for the most part, things "just work" without PWD.

However, I recently ran into a case where a missing or incorrect PWD variable causes wrong behavior (specifically, terminal cwd-syncing behavior like this, though I also found this fish issue where bad PWDs caused people a lot of other problems). So I started looking into it. Based on a couple other shells, the right behavior seems to be:

• On shell startup, check PWD against cwd (i.e., the return value from getcwd(3)). If the two point to the same inode, chdir(3) to PWD. Otherwise, set PWD to cwd.
• At cd time, set PWD to the new cwd.

Note that PWD only makes sense if it's an absolute pathname. PWD need not, however, be a canonical pathname, and the behavior described above makes the shell respect it if PWD includes symlinks.

It's reasonably easy to hack an approximation of this into .esrc with something like this:

let (cd = $fn-cd)
fn cd dir {
  let (result = <={$fn-cd $dir}) {
    PWD = `pwd
    result $result
  }
}
PWD = `pwd

But I find this lacking in a couple ways. First, I really don't like depending on an external binary like /bin/pwd during cd. It would be pretty simple to either define a $&pwd primitive, or as a more general option, add a -a flag for $&access, such that access -1a path canonicalizes path when printing it. Then pwd could either be defined as echo <=$&pwd or echo <={access -1a .}, respectively.

Second, this version doesn't actually sync PWD with the current directory at (non-login) shell startup, and there's really no facility to do something like that. You could hack up a new %batch-loop and %interactive-loop in .esrc to set PWD right at the start, I suppose.

There's also the matter of "if PWD is equivalent to cwd modulo symlinks, keep the current value", but I can't even picture a way to do that in es script.

So, a couple alternate ideas, in decreasing order of special-casing PWD:

1. Build PWD all into C: add an initwd() in main.c which handles the startup behavior and add PWD-setting logic within $&cd.
2. Build some stuff into C: add initwd() in main.c, and provide a $&pwd primitive that can be called within cd.

These first two options can provide behavior that perfectly matches the "common" shell path, especially with respect to symbolic links. The following options don't, in my mind, provide a clear way to handle symlinks well.

3. Add more general tools which happen to serve to help users sync PWD, like a shell-startup hook and a canonicalization flag for $&access.
4. Do nothing, the current behavior is okay.

The last two options don't handle symlinks quite right, in the case where the absolute path from getcwd() may not be the "canonical" path. One of the big fights in the mailing list was on this exact topic :) Based on my understanding of how it works, the typical shell behavior is pretty okay, but of course giving the user the ability to write their own preference into the shell would be nice.

I'm curious how people feel about all this. I was happy just hacking a cwd in for my own convenience until I realized that PWD is actually kind of load bearing, so it deserves some thinking about what the default behavior should be out of the box.

[jrbarnette]

Hmmm... For many years, I used some customizations (as es functions) that provided several things, including keeping PWD up-to-date with every invocation of "cd".

Here's what I had then:
fn internal-cd dir {
if {!~ $dir /* && !~ $#cdpath 0 && !access -xd $dir} {
dir = <={access -n $dir -1exd $cdpath}
}
$&cd $dir
if {~ $dir /*} {
PWD = $dir
} {
PWD = $PWD^/^$dir
}
let (pwd = <={%split / $PWD}) {
if {~ $pwd ..} {
PWD = `pwd
} {
if {~ $pwd .} {
pwd = <={
map @ d {
if {~ $d .} { result () } { result $d }
} $pwd
}
}
PWD = /^<={%flatten / $pwd}
}
}
result $dir
}

That's a little involved, but it avoids invoking /bin/pwd unless there's messiness involving a reference to "..".
IIRC, there were also issues if any component of PWD was a symlink. Also, IIRC, I found other shells of the time had similar issues.

As keeping PWD up-to-date with subshell invocations, I found this in my old setup:
let (savedpid = $pid) {
fn %prompt {
if {!~ $savedpid $pid} {
. ~/.esrc
savedpid = $pid
} {
jobs -n
}
}
}

It's been awhile, but I think that snippet guaranteed a lot of stuff got re-updated after pushing an interactive subshell.

[jrbarnette]

Argh! Need to do the code snippets with Markdown, it seems:

My magical cd for managing PWD:

        fn internal-cd dir {
            if {!~ $dir /* && !~ $#cdpath 0 && !access -xd $dir} {
                dir = <={access -n $dir -1exd $cdpath}
            }
            $&cd $dir
            if {~ $dir /*} {
                PWD = $dir
            } {
                PWD = $PWD^/^$dir
            } 
            let (pwd = <={%split / $PWD}) {
                if {~ $pwd ..} {
                    PWD = `pwd
                } {
                    if {~ $pwd .} {
                        pwd = <={
                            map @ d {
                                if {~ $d .} { result () } { result $d }
                            } $pwd
                        }
                    }
                    PWD = /^<={%flatten / $pwd}
                }
            }
            prompt
            result $dir
        }

And the magic I used to update PWD, etc. in a subshell:

let (savedpid = $pid) {
    fn %prompt {
        if {!~ $savedpid $pid} {
            . ~/.esrc
            savedpid = $pid
        } { 
            jobs -n 
        }   
    }       
} 

[wryun]

My instinct is 'curses be upon all standard shell behaviour, I'm already a masochist if I'm using es', but if this will legitimately trip up users and it's easy to support then... sure?

FWIW, I also have a 'cd' which tracks the current directory, but doesn't require `pwd:

                let (current = <={
                    if {~ $dir /*} {
                        result
                    } {
                        %split / $cwd
                    }
                }) {
                    for (name = <={%split / $dir}) {
                        if {~ $name ..} {
                            if {!~ $#current 0} {
                                let (x = 1 $current) current = $x(2 ... $#current)
                            }
                        } {!~ $name . ''} {
                            current = $current $name
                        }
                    }
                    result / ^ <={ %flatten / $current }
                }

(snippet of my cd which also does other weird things; may or may not make sense on its own)

[jpco]

At the moment, I'm leaning towards just having a CAVEATS section in the man page to list common shell features that people might run into that are absent-by-default in es, and a for each one very short recommendation of how to add it to get people in the right direction. That could list both PWD and $status (which is already in the man page, but a pointer to update %interactive-loop and a recommendation not to change %batch-loop could be friendly.) Hypothetically this could be taken further by including links to a "library" of these online, or even distributing things in /usr/local/lib/es, but just starting with documentation sounds reasonable. What do folks think?