From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Finding the dump Date: Sat, 02 Feb 2019 09:22:59 +0200 Message-ID: <83zhrewt64.fsf@gnu.org> References: <83munr8jb1.fsf@gnu.org> <838szb8ey9.fsf@gnu.org> <83d0oj62bc.fsf@gnu.org> <87ef8z4g1m.fsf@igel.home> <838sz75u7p.fsf@gnu.org> <877eer4e4x.fsf@igel.home> <835zub5p3i.fsf@gnu.org> <8736pf408v.fsf@igel.home> <83womq3z5c.fsf@gnu.org> <871s4yxfvb.fsf@igel.home> <83o9823xcq.fsf@gnu.org> <87womqvyy4.fsf@igel.home> <4f30b2b598e71d2c6ad766a3da8e4a33.squirrel@dancol.org> <87o982vszn.fsf@igel.home> <87k1ipx3jq.fsf@igel.home> <87bm41wzmv.fsf@igel.home> <608533e75f41da3e36e191f8a670af05.squirrel@dancol.org> <725a9f97-8bb5-4592-2512-dbd422023f51@cs.ucla.edu> <6611df71-c89e-d4ce-5db7-00edec98a9f5@cs.ucla.edu> <83bm3wynuw.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="76847"; mail-complaints-to="usenet@blaine.gmane.org" Cc: rpluim@gmail.com, eggert@cs.ucla.edu, schwab@linux-m68k.org, emacs-devel@gnu.org, dancol@dancol.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 02 08:23:53 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.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gppea-000JuB-KB for ged-emacs-devel@m.gmane.org; Sat, 02 Feb 2019 08:23:52 +0100 Original-Received: from localhost ([127.0.0.1]:38518 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gppeZ-000839-Kd for ged-emacs-devel@m.gmane.org; Sat, 02 Feb 2019 02:23:51 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49449) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gppeP-00080p-SL for emacs-devel@gnu.org; Sat, 02 Feb 2019 02:23:46 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59773) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gppeE-0001UL-P9; Sat, 02 Feb 2019 02:23:33 -0500 Original-Received: from [176.228.60.248] (port=4439 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gppe4-0004da-FP; Sat, 02 Feb 2019 02:23:20 -0500 In-reply-to: (message from Richard Stallman on Fri, 01 Feb 2019 22:25:50 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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:232899 Archived-At: > From: Richard Stallman > Cc: schwab@linux-m68k.org, rpluim@gmail.com, eggert@cs.ucla.edu, > dancol@dancol.org, emacs-devel@gnu.org > Date: Fri, 01 Feb 2019 22:25:50 -0500 > > > I would suggest to use another word instead of "should". Using > > argv[0] has its drawbacks, e.g., if the string there neither has a > > slash nor is a file found along PATH -- this could happen when a > > program is invoked via a symlink > > How so? I don't see how this could happen. If the symlink was found > in PATH to run the program, it should be there when the program looks > for it, except in the case where it was deleted or renamed in the mean > time. I mean the case where a symlink is to an explicit absolute file name, and the related files can be found only if you know the target of the symlink. But AFAIK argv[0] will not give you the resolved target file name, it will give you the symlink name. > or some other method, or because the > > calling program puts there something unrelated to where the executable > > lives. > > Yes, that can happen, but I think that is an error on the caller's > part. Anyway, there is no other portable method besides argv[0]. I > don't know whether we want to assume that all kernels for GNU will > support /proc/self. Maybe so, but still, saying "should" can be interpreted to mean any other method is discouraged, which I don't think is the case. I think this text wants to make a point that in this case it is OK to use argv[0], unlike when it is used to change the behavior of the program in some fundamental way.