From: David Bremner Date: Sat, 2 Mar 2013 18:50:19 +0000 (+2000) Subject: Re: [BUG] inconsistent user context handling w/ tramp X-Git-Url: http://git.tremily.us/gitweb.cgi?a=commitdiff_plain;h=f599699dbc21b93b533be9eeaf8ceb68fa2aaac1;p=notmuch-archives.git Re: [BUG] inconsistent user context handling w/ tramp --- diff --git a/6a/15a6beb0d053c4090bc2d3b78793227a00f5d6 b/6a/15a6beb0d053c4090bc2d3b78793227a00f5d6 new file mode 100644 index 000000000..1c294b446 --- /dev/null +++ b/6a/15a6beb0d053c4090bc2d3b78793227a00f5d6 @@ -0,0 +1,107 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 7CB13431FAF + for ; Sat, 2 Mar 2013 10:50:28 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0 +X-Spam-Level: +X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id i9+PcW56R5H0 for ; + Sat, 2 Mar 2013 10:50:28 -0800 (PST) +Received: from tesseract.cs.unb.ca (tesseract.cs.unb.ca [131.202.240.238]) + (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id E7B5F431FAE + for ; Sat, 2 Mar 2013 10:50:27 -0800 (PST) +Received: from fctnnbsc30w-156034082078.dhcp-dynamic.fibreop.nb.bellaliant.net + ([156.34.82.78] helo=zancas.localnet) + by tesseract.cs.unb.ca with esmtpsa + (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) + (envelope-from ) + id 1UBrVp-0008Lz-8K; Sat, 02 Mar 2013 14:50:26 -0400 +Received: from bremner by zancas.localnet with local (Exim 4.80) + (envelope-from ) + id 1UBrVj-0002Ql-GI; Sat, 02 Mar 2013 14:50:19 -0400 +From: David Bremner +To: Simon Campese , notmuch@notmuchmail.org +Subject: Re: [BUG] inconsistent user context handling w/ tramp +In-Reply-To: <874nguxbvq.fsf@tu-dortmund.de> +References: <874nguxbvq.fsf@tu-dortmund.de> +User-Agent: Notmuch/0.15.2+32~g16aa65b (http://notmuchmail.org) Emacs/24.2.1 + (x86_64-pc-linux-gnu) +Date: Sat, 02 Mar 2013 14:50:19 -0400 +Message-ID: <87sj4d63h0.fsf@zancas.localnet> +MIME-Version: 1.0 +Content-Type: text/plain +X-Spam_bar: - +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Sat, 02 Mar 2013 18:50:28 -0000 + +Simon Campese writes: + +> Hello, +> +> after using tramp to open a file using the 'su' or 'sudo' protocol as +> user X, the next time I run 'compose-mail' to compose a message it +> apparently looks in the home directory of user X for its config file, +> mail directory etc. In the compose window, I get the error message +> +> 'Error reading configuration file $X_homedir/.notmuch-config: No such +> file or directory' +> +> in all header fields (From, Fcc etc.) that should be filled by notmuch +> ($X_homedir is the home directory of user X from above). +> + +I don't think this is specific to notmuch. Notmuch uses the HOME +environment variable to locate it's configuration file, and tramp is +modifying this environment variable. + +To verify this: + +Start emacs with "emacs -Q" +open a file use /su:user_@localhost:filename +run M-! (or M-x shell-command) echo $HOME + +you will see that the variable is changed to the home directory of +user_x. + +If you think this behaviour of tramp is wrong (I didn't think through +all the implications), then you could file an emacs bug. + +Do you see this behaviour when running compose-mail from a buffer that +is not a tramp buffer? + +All that said, the patches of + + mid:2f89028f7986f67792478f1728ca1f1fdd382d3c.1359495450.git.jani@nikula.org + +could be used to work around this "feature" of tramp. In fact since +they were stalled a bit waiting for a convincing use case, maybe your +report will help get them into notmuch more quickly. + +Someone would still have to modify the emacs client side code, but at +least conceptually I don't think that would be difficult. + +d + +PS: all my tests where with Emacs 24.2.1 + +