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

[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 --]