Re: RE : RE : rm -f core cause some troubles
On 12/16/2012 07:06 AM, Bob Friesenhahn wrote: Why not just use ulimit to not dump core? Or is that a bashism and not a shism? The ulimit approach seems useful. Yes, that would be nice to add, if someone writes a patch. I doubt whether it'd work everywhere, though. Instead they write a core file with some other file name Autoconf-generated 'configure' scripts remove the commonly-used file names for core files. or even write all core files to some other directory on the system. It doesn't catch those. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RE : RE : rm -f core cause some troubles
On Sat, 15 Dec 2012, NightStrike wrote: On Sat, Dec 15, 2012 at 2:18 PM, Paul Eggert wrote: On 12/15/2012 03:08 PM, Jeffrey Walton wrote: Is the program designed to remove old core files as part of the autoconf process? No, new cores. 'configure' regularly generates programs that dump core, as part of its ordinary working procedure. Why not just use ulimit to not dump core? Or is that a bashism and not a shism? The ulimit approach seems useful. Blindly trying to remove a file named 'core' seems somewhat silly since many OSs do not write a file named 'core'. Instead they write a core file with some other file name or even write all core files to some other directory on the system. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RE : RE : rm -f core cause some troubles
On Sat, Dec 15, 2012 at 2:18 PM, Paul Eggert wrote: > On 12/15/2012 03:08 PM, Jeffrey Walton wrote: >> >> Is the program designed to remove old core >> files as part of the autoconf process? > > > No, new cores. 'configure' regularly generates > programs that dump core, as part of its ordinary > working procedure. Why not just use ulimit to not dump core? Or is that a bashism and not a shism? ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RE : RE : rm -f core cause some troubles
On 12/15/2012 05:01 PM, Marko Lindqvist wrote: > Does it make sure core is new one it has created. No. > Is the performance issue in the checking of nature of "core" *every > time* configure has potentially created one to be removed? Yes. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RE : RE : rm -f core cause some troubles
On 16 December 2012 02:18, Paul Eggert wrote: > On 12/15/2012 03:08 PM, Jeffrey Walton wrote: >> >> Is the program designed to remove old core >> files as part of the autoconf process? > > > No, new cores. 'configure' regularly generates > programs that dump core, as part of its ordinary > working procedure. Does it make sure core is new one it has created. Granted that if one wants to play with core generated by the program being developet, (s)he shouldn't be rebuilding program before those investigations, but potentially core file is valuable. Is the performance issue in the checking of nature of "core" *every time* configure has potentially created one to be removed? Could it just check existing situation in the beginning (is there something named 'core' already) and to store it to variable for later parts to use? - ML ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RE : RE : rm -f core cause some troubles
On 12/15/2012 03:08 PM, Jeffrey Walton wrote: Is the program designed to remove old core files as part of the autoconf process? No, new cores. 'configure' regularly generates programs that dump core, as part of its ordinary working procedure. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RE : RE : rm -f core cause some troubles
On Sat, Dec 15, 2012 at 5:58 PM, Paul Eggert wrote: > On 12/15/2012 12:31 PM, Jeffrey Walton wrote: >> >> the program is still not correct > > Correctness is in the eye of the beholder. Hmmm > For most people 'configure' behaves as intended, > but it doesn't match your intent. I'm not sure its my intent. Is the program designed to remove old core files as part of the autoconf process? Perhaps that's where the confusion lies. Perhaps it would be easier (easiest?) to remove that step in the process? That is, no longer make it a specification of the autoconf process. > the discussion we've all had so far suggests that > it's not likely Autoconf will change its behavior > in this area, so I suggest following some of the > advice that I and others already gave to work > around the problem. That's fine - I'm used to it (Closed, Won't Fix). It reminds me of http://linuxhaters.blogspot.com/2008/08/one-bug-report-to-rule-them-all.html :) Jeff ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RE : RE : rm -f core cause some troubles
On 12/15/2012 12:31 PM, Jeffrey Walton wrote: the program is still not correct Correctness is in the eye of the beholder. For most people 'configure' behaves as intended, but it doesn't match your intent. Unfortunately the discussion we've all had so far suggests that it's not likely Autoconf will change its behavior in this area, so I suggest following some of the advice that I and others already gave to work around the problem. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RE : RE : rm -f core cause some troubles
On Mon, Dec 10, 2012 at 8:36 AM, Eric Blake wrote: > On 12/08/2012 05:16 PM, Jeffrey Walton wrote: >> Agreed. Before anything, the program has to be correct. Trying to >> remove a directory named 'core' does not follow the intention >> (informally 'specification') of removing crash dump files. > > Naming a directory 'core' is dangerous and non-portable, because the > name 'core' is traditionally reserved for core dumps. Agreed, but the program is still not correct (assuming the specification is to remove old core dumps). Before anything, the program has to be correct. After correctness, the program should be secure and can be efficient. Jeff ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RE : RE : rm -f core cause some troubles
On 12/08/2012 05:16 PM, Jeffrey Walton wrote: > Agreed. Before anything, the program has to be correct. Trying to > remove a directory named 'core' does not follow the intention > (informally 'specification') of removing crash dump files. Naming a directory 'core' is dangerous and non-portable, because the name 'core' is traditionally reserved for core dumps. Similarly, naming a directory 'aux' is dangerous and non-portable, because the name 'aux' opens a special device on Windows. Similarly, naming two files with a case-sensitive clash is unsupported. In short, autoconf sticks with the philosophy that it is better for you to name your files portably than for autoconf to bend over backward to special case when those non-portable names exist on platforms where they happen to work, but will fall apart on platforms where they do not work. > > Special rules (i.e., no 'core' directories) that can only be found by > grepping mailing lists also seems to be less than desirable. If you think we need to more fully document that both 'core' and 'aux' are recommended to be avoided in your project, patches are welcome. > > What happens if a user aliases `rm` to `rm -rf`? Precisely why we are suggesting that you should fix your package to avoid 'core' as a directory, and not that we fix 'autoconf' to bend over backwards to support this fringe case. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RE : RE : rm -f core cause some troubles
On Sat, Dec 8, 2012 at 7:12 PM, Marko Lindqvist wrote: > On 9 December 2012 01:45, Paul Eggert wrote: >> On 12/08/2012 12:30 PM, PICCA Frédéric-Emmanuel wrote: >> >>> the right fix is to avoid removing core if this is a directory. >> >> Autoconf-generated 'configure' files already do that. >> That's not the issue. >> >> The only issue that has been identified is that >> 'configure' issues some annoying warnings. > > So you are saing that "we try to do the wrong thing, but as that > reliably fails, only problem are the error messages from the failure > (to do the wrong thing)"? > > As hackish solutions go, I'd consider this particular way of thinking > bad. If reliability of the normal use increases -> failure happens > less reliably when it's hackishly counted on. Agreed. Before anything, the program has to be correct. Trying to remove a directory named 'core' does not follow the intention (informally 'specification') of removing crash dump files. Special rules (i.e., no 'core' directories) that can only be found by grepping mailing lists also seems to be less than desirable. What happens if a user aliases `rm` to `rm -rf`? Jeff ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RE : RE : rm -f core cause some troubles
On 12/08/2012 04:12 PM, Marko Lindqvist wrote: > So you are saing that No. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RE : RE : rm -f core cause some troubles
On 9 December 2012 01:45, Paul Eggert wrote: > On 12/08/2012 12:30 PM, PICCA Frédéric-Emmanuel wrote: > >> the right fix is to avoid removing core if this is a directory. > > Autoconf-generated 'configure' files already do that. > That's not the issue. > > The only issue that has been identified is that > 'configure' issues some annoying warnings. So you are saing that "we try to do the wrong thing, but as that reliably fails, only problem are the error messages from the failure (to do the wrong thing)"? As hackish solutions go, I'd consider this particular way of thinking bad. If reliability of the normal use increases -> failure happens less reliably when it's hackishly counted on. - ML ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RE : RE : rm -f core cause some troubles
On 12/08/2012 12:30 PM, PICCA Frédéric-Emmanuel wrote: > You mean , I need to maintain a fork of autoconf for this project ;) No, you don't need to change autoconf at all. You merely edit its output, with 'sed', before running it. It's easy. > the right fix is to avoid removing core if this is a directory. Autoconf-generated 'configure' files already do that. That's not the issue. The only issue that has been identified is that 'configure' issues some annoying warnings. There may be some other issues, but that's all we've found so far. And the above-mentioned fix resolves that issue. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
RE : RE : rm -f core cause some troubles
> > I renamed core -> Core, and this issue just gone. > I don't know why that would be, but perhaps more digging > on your end can find out. Yes I need to investigate on this > Here's another idea. Define your own 'rm', > which will be a simple shell script that invokes the > real 'rm', except it ignores any 'core' argument. Put > it in your PATH, before the real 'rm'. Then run > configure with that PATH. That should work. yes this could work but it is really a nasty hack... > And here's another another idea. When building > 'configure', do it like this: > autoconf > sed 's/ core / /g' configure >config.cache > cp config.cache configure > That way, your 'configure' won't try to remove 'core'. > It's a bit of a hack, but it should work. You mean , I need to maintain a fork of autoconf for this project ;) To me even if this is slower, the right fix is to avoid removing core if this is a directory. It will be difficult for me to convince upstream to use autoconf if it needs to change it's code due to this bug. cheers, Frederic ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: RE : rm -f core cause some troubles
On 12/08/2012 10:12 AM, PICCA Frédéric-Emmanuel wrote: >> That would slow down 'configure' everywhere. > > how much ? I don't know. I expect it'd be measurable, though. > if you add an option each time a directory name or other file is not > allowed... Yes, perhaps it's not a good idea. > I renamed core -> Core, and this issue just gone. I don't know why that would be, but perhaps more digging on your end can find out. Here's another idea. Define your own 'rm', which will be a simple shell script that invokes the real 'rm', except it ignores any 'core' argument. Put it in your PATH, before the real 'rm'. Then run configure with that PATH. That should work. And here's another another idea. When building 'configure', do it like this: autoconf sed 's/ core / /g' configure >config.cache cp config.cache configure That way, your 'configure' won't try to remove 'core'. It's a bit of a hack, but it should work. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
