bug#74524: 29.4; dirtrack-mode

bug#74524: 29.4; dirtrack-mode

[Colton Goates]

[-- Attachment #1: Type: text/plain, Size: 3397 bytes --]

In a shell, running a command like the following causes a problem with
dirtrack-mode:

    echo 'Coltons-MacBook-Pro:/Users/coltongoates/software-dev/$'

After running this command, dirtrack thinks I changed to a different
directory based on the output, and it sets the default-directory
variable to the output of the echo command. Thus, the actual working
directory and shell directory are out of sync.

In GNU Emacs 29.4 (build 1, x86_64-apple-darwin23.4.0) of 2024-10-04
built on Sonoma
System Description:  macOS 15.1.1

Configured using:
'configure --disable-silent-rules
--enable-locallisppath=/usr/local/share/emacs/site-lisp
--infodir=/usr/local/Cellar/emacs/29.4_1/share/info/emacs
--prefix=/usr/local/Cellar/emacs/29.4_1 --with-gnutls --without-x
--with-xml2 --without-dbus --with-modules --without-ns
--without-imagemagick --without-selinux --with-tree-sitter'

Configured features:
ACL GMP GNUTLS JSON LIBXML2 MODULES NOTIFY KQUEUE PDUMPER SQLITE3
THREADS TREE_SITTER ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Shell

Minor modes in effect:
  dirtrack-debug-mode: t
  dirtrack-mode: t
  comint-fontify-input-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dnd dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils pp
cl-print cl-extra mode-local find-func thingatpt help-fns radix-tree
help-mode tool-bar misearch multi-isearch vc-git diff-mode easy-mmode
vc-dispatcher pcmpl-unix sh-script rx smie treesit cl-seq cl-loaddefs
cl-lib executable dirtrack files-x shell subr-x pcomplete comint
regexp-opt ansi-osc ansi-color ring term/xterm xterm byte-opt gv
bytecomp byte-compile ls-lisp mwheel rmc iso-transl tooltip cconv eldoc
paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select mouse
jit-lock font-lock syntax font-core term/tty-colors frame minibuffer
nadvice seq simple cl-generic indonesian philippine cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads kqueue multi-tty make-network-process emacs)

Memory information:
((conses 16 80404 8799)
(symbols 48 8210 0)
(strings 32 27749 1825)
(string-bytes 1 749593)
(vectors 16 14814)
(vector-slots 8 174891 10453)
(floats 8 40 600)
(intervals 56 668 0)
(buffers 984 17))

