From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: `message' not outputting the newline "atomically" Date: Tue, 9 Jul 2019 11:12:52 -0700 Organization: UCLA Computer Science Department Message-ID: <41d16c85-f541-a437-e9ce-12cb94c0d2cc@cs.ucla.edu> References: <07619925-e367-fb88-2dd8-27addb2e9052@grinta.net> <68b398b1-3790-b32f-535d-6ea2518f79b8@cs.ucla.edu> <83pnn1lkej.fsf@gnu.org> <83tvccjrpo.fsf@gnu.org> <83zhm3i285.fsf@gnu.org> <7a39d680-6234-1301-74e5-62d599f500f6@cs.ucla.edu> <838stfd0pp.fsf@gnu.org> <835zojd0fx.fsf@gnu.org> <834l43czz8.fsf@gnu.org> <5c979663-9ded-4273-11d1-483345053a6f@cs.ucla.edu> <831rz7cvoh.fsf@gnu.org> <540324b5-fad3-ded0-5018-6abb494ce126@cs.ucla.edu> <83blyaaq5l.fsf@gnu.org> <73e8afc0-2151-9c8b-26c5-454fcd2f361d@cs.ucla.edu> <83tvbx7v9l.fsf@gnu.org> <83y31740yg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="200518"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 Cc: larsi@gnus.org, daniele@grinta.net, Emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 09 20:15:02 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hkudp-000pzE-N1 for ged-emacs-devel@m.gmane.org; Tue, 09 Jul 2019 20:15:01 +0200 Original-Received: from localhost ([::1]:52638 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkudo-0006Ol-6E for ged-emacs-devel@m.gmane.org; Tue, 09 Jul 2019 14:15:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53952) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkudb-0006Ob-EH for Emacs-devel@gnu.org; Tue, 09 Jul 2019 14:14:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hkudX-0003bx-VD for Emacs-devel@gnu.org; Tue, 09 Jul 2019 14:14:46 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:40814) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hkudK-0002ic-Tg; Tue, 09 Jul 2019 14:14:38 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 80C61160172; Tue, 9 Jul 2019 11:12:54 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 6-syLFlnGVnB; Tue, 9 Jul 2019 11:12:53 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B6921161D93; Tue, 9 Jul 2019 11:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1A2iAC42hOOM; Tue, 9 Jul 2019 11:12:53 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 7B768160172; Tue, 9 Jul 2019 11:12:53 -0700 (PDT) In-Reply-To: <83y31740yg.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:238471 Archived-At: Eli Zaretskii wrote: > We already found an agreed solution for > 'message' and 'vmessage', so why step back and re-introduce them into > the problem again? Because we now have a simpler solution. > As for other messages, I think the vast majority are diagnostics, and > thus using stdout for them is inappropriate, as it will get in the way > of using Emacs in scripts. No, Emacs uses stdout reasonably extensively for this sort of thing already; see 'write_stdout' and I can cite several other examples. In practice this has not been a problem because nobody cares whether these kinds of Emacs messages go to stdout or stderr. One can also see this in the decades-old commentary for the implementation of 'message', which says both 'stdout' and 'stderr' (obviously some of this commentary is incorrect, and the proposed patch fixes it). All I'm suggesting is that we move a few messages from Emacs's stderr category to its (already-existing) stdout category, to fix the interleaving problem for messages that are not fatal diagnostics or for debugging. These messages are the ones most likely to cause interleaving problems in practice. The vast majority of messages would be unaffected by the proposed patch. > what would happen if a script says > 2>foo? will the file 'foo' remain empty if we use any stream but > stderr inside message_to_stderr? No, it'll work fine. The OS doesn't care about stdio's buffers; all it cares is whether file descriptor 2 is used, which it is.