From unknown Wed Jun 18 00:24:51 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#59804 <59804@debbugs.gnu.org> To: bug#59804 <59804@debbugs.gnu.org> Subject: Status: shell-resync-dirs hangs in (t)csh Reply-To: bug#59804 <59804@debbugs.gnu.org> Date: Wed, 18 Jun 2025 07:24:51 +0000 retitle 59804 shell-resync-dirs hangs in (t)csh reassign 59804 emacs submitter 59804 Nicolas Graner severity 59804 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 03 06:37:26 2022 Received: (at submit) by debbugs.gnu.org; 3 Dec 2022 11:37:26 +0000 Received: from localhost ([127.0.0.1]:51611 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1Qph-0008Tq-QD for submit@debbugs.gnu.org; Sat, 03 Dec 2022 06:37:26 -0500 Received: from lists.gnu.org ([209.51.188.17]:35402) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1Qpe-0008Tk-9J for submit@debbugs.gnu.org; Sat, 03 Dec 2022 06:37:24 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p1Qpe-0004cg-4A for bug-gnu-emacs@gnu.org; Sat, 03 Dec 2022 06:37:22 -0500 Received: from ouvsmtp1.octopuce.fr ([194.36.166.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p1Qpa-0003dv-As for bug-gnu-emacs@gnu.org; Sat, 03 Dec 2022 06:37:21 -0500 Received: from panel.vitry.ouvaton.coop (unknown [194.36.166.20]) by ouvsmtp1.octopuce.fr (Postfix) with ESMTPS id A609115B for ; Sat, 3 Dec 2022 12:37:12 +0100 (CET) Received: from hypra-graner (212.246.204.77.rev.sfr.net [77.204.246.212]) by panel.vitry.ouvaton.coop (Postfix) with ESMTPSA id 40FF55E286B for ; Sat, 3 Dec 2022 12:37:12 +0100 (CET) From: Nicolas Graner To: bug-gnu-emacs@gnu.org Subject: shell-resync-dirs hangs in (t)csh Date: Sat, 03 Dec 2022 12:37:11 +0100 Message-ID: <87r0xghg60.fsf@graner.name> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=194.36.166.50; envelope-from=nicolas@graner.name; helo=ouvsmtp1.octopuce.fr X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) In a shell buffer where the running shell is csh or tcsh, the command shell-resync-dirs never returns. You can test this even without changing your normal shell by typing `csh' in any shell buffer, then M- Emacs hangs until you quit with C-g. The reason is that the `dirs' command in (t)csh (unlike its equivalent in bash) adds a trailing space to its output. This triggers an infinite loop. As evidence that the trailing space is the culprit, note that this kludge, whiche removes it, fixes the problem: (setq shell-dirstack-query "dirs | sed 's/ $//'") -- Nicolas From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 04 03:17:39 2022 Received: (at 59804) by debbugs.gnu.org; 4 Dec 2022 08:17:39 +0000 Received: from localhost ([127.0.0.1]:56155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1kBu-00007f-QM for submit@debbugs.gnu.org; Sun, 04 Dec 2022 03:17:39 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45266) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1kBt-00007Y-AJ for 59804@debbugs.gnu.org; Sun, 04 Dec 2022 03:17:37 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p1kBm-0001m4-S1; Sun, 04 Dec 2022 03:17:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=6EQfdbjGgpqfjC/1tccd6x0NKr6hNaf4j9NS90oDWhM=; b=G6NtgQX8IrYq +wUfCxCvFrZKp8aHPoqiifoS4BQh8y+vhvFPOVQWj+wC1WxxOjBWws9vaIM/2a+2Ka01Zk/oWnLet 0OTnKzrojUF+Jsp3qhyDq8wie5lR0dR0jKlRXJ2RjUzqyH4QgeccJ8OOfwD7CwPR947HwqsrGyiAO djaMhBvpl9nWd708T5aTGuDGMAN+hf7LoajijmEgiSNuUZ41vGp7qCff+6bjehzT9qllkVkcnUe3H EKDQyGiUH+2mBQC0aqX4C8MEusH7UxRWjyumTCrFIcsu5FacJkeFYsfAv9yiazB5oIMl0EbKpEVrV /YkcVvpLosKWVHqrEcvr/g==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p1kBm-0003Jd-B4; Sun, 04 Dec 2022 03:17:30 -0500 Date: Sun, 04 Dec 2022 10:17:10 +0200 Message-Id: <83r0xfbn21.fsf@gnu.org> From: Eli Zaretskii To: Nicolas Graner In-Reply-To: <87r0xghg60.fsf@graner.name> (message from Nicolas Graner on Sat, 03 Dec 2022 12:37:11 +0100) Subject: Re: bug#59804: shell-resync-dirs hangs in (t)csh References: <87r0xghg60.fsf@graner.name> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59804 Cc: 59804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Nicolas Graner > Date: Sat, 03 Dec 2022 12:37:11 +0100 > > In a shell buffer where the running shell is csh or tcsh, the command > shell-resync-dirs never returns. > > You can test this even without changing your normal shell by typing > `csh' in any shell buffer, then M- > Emacs hangs until you quit with C-g. > > The reason is that the `dirs' command in (t)csh (unlike its equivalent > in bash) adds a trailing space to its output. This triggers an infinite > loop. > > As evidence that the trailing space is the culprit, note that this > kludge, whiche removes it, fixes the problem: > > (setq shell-dirstack-query "dirs | sed 's/ $//'") Thanks for the analysis. Does the patch below fix this problem? If not, could you point out more precisely where the command infloops and why? diff --git a/lisp/shell.el b/lisp/shell.el index b396bc2..dadbdcb 100644 --- a/lisp/shell.el +++ b/lisp/shell.el @@ -1162,6 +1162,7 @@ shell-resync-dirs (dlsl nil) (pos 0) (ds nil)) + (setq dls (string-trim-right dls "[ ]+")) ;; Split the dirlist into whitespace and non-whitespace chunks. ;; dlsl will be a reversed list of tokens. (while (string-match "\\(\\S-+\\|\\s-+\\)" dls pos) From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 04 13:41:36 2022 Received: (at 59804) by debbugs.gnu.org; 4 Dec 2022 18:41:36 +0000 Received: from localhost ([127.0.0.1]:59134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1tvk-0007U9-2l for submit@debbugs.gnu.org; Sun, 04 Dec 2022 13:41:36 -0500 Received: from ouvsmtp1.octopuce.fr ([194.36.166.50]:41778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1tvf-0007U3-9a for 59804@debbugs.gnu.org; Sun, 04 Dec 2022 13:41:35 -0500 Received: from panel.vitry.ouvaton.coop (unknown [194.36.166.20]) by ouvsmtp1.octopuce.fr (Postfix) with ESMTPS id 93570F4F; Sun, 4 Dec 2022 19:41:29 +0100 (CET) Received: from hypra-graner (95.106.204.77.rev.sfr.net [77.204.106.95]) by panel.vitry.ouvaton.coop (Postfix) with ESMTPSA id 12DF25E28E2; Sun, 4 Dec 2022 19:41:29 +0100 (CET) From: Nicolas Graner To: Eli Zaretskii Subject: Re: bug#59804: shell-resync-dirs hangs in (t)csh In-Reply-To: <83r0xfbn21.fsf@gnu.org> (message from Eli Zaretskii on Sun, 04 Dec 2022 10:17:10 +0200) Date: Sun, 04 Dec 2022 19:41:24 +0100 Message-ID: <87y1rnggff.fsf@graner.name> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 59804 Cc: 59804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii wrote on 2022-12-04 10:17: >> From: Nicolas Graner >> Date: Sat, 03 Dec 2022 12:37:11 +0100 >> >> In a shell buffer where the running shell is csh or tcsh, the command >> shell-resync-dirs never returns. >> >> You can test this even without changing your normal shell by typing >> `csh' in any shell buffer, then M- >> Emacs hangs until you quit with C-g. >> >> The reason is that the `dirs' command in (t)csh (unlike its equivalent >> in bash) adds a trailing space to its output. This triggers an infinite >> loop. >> >> As evidence that the trailing space is the culprit, note that this >> kludge, whiche removes it, fixes the problem: >> >> (setq shell-dirstack-query "dirs | sed 's/ $//'") > > Thanks for the analysis. Does the patch below fix this problem? If not, > could you point out more precisely where the command infloops and why? > > diff --git a/lisp/shell.el b/lisp/shell.el > index b396bc2..dadbdcb 100644 > --- a/lisp/shell.el > +++ b/lisp/shell.el > @@ -1162,6 +1162,7 @@ shell-resync-dirs > (dlsl nil) > (pos 0) > (ds nil)) > + (setq dls (string-trim-right dls "[ ]+")) > ;; Split the dirlist into whitespace and non-whitespace chunks. > ;; dlsl will be a reversed list of tokens. > (while (string-match "\\(\\S-+\\|\\s-+\\)" dls pos) It works in most situations, but not if a directory name actually ends with a space. Upon further investigation, I found there are two distinct issues here. 1) When the dirs command prints "foo ", there is no way to tell if the directory is named "foo" and the shell (e.g. csh) added a trailing space, or the directory is named "foo " and the shell (e.g. bash) printed it unchanged. There may even be more than one trailing space. The only clean solution I can think of is to introduce a new shell-dependent variable, similar to shell-dirstack-query, say shell-dirstack-query-suffix, which would be " " for csh and tcsh, and "" for most other shells. Your patch above would become: (setq dls (string-trim-right dls shell-dirstack-query-suffix)) 2) the loop that goes wild, later in the same function, starts with: (while newelt It tries to construct an existing directory name by concatenating tokens from the output of dirs, starting from the last. It runs indefinitely if this doesn't yield a valid directory name. This can happen for several reasons: an extra space at the end as discussed above, a non-printable character in a directory name, a directory that was deleted after being pushed onto the dirstack, and maybe more. This can happen in any shell, not just csh. This loop should therefore be fixed, regardless of the trailing space issue. The following patch fixes the bug by ensuring the loop terminates in all cases, but I am not sure it always does the right thing when no directory name is found. It should be reviewed by someone who understands the code better than me. diff --git a/lisp/shell.el b/lisp/shell.el index b396bc2b180..abeaba04ab4 100644 --- a/lisp/shell.el +++ b/lisp/shell.el @@ -1173,7 +1173,7 @@ shell-resync-dirs (while dlsl (let ((newelt "") tem1 tem2) - (while newelt + (while (and newelt dlsl) ;; We need tem1 because we don't want to prepend ;; `comint-file-name-prefix' repeatedly into newelt via tem2. (setq tem1 (pop dlsl) From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 04 14:16:00 2022 Received: (at 59804) by debbugs.gnu.org; 4 Dec 2022 19:16:00 +0000 Received: from localhost ([127.0.0.1]:59276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1uT1-0007o3-PG for submit@debbugs.gnu.org; Sun, 04 Dec 2022 14:16:00 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58908) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p1uSx-0007nx-Bg for 59804@debbugs.gnu.org; Sun, 04 Dec 2022 14:15:58 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p1uSo-00031O-DQ; Sun, 04 Dec 2022 14:15:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=aY63Tpr9ULpeSLXabKmLl7YgOwxY0l1p5tbtT9h6HSc=; b=RDOn8TeWVIel STQdFR4m3tqPLn8Ms590t4z572Im3YQR79HnQDltCNDjk28CK5AdKtUryatqgxqDQ+viLzt0HYS2x /u8YcD0PYheajkEPRmrZYfXdSx7kJwJmC76QdL/PuepiTGGjIS13nMDPPf+ufEr0+kYu4DsNRNPZR ypLimMcHXO/2rR4qgFjEps11UVi43BloLJMmWLf7e8i6v4KoSnM22SEYxjRS1YJfD9K6OFqJQrLgK VrfU0nv9fTjO+7Q+Qp7GEeSUJcUQFiFGpBitL8WdbdvaYxXkWk8z6ttsldOtHsa/usSM/XE6vFW4/ 82kB21igZGtop7gFmzfRjg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p1uSn-0004op-NR; Sun, 04 Dec 2022 14:15:46 -0500 Date: Sun, 04 Dec 2022 21:15:27 +0200 Message-Id: <83cz8z9e0g.fsf@gnu.org> From: Eli Zaretskii To: Nicolas Graner In-Reply-To: <87y1rnggff.fsf@graner.name> (message from Nicolas Graner on Sun, 04 Dec 2022 19:41:24 +0100) Subject: Re: bug#59804: shell-resync-dirs hangs in (t)csh References: <87y1rnggff.fsf@graner.name> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59804 Cc: 59804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Nicolas Graner > Cc: 59804@debbugs.gnu.org > Date: Sun, 04 Dec 2022 19:41:24 +0100 > > > --- a/lisp/shell.el > > +++ b/lisp/shell.el > > @@ -1162,6 +1162,7 @@ shell-resync-dirs > > (dlsl nil) > > (pos 0) > > (ds nil)) > > + (setq dls (string-trim-right dls "[ ]+")) > > ;; Split the dirlist into whitespace and non-whitespace chunks. > > ;; dlsl will be a reversed list of tokens. > > (while (string-match "\\(\\S-+\\|\\s-+\\)" dls pos) > > It works in most situations, but not if a directory name actually ends > with a space. > Upon further investigation, I found there are two distinct issues here. > > 1) When the dirs command prints "foo ", there is no way to tell if the > directory is named "foo" and the shell (e.g. csh) added a trailing > space, or the directory is named "foo " and the shell (e.g. bash) > printed it unchanged. There may even be more than one trailing space. > > The only clean solution I can think of is to introduce a new > shell-dependent variable, similar to shell-dirstack-query, say > shell-dirstack-query-suffix, which would be " " for csh and tcsh, and "" > for most other shells. Your patch above would become: > > (setq dls (string-trim-right dls shell-dirstack-query-suffix)) Is it certain that csh/tcsh always add just one space? If so, we could simply remove that one space in the case of these two shells. > The following patch fixes the bug by ensuring the loop terminates in all > cases, but I am not sure it always does the right thing when no > directory name is found. It should be reviewed by someone who > understands the code better than me. OK, thanks. I think I'd prefer for now to fix just the trailing space part, which AFAIU happens always, and leave the more exotic situations as a FIXME comment, or maybe I will make the change you propose on the master branch. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 10 07:57:32 2022 Received: (at 59804) by debbugs.gnu.org; 10 Dec 2022 12:57:32 +0000 Received: from localhost ([127.0.0.1]:42614 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3zQ4-0004Gb-9N for submit@debbugs.gnu.org; Sat, 10 Dec 2022 07:57:32 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39088) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3zQ2-0004GR-Ju for 59804@debbugs.gnu.org; Sat, 10 Dec 2022 07:57:30 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p3zPx-0001DB-Aq; Sat, 10 Dec 2022 07:57:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=mbbI88i7vNIc5qhZMI1GqDb95uNFn/DWIt20yYVY8QU=; b=eZlB/hPZDCqs zJrwuYHhUfPlgHgOdgVZdWc+JBA9LWVN4jVqQxD5JAne+FDaFjPxpLRJ69UXc0HTOBFsU1pcdixBN Cyync1afHESz1E7OOJZ/l6xpuHvNsJ0QsGorTYQQqJC2jQotAWc/44SSkhH+uHmKAMaOzhmZd1ADU 9cHjDGpxgTBb5uTb2XyVUdAVyZgZ7OZE2Zl091gPL0ZJwBuwWFTJkBAefxClxaY1zu5indBeM3Wo7 o5DPknWgH2SwmPg/KmoWtf5wyFFeWIWrCiu6ulyuE3kW5GAnuOV089q4u++obbTbuWrJ8Tzi3gOqM cmmlD2y8p/1MMtEvsyXzuQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p3zPw-0002a5-KM; Sat, 10 Dec 2022 07:57:24 -0500 Date: Sat, 10 Dec 2022 14:57:20 +0200 Message-Id: <83359nxvpr.fsf@gnu.org> From: Eli Zaretskii To: nicolas@graner.name In-Reply-To: <83cz8z9e0g.fsf@gnu.org> (message from Eli Zaretskii on Sun, 04 Dec 2022 21:15:27 +0200) Subject: Re: bug#59804: shell-resync-dirs hangs in (t)csh References: <87y1rnggff.fsf@graner.name> <83cz8z9e0g.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59804 Cc: 59804@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 59804@debbugs.gnu.org > Date: Sun, 04 Dec 2022 21:15:27 +0200 > From: Eli Zaretskii > > > The following patch fixes the bug by ensuring the loop terminates in all > > cases, but I am not sure it always does the right thing when no > > directory name is found. It should be reviewed by someone who > > understands the code better than me. > > OK, thanks. I think I'd prefer for now to fix just the trailing space part, > which AFAIU happens always, and leave the more exotic situations as a FIXME > comment, or maybe I will make the change you propose on the master branch. I've now installed the simple patch I suggested. I'm leaving the bug open because the rest of the issue you describe has yet to be solved, probably by someone who knows more about "dirs" in various shells than I do. Thanks.