[-- Attachment #2: Type: text/html, Size: 3718 bytes --]

bug#74524: 29.4; dirtrack-mode

[Eli Zaretskii]

> From: Colton Goates <coltongoates@gmail.com>
> Date: Sun, 24 Nov 2024 20:55:37 -0700
> 
> In a shell, running a command like the following causes a problem with dirtrack-mode:
> 
>     echo 'Coltons-MacBook-Pro:/Users/coltongoates/software-dev/$'
> 
> After running this command, dirtrack thinks I changed to a different
> directory based on the output, and it sets the default-directory
> variable to the output of the echo command. Thus, the actual working
> directory and shell directory are out of sync.

Isn't that because the colon in this (unusual) directory name?  If so,
you could perhaps customize the regexp in dirtrack-list to solve this?

bug#74524: 29.4; dirtrack-mode

[Colton Goates]

[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]

Coltons-MacBook-Pro:/Users/coltongoates/software-dev/$ isn't intended to be
a directory name, it's a string that's intended to look exactly like my
prompt. (I know it's pretty contrived.)

So, if someone prints something that resembles their prompt, dirtrack will
change the directory, because dirtrack thinks it just saw the shell prompt
appear, but it really just saw a string that resembles the prompt. Does
that make more sense now?

On Mon, Nov 25, 2024 at 5:38 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Colton Goates <coltongoates@gmail.com>
> > Date: Sun, 24 Nov 2024 20:55:37 -0700
> >
> > In a shell, running a command like the following causes a problem with
> dirtrack-mode:
> >
> >     echo 'Coltons-MacBook-Pro:/Users/coltongoates/software-dev/$'
> >
> > After running this command, dirtrack thinks I changed to a different
> > directory based on the output, and it sets the default-directory
> > variable to the output of the echo command. Thus, the actual working
> > directory and shell directory are out of sync.
>
> Isn't that because the colon in this (unusual) directory name?  If so,
> you could perhaps customize the regexp in dirtrack-list to solve this?
>

[-- Attachment #2: Type: text/html, Size: 1715 bytes --]

bug#74524: 29.4; dirtrack-mode

[Eli Zaretskii]

> From: Colton Goates <coltongoates@gmail.com>
> Date: Mon, 25 Nov 2024 10:27:00 -0700
> Cc: 74524@debbugs.gnu.org
> 
> Coltons-MacBook-Pro:/Users/coltongoates/software-dev/$ isn't intended to be a directory name, it's a string
> that's intended to look exactly like my prompt. (I know it's pretty contrived.) 
> 
> So, if someone prints something that resembles their prompt, dirtrack will change the directory, because
> dirtrack thinks it just saw the shell prompt appear, but it really just saw a string that resembles the prompt.
> Does that make more sense now?

What do you expect dirtrack to do when you deliberately try to deceive
it?  AFAIU, dirtrack is a piece of heuristic ad-hocery (as explained
in its commentary), so it cannot be expected to survive such
deception.  What kind of changes would you suggest to consider to
handle the cases such as this one?

bug#74524: 29.4; dirtrack-mode

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

If you're using a shell that can support the following ansi osc 7 escape
sequence excerpt I took from my bashrc, just disable dirtrack via
(shell-dirtrack-mode -1).

function myprompt () {
  printf "\e]7;file://%s%s\e\\" "$HOSTNAME" "$PWD"
}

# Do these only if we're in an interactive shell
case $- in
*i*)
# ...snip...
  export PROMPT_COMMAND=myprompt

On Mon, Nov 25, 2024 at 1:56 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Colton Goates <coltongoates@gmail.com>
> > Date: Mon, 25 Nov 2024 10:27:00 -0700
> > Cc: 74524@debbugs.gnu.org
> >
> > Coltons-MacBook-Pro:/Users/coltongoates/software-dev/$ isn't intended to
> be a directory name, it's a string
> > that's intended to look exactly like my prompt. (I know it's pretty
> contrived.)
> >
> > So, if someone prints something that resembles their prompt, dirtrack
> will change the directory, because
> > dirtrack thinks it just saw the shell prompt appear, but it really just
> saw a string that resembles the prompt.
> > Does that make more sense now?
>
> What do you expect dirtrack to do when you deliberately try to deceive
> it?  AFAIU, dirtrack is a piece of heuristic ad-hocery (as explained
> in its commentary), so it cannot be expected to survive such
> deception.  What kind of changes would you suggest to consider to
> handle the cases such as this one?
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2159 bytes --]

bug#74524: 29.4; dirtrack-mode

[Colton Goates]

[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]

I did what Ship Mints suggested, and it didn't work on my macbook i.e. no
directory tracking is happening. I checked directory tracking via the
`default-directory` variable and it did not change in response to cd
commands. I made sure to restart emacs to ensure that everything got
loaded. I have Emacs 29.4 (installed with brew) and I'm running macOS
Sequoia 15.1.1. See below for my configuration:

Here is my .bashrc:



*function myprompt () {  printf "\e]7;file://%s%s\e\\" "$HOSTNAME"
"$PWD"}export PROMPT_COMMAND=myprompt*

And I added this to my init.el
*(add-hook 'comint-output-filter-functions #'comint-osc-process-output)*

Does anyone have debugging tips?

On Mon, Nov 25, 2024 at 12:08 PM Ship Mints <shipmints@gmail.com> wrote:

