With 5.9: 1 % cd /tmp 2 % PS1='%~%# ' 3 /tmp% mkdir foo foo/bar 4 /tmp% cd foo/bar 5 /tmp/foo/bar% rm -rf /tmp/foo 6 /tmp/foo/bar% cd .. 7 /tmp/foo/bar% cd .. 8 /tmp% The prompts on lines 6 and 7 are wrong. Ideally I'd like to see some indication that cwd has been deleted, or that a path to cwd couldn't be determined, etc.. Definitely not some apprently-valid path that points to something else than cwd. Cheers, Daniel (who hasn't forgotten about the widgets shadowing docs thread)
> On 08 June 2022 at 10:14 Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
>
> With 5.9:
>
> 1 % cd /tmp
> 2 % PS1='%~%# '
> 3 /tmp% mkdir foo foo/bar
> 4 /tmp% cd foo/bar
> 5 /tmp/foo/bar% rm -rf /tmp/foo
> 6 /tmp/foo/bar% cd ..
> 7 /tmp/foo/bar% cd ..
> 8 /tmp%
>
> The prompts on lines 6 and 7 are wrong.
>
> Ideally I'd like to see some indication that cwd has been deleted, or
> that a path to cwd couldn't be determined, etc.. Definitely not some
> apprently-valid path that points to something else than cwd.
It looks like prompts currently just passively look at the internal pwd
variable, so make no kind of checks of the environment of any sort.
Presumably a getcwd() is needed each time the prompt is updated.
We also need to decide how to signal this.
However, it looks like this has wider ramifications as it appears
"pwd" and "pwd -P" both just shrug their shoulders and return
the last known current directory in this case. For both, bash gives
the more logical
pwd: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
pws
On Wed, Jun 8, 2022 at 2:42 AM Peter Stephenson <p.w.stephenson@ntlworld.com> wrote: > > > On 08 June 2022 at 10:14 Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > > > With 5.9: With any version of zsh ever, really. > > Ideally I'd like to see some indication that cwd has been deleted, or > > that a path to cwd couldn't be determined, etc.. IMO this happens so seldom that doing it before every prompt as a shell default just seems like a huge waste of time, especially if (say) the current directory is on a networked file system and there may be a significant delay checking it. If you're doing this to yourself often enough to notice, put something in your precmd hooks to discover it. > It looks like prompts currently just passively look at the internal pwd > variable, so make no kind of checks of the environment of any sort. Intentionally so ... > However, it looks like this has wider ramifications as it appears > "pwd" and "pwd -P" both just shrug their shoulders and return > the last known current directory in this case. /* * Try to find the current directory. * If we couldn't work it out internally, fall back to getcwd(). * If it fails, fall back to pwd; if zgetcwd() is being used * to set pwd, pwd should be NULL and we just return ".". */ As of workers/50287, we always fall back to getcwd() rather than "work it out internally", so some of the foregoing may have subtly changed.
On Wed, Jun 8, 2022 at 9:15 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> If you're doing this to
> yourself often enough to notice, put something in your precmd hooks to
> discover it.
SGI IRIX (y'all have seen Jurassic Park, ya?) had this thing called
FAM, the File Access Monitor. Here's a really dumb version of that.
# --- 8< --- zFAM
# Example Usage
# coproc zFAM
# chpwd() { pwd -P >&p }
# precmd() { read -t 0 -p && print -ru2 -- $REPLY not readable }
typeset filename
read filename # Wait forever for first file to monitor
while [[ -n $filename ]]
do
if [[ -r $filename ]]
then
read -t 1 filename
else
print -r -- $filename
read filename
fi
done
# --- >8 ---