[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous
Follow-up Comment #11, bug #64442 (project findutils): It is probably more reasonable to test with USR2 as pkill will signal any xargs running on the system. ___ Reply to this item at:

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous
Follow-up Comment #10, bug #64442 (project findutils): An automated test for this issue can be done with sleep 0.2 && pkill -USR1 xargs & { sleep 0.5 && echo success; } | xargs ___ Reply to this item at:

[bug #58197] "find" fails to optimize "-path /usr/foo -o -path /usr/bar" to "-regex '/usr/\(foo\|bar\)'"

2023-07-19 Thread Spencer Baugh
Follow-up Comment #3, bug #58197 (project findutils): One use case is GNU Emacs which heavily uses find, for example in M-x rgrep. Emacs often constructs find commands which look like this by default: find -H . \( -path \*/SCCS/\* -o -path \*/RCS/\* -o -path \*/CVS/\* -o -path \*/MCVS/\* -o

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous
Follow-up Comment #9, bug #64442 (project findutils): I decided to strace xargs on my phone and curiously read() is interrupted there as well but does not cause any problems. (file #54945) ___ Additional Item Attachment: File name:

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous
Follow-up Comment #8, bug #64442 (project findutils): I retract my previous statement the patch works, I just accidentaly ran system xargs instead of the locally built one. ___ Reply to this item at:

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous
Follow-up Comment #7, bug #64442 (project findutils): After testing further I found that SA_RESTART only fixes the case of waiting on read. I managed to trigger _xargs: error closing file_ by running this c=1; while true; do printf '%s\n' "$c"; c=$((c+1)); done | xargs and sending USR1 to

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous
Follow-up Comment #6, bug #64442 (project findutils): Setting _sa_flags_ to SA_RESTART fixes this. (file #54944) ___ Additional Item Attachment: File name: sa_flags.diff Size:0 KB

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous
Follow-up Comment #5, bug #64442 (project findutils): >From sigaction(3p) ... The _sa_flags_ field can be used to modify the behavior of the specified signal. ... SA_RESTART This flag affects the behavior of interruptible functions; that is, those specified to fail with errno set to *[EINTR]*.

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous
Follow-up Comment #4, bug #64442 (project findutils): Here is a diff between a normal xargs execution and one interrupted with SIGUSR1. Normal execution is just running xargs and entering ^D. --- strace-normal.txt 2023-07-19 14:31:18.639157032 +0300 +++ strace-usr1.txt 2023-07-19

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread raf
Follow-up Comment #3, bug #64442 (project findutils): I had a quick look at the code, and the signal handler for SIGUSR1/SIGUSR2 is always setup without regard to whether or not the -P option was used. I couldn't see why those signals would terminate xargs (but it did when I tested it on macos

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread Geoff Clare
Follow-up Comment #2, bug #64442 (project findutils): When fixing this, please also consider changing xargs to make it conform to POSIX as regards signal handling. POSIX does not allow xargs to handle SIGUSR1 and SIGUSR2 differently from other signals. I.e. if they are inherited as ignored they