> If you're using a shell that can support the following ansi osc 7 escape
> sequence excerpt I took from my bashrc, just disable dirtrack via
> (shell-dirtrack-mode -1).
>
> function myprompt () {
>   printf "\e]7;file://%s%s\e\\" "$HOSTNAME" "$PWD"
> }
>
> # Do these only if we're in an interactive shell
> case $- in
> *i*)
> # ...snip...
>   export PROMPT_COMMAND=myprompt
>
> On Mon, Nov 25, 2024 at 1:56 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: Colton Goates <coltongoates@gmail.com>
>> > Date: Mon, 25 Nov 2024 10:27:00 -0700
>> > Cc: 74524@debbugs.gnu.org
>> >
>> > Coltons-MacBook-Pro:/Users/coltongoates/software-dev/$ isn't intended
>> to be a directory name, it's a string
>> > that's intended to look exactly like my prompt. (I know it's pretty
>> contrived.)
>> >
>> > So, if someone prints something that resembles their prompt, dirtrack
>> will change the directory, because
>> > dirtrack thinks it just saw the shell prompt appear, but it really just
>> saw a string that resembles the prompt.
>> > Does that make more sense now?
>>
>> What do you expect dirtrack to do when you deliberately try to deceive
>> it?  AFAIU, dirtrack is a piece of heuristic ad-hocery (as explained
>> in its commentary), so it cannot be expected to survive such
>> deception.  What kind of changes would you suggest to consider to
>> handle the cases such as this one?
>>
>>
>>
>>

[-- Attachment #2: Type: text/html, Size: 3439 bytes --]

bug#74524: 29.4; dirtrack-mode

[Colton Goates]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

I don't know how dirtrack would tell the difference between a prompt output
and other printed output. I just thought of the edge case and decided to
point it out in case someone knew of a solution. Thanks for responding.

On Mon, Nov 25, 2024 at 11:55 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Colton Goates <coltongoates@gmail.com>
> > Date: Mon, 25 Nov 2024 10:27:00 -0700
> > Cc: 74524@debbugs.gnu.org
> >
> > Coltons-MacBook-Pro:/Users/coltongoates/software-dev/$ isn't intended to
> be a directory name, it's a string
> > that's intended to look exactly like my prompt. (I know it's pretty
> contrived.)
> >
> > So, if someone prints something that resembles their prompt, dirtrack
> will change the directory, because
> > dirtrack thinks it just saw the shell prompt appear, but it really just
> saw a string that resembles the prompt.
> > Does that make more sense now?
>
> What do you expect dirtrack to do when you deliberately try to deceive
> it?  AFAIU, dirtrack is a piece of heuristic ad-hocery (as explained
> in its commentary), so it cannot be expected to survive such
> deception.  What kind of changes would you suggest to consider to
> handle the cases such as this one?
>

[-- Attachment #2: Type: text/html, Size: 1698 bytes --]

bug#74524: 29.4; dirtrack-mode

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]

Check that your default shell supports the function. I understand later
macOS defaults to zsh which I have no experience with. I use macOS but I
default my shell to bash. If you have an alternate terminal like
Wezterm you could verify your shell settings there
https://wezfurlong.org/wezterm/shell-integration.html#osc-7-escape-sequence-to-set-the-working-directory

