Follow-up Comment #5, bug #67390 (group groff): On Thursday, 7 August 2025 14:59:19 BST you wrote: > Follow-up Comment #4: > > The commit Deri said he made in comment #1 seems not to have been pushed > yet. Reassigning to him. > > Also, some of Deri's and my exchange on this ticket seems to have gone > missing. It happened the same day GNU-related mails seemed to be delayed by > several hours, so maybe that has/had something to do with it. > > I rescued the following from my sent folder. > >> Phew! Thought you meant the code was not working. By "too bullish >> again, ignoring signals" you actually meant you did not want to wait >> "a few seconds" for it to act on the signal on an incredibly slow >> machine. > > More precisely, what happened is that "BuildFoundries" noted that > afmtodit exited with a failure status, but all it did with that > information is set a flag to be consulted later; it continued to iterate > over its argument list.
Thank you, you are correct - BuildFoundries does not "ignore" the error, but schedules a warning exit to occur less than a second later. > If the _rm_(1) command worked that way, single-mindedly iterating over > its entire argument list regardless of incoming fatal signals, telling > the user only at the end of its work that "oh, by the way, some fool > attempted to interrupt me", traditional Unix users would revolt. Gets a bit weird here! You do know that file removal is an atomic task. If rm exited as soon as it received the signal from ctrl-c there could be FS corruption, so instead it sets a flag which it consults at an appropriate point, outside the atomic job, and exits. Sounds familiar. The question then becomes, what is the most appropriate time to action the flag? The answer depends on whether the process is destructive (rm) or constructive (BuildFoundries). The second is repeatable, the first is not (you can't delete the same files again). For destructive processes I agree with you, it is very important to stop as soon as it is safe to stop (which may not be immediately if the signal occurs during an atomic part of the task). For constructive processes there is no hard and fast rule, it is a judgement call, you don't want to wait too long to action the flag (1-2 seconds is probably fine), against not giving the user complete information about problems with the run, since you have exited before completing the run. This unix user would never use rm without -i, and if I had to delete a large number of files (where -i is tedious) I would run 'find ... -print' to a file, edit to shove 'rm ' at the start, and name it as a shell script. Get a colleague to eyeball, and run it overnight when no users are on, capturing an error log. (This is of course in the days of big main frames (and minis) from ICL/IBM/Sequent/Perkin Elmer with 100s of terminals, and overnight batch runs). Its the young'uns who are punching ctrl-c on 'rm -rf' commands. > (Modern ones might not, admittedly, and resign themselves to total data > destruction because even disk access is much faster than it used to be. > > https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html > > ) > >> Perhaps you could amend the bug title to something more >> appropriate. It must take minutes to do a full make clean; configure; >> make; make check; make distcheck - I feel for you. > > I don't agree with your interpretation: by not checking the (full, > system-level) exit status of the process you're spawning, you're > throwing away information irrecoverably. Incorrect! The code was checking - and setting a flag - adding the code to the warning was appreciated, its the Intimation the signal was ignored which is wrong. > Also, on general application > design principles, unless a program has a good reason (such as wanting to give complete information on ALL the problems with the single step of buildinmg the fonts, rather than finding out piece-meal requiring multiple runs). > to be ignoring or > blocking neither, rather deferring, > a symbol, (sic) > it should respond to that signal immediately. > (Generally, if it has a good reason to not use a signal's default > behavior--in most cases, dying--it should install a handler for the > signal that sets a global flag that the main program logic routinely > checks, and which causes the program to gracefully but expeditiously > release resources and exit, often with a failure status.) I see you are agreeing with my analysis above, rm does not action the signal immediately. > I've come to expect interactive builds to be responsive to fatal > signals. I don't think my experience is unusual. The question is "How Responsive?" I consider 1-2 seconds sufficient for a constructive task, since the bonus is you receive all information from the run, meaning if there is more than 1 warning you are aware of both while fixing the issues. The title implies the program is "ignoring signals" i.e. does nothing with them, whereas your patch just shortens the time before the run terminates by a measure of milliseconds and so, since I believe you are proud of the accuracy of your prose, you would like another go at the title. > So, to me, "ignoring signals" Which you have now said it is not, just deferring acting on them some milliseconds longer than possible. > in this application implies "too bullish". Why? > > [snip] > >> I shall reply over there, probably toomorrow. > > Looking forward to it. Note James Cloos's reply on the groff list;[*] > it sounds like I may have started down an incorrect path regarding these > overloaded Greek glyphs. His reply may save you the trouble of > correcting me yourself. > Apologies, my interrupt stack keeps getting higher priority interrupts! (Still not completely unwound yet). For the emoji query I wrote a program which built the emoji.map straight from the .ttf font. > [*] https://lists.gnu.org/archive/html/groff/2025-08/msg00000.html > _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?67390> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
