Subject: Re: [PATCH] Re: bug#79441: shell-resync-dirs breaks on PS1 with newline

From: Eli Zaretskii <[email-masked]>
Date: Sun, 14 Sep 2025 09:08:42 +0300

> From: Janneke Nieuwenhuizen <[email-masked]>
> Cc: [email-masked]
> Date: Sat, 13 Sep 2025 17:01:45 +0200
> 
> > Can you suggest how to solve this?
> 
> Good question!  When I tried to add (message ...) debugging this
> morning, it started (and kept) looping; so I had no idea how to proceed.
> However, I tried again and got better results this time and have created
> a patch that "works for me" (see attached).
> 
> The puzzle is that I don't know all the requirements, e.g., I have no
> idea why the code was (blindly) using `last' to set `dsl' from the
> shell-dirtrack-query's result, and only much later using
> file-directory-p.
> 
> The code using `last' suggests to me that there could me more (partial?)
> directory-like elements coming back from `shell-dirtrack-query' and that
> in such a case, that I haven't oberved, the last must be the most
> relevant?
> 
> Also, the nested while loops lateron with the concatenations suggest
> that `shell-dirtrack-query' may not always return the needed directory
> element as one string, but that it could be split up in parts that would
> need to be concatenated?  Also, something that I didn't observe.

Yes, these all can happen.  I think if you use "git log -L" to show
changes in the relevant portions of the code, you will find bug
reports that describe those cases.

> So, I've changed the code to prefer `seq-find' with `file-directory-p'
> and reverse the list first, so that the last element remains the most
> relevant.  Also, I've kept selecting the last element in case the
> `seq-find' does not return a result.
> 
> Anyway, naively looking at my case only, it seems the code could be a
> lot simpler, using just the `seq-find' and without the nested `while'
> loops...so yeah, dunno ;)

Thanks.  However, if it doesn't handle the case of receiving a partial
directory from the shell, it will cause regressions.