As far as your osc filter goes, I think it would be better to install it
buffer-locally in a shell-mode-hook so you don't interfere with other
comint uses.

  (defun my/shell-mode-hook ()
    (shell-dirtrack-mode -1)
    (add-hook 'comint-output-filter-functions #'comint-osc-process-output
nil 'local))
  (add-hook 'shell-mode-hook #'my/shell-mode-hook)

On Tue, Nov 26, 2024 at 3:16 AM Colton Goates <coltongoates@gmail.com>
wrote:

> I don't know how dirtrack would tell the difference between a prompt
> output and other printed output. I just thought of the edge case and
> decided to point it out in case someone knew of a solution. Thanks for
> responding.
>
> On Mon, Nov 25, 2024 at 11:55 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: Colton Goates <coltongoates@gmail.com>
>> > Date: Mon, 25 Nov 2024 10:27:00 -0700
>> > Cc: 74524@debbugs.gnu.org
>> >
>> > Coltons-MacBook-Pro:/Users/coltongoates/software-dev/$ isn't intended
>> to be a directory name, it's a string
>> > that's intended to look exactly like my prompt. (I know it's pretty
>> contrived.)
>> >
>> > So, if someone prints something that resembles their prompt, dirtrack
>> will change the directory, because
>> > dirtrack thinks it just saw the shell prompt appear, but it really just
>> saw a string that resembles the prompt.
>> > Does that make more sense now?
>>
>> What do you expect dirtrack to do when you deliberately try to deceive
>> it?  AFAIU, dirtrack is a piece of heuristic ad-hocery (as explained
>> in its commentary), so it cannot be expected to survive such
>> deception.  What kind of changes would you suggest to consider to
>> handle the cases such as this one?
>>
>

[-- Attachment #2: Type: text/html, Size: 3342 bytes --]

bug#74524: 29.4; dirtrack-mode

[Colton Goates]

[-- Attachment #1: Type: text/plain, Size: 2377 bytes --]

I also default my shell to bash. I might look into wezterm to see if I can
get it working with that one. Thanks for the tip about buffer local

On Tue, Nov 26, 2024 at 7:00 AM Ship Mints <shipmints@gmail.com> wrote:

> Check that your default shell supports the function. I understand later
> macOS defaults to zsh which I have no experience with. I use macOS but I
> default my shell to bash. If you have an alternate terminal like
> Wezterm you could verify your shell settings there
> https://wezfurlong.org/wezterm/shell-integration.html#osc-7-escape-sequence-to-set-the-working-directory
>
> As far as your osc filter goes, I think it would be better to install it
> buffer-locally in a shell-mode-hook so you don't interfere with other
> comint uses.
>
>   (defun my/shell-mode-hook ()
>     (shell-dirtrack-mode -1)
>     (add-hook 'comint-output-filter-functions #'comint-osc-process-output
> nil 'local))
>   (add-hook 'shell-mode-hook #'my/shell-mode-hook)
>
> On Tue, Nov 26, 2024 at 3:16 AM Colton Goates <coltongoates@gmail.com>
> wrote:
>
>> I don't know how dirtrack would tell the difference between a prompt
>> output and other printed output. I just thought of the edge case and
>> decided to point it out in case someone knew of a solution. Thanks for
>> responding.
>>
>> On Mon, Nov 25, 2024 at 11:55 AM Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>> > From: Colton Goates <coltongoates@gmail.com>
>>> > Date: Mon, 25 Nov 2024 10:27:00 -0700
>>> > Cc: 74524@debbugs.gnu.org
>>> >
>>> > Coltons-MacBook-Pro:/Users/coltongoates/software-dev/$ isn't intended
>>> to be a directory name, it's a string
>>> > that's intended to look exactly like my prompt. (I know it's pretty
>>> contrived.)
>>> >
>>> > So, if someone prints something that resembles their prompt, dirtrack
>>> will change the directory, because
>>> > dirtrack thinks it just saw the shell prompt appear, but it really
>>> just saw a string that resembles the prompt.
>>> > Does that make more sense now?
>>>
>>> What do you expect dirtrack to do when you deliberately try to deceive
>>> it?  AFAIU, dirtrack is a piece of heuristic ad-hocery (as explained
>>> in its commentary), so it cannot be expected to survive such
>>> deception.  What kind of changes would you suggest to consider to
>>> handle the cases such as this one?
>>>
>>

[-- Attachment #2: Type: text/html, Size: 3876 bytes --]

bug#74524: 29.4; dirtrack-mode

[Eli Zaretskii]

> From: Colton Goates <coltongoates@gmail.com>
> Date: Mon, 25 Nov 2024 19:11:03 -0700
> Cc: 74524@debbugs.gnu.org
> 
> I don't know how dirtrack would tell the difference between a prompt output and other printed output. I just
> thought of the edge case and decided to point it out in case someone knew of a solution. Thanks for
> responding.

Thanks, understood.

Does anyone see a way to overcome these situations?

bug#74524: 29.4; dirtrack-mode

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

You can customize dirtrack-list to a regexp that can detect your prompt
format. I'd still recommend using osc 7 support, though, as it's precise
(once you get it working) and tracking pushd popd cd, parsing your prompt,
etc. is not necessary.

On Tue, Nov 26, 2024 at 3:16 AM Colton Goates <coltongoates@gmail.com>
wrote:

> I don't know how dirtrack would tell the difference between a prompt
> output and other printed output. I just thought of the edge case and
> decided to point it out in case someone knew of a solution. Thanks for
> responding.
>
> On Mon, Nov 25, 2024 at 11:55 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: Colton Goates <coltongoates@gmail.com>
>> > Date: Mon, 25 Nov 2024 10:27:00 -0700
>> > Cc: 74524@debbugs.gnu.org
>> >
>> > Coltons-MacBook-Pro:/Users/coltongoates/software-dev/$ isn't intended
>> to be a directory name, it's a string
>> > that's intended to look exactly like my prompt. (I know it's pretty
>> contrived.)
>> >
>> > So, if someone prints something that resembles their prompt, dirtrack
>> will change the directory, because
>> > dirtrack thinks it just saw the shell prompt appear, but it really just
>> saw a string that resembles the prompt.
>> > Does that make more sense now?
>>
>> What do you expect dirtrack to do when you deliberately try to deceive
>> it?  AFAIU, dirtrack is a piece of heuristic ad-hocery (as explained
>> in its commentary), so it cannot be expected to survive such
>> deception.  What kind of changes would you suggest to consider to
>> handle the cases such as this one?
>>
>

[-- Attachment #2: Type: text/html, Size: 2394 bytes --]

bug#74524: 29.4; dirtrack-mode

[Colton Goates]

[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]

I was referring to the bizarre edge case of a printed edge case that
matches your regex. In that case, it will confuse the two. But like you
said, OS7 is the way to go. I'll just try to get it working

On Tue, Nov 26, 2024 at 7:46 AM Ship Mints <shipmints@gmail.com> wrote:

> You can customize dirtrack-list to a regexp that can detect your prompt
> format. I'd still recommend using osc 7 support, though, as it's precise
> (once you get it working) and tracking pushd popd cd, parsing your prompt,
> etc. is not necessary.
>
> On Tue, Nov 26, 2024 at 3:16 AM Colton Goates <coltongoates@gmail.com>
> wrote:
>
>> I don't know how dirtrack would tell the difference between a prompt
>> output and other printed output. I just thought of the edge case and
>> decided to point it out in case someone knew of a solution. Thanks for
>> responding.
>>
>> On Mon, Nov 25, 2024 at 11:55 AM Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>> > From: Colton Goates <coltongoates@gmail.com>
>>> > Date: Mon, 25 Nov 2024 10:27:00 -0700
>>> > Cc: 74524@debbugs.gnu.org
>>> >
>>> > Coltons-MacBook-Pro:/Users/coltongoates/software-dev/$ isn't intended
>>> to be a directory name, it's a string
>>> > that's intended to look exactly like my prompt. (I know it's pretty
>>> contrived.)
>>> >
>>> > So, if someone prints something that resembles their prompt, dirtrack
>>> will change the directory, because
>>> > dirtrack thinks it just saw the shell prompt appear, but it really
>>> just saw a string that resembles the prompt.
>>> > Does that make more sense now?
>>>
>>> What do you expect dirtrack to do when you deliberately try to deceive
>>> it?  AFAIU, dirtrack is a piece of heuristic ad-hocery (as explained
>>> in its commentary), so it cannot be expected to survive such
>>> deception.  What kind of changes would you suggest to consider to
>>> handle the cases such as this one?
>>>
>>

[-- Attachment #2: Type: text/html, Size: 2975 bytes --]