Re: wait -n misses signaled subprocess

2024-01-28 Thread Oğuz
On Monday, January 29, 2024, Greg Wooledge wrote: > > Anyway... a script writer who has a basic familiarity with wait(2) and > who reads about "wait -n" will probably assume that wait -n will return > immediately if a child process has already terminated and hasn't been > "pseudo-reaped" by a prev

Re: wait -n misses signaled subprocess

2024-01-28 Thread Greg Wooledge
On Sun, Jan 28, 2024 at 10:26:27PM -0500, Dale R. Worley wrote: > The man page doesn't make clear that if you don't specify "-n" and do > supply ids and one of them has already terminated, you'll get its status > (from the terminated table); the wording suggests that "wait" will > always *wait for*

Re: wait -n misses signaled subprocess

2024-01-28 Thread Dale R. Worley
Chet Ramey writes: >> echo "wait -n $pid return code $? @${SECONDS} (BUG)" > > The job isn't in the jobs table because you've already been notified about > it and it's not `new', you get the unknown job error status. The man page gives a lot of details and I'm trying to digest them into a structu

Re: wait -n misses signaled subprocess

2024-01-28 Thread Steven Pelley
Thank you Chet for your thorough reply. You make a few comments about differences in output (stderr for not finding a job, notifications for jobs terminating) and in all cases I believe you are correct. Let's assume job control is disabled. > > > > I expect the line ending (BUG) to indicate a re

Re: wait -n misses signaled subprocess

2024-01-28 Thread Chet Ramey
On 1/22/24 11:30 AM, Steven Pelley wrote: I've tried: killing with SIGTERM and SIGALRM killing from the test script, a subshell, and another terminal. I don't believe this is related to kill being a builtin. enabling job control (set -m) bash versions 4.4.12, 5.2.15, 5.2.21. All linux arm64

Re: cd"": Shouldn't it fail?

2024-01-28 Thread Oğuz
On Sunday, January 28, 2024, Kerin Millar wrote: > To summarise, the behaviour of bash appears to conform with the wording of > Issue 7 but it may have to change for Issue 8 or a later revision. > Yeah I think you're right. In the description of directory operand, Issue 7 says: >If *directory* i

Re: cd"": Shouldn't it fail?

2024-01-28 Thread Kerin Millar
On Sun, 28 Jan 2024 18:09:24 +0300 Oğuz wrote: > On Sun, Jan 28, 2024 at 5:10 PM wrote: > > POSIX Programmer's Manual (cd(1p) manpage) says this: > > > > [9 unrelated special cases] > > > > 10. The cd utility shall then perform actions equivalent to the > >chdir() functio

Re: cd"": Shouldn't it fail?

2024-01-28 Thread Oğuz
On Sun, Jan 28, 2024 at 5:10 PM wrote: > POSIX Programmer's Manual (cd(1p) manpage) says this: > > [9 unrelated special cases] > > 10. The cd utility shall then perform actions equivalent to the >chdir() function called with curpath as the path argument. If >the

Re: cd"": Shouldn't it fail?

2024-01-28 Thread Kerin Millar
On Sun, 28 Jan 2024 04:30:48 +0100 j...@jwo.cz wrote: > My opinion on this is that the ``cd ""'' command should fail with an > error in this case. The zsh is the only POSIX-compatible or > POSIX-shell-like shell that was available on machines to which I have > access that exhibits this behavior. >

cd"": Shouldn't it fail?

2024-01-28 Thread jwo
Hello, (If you don't want to read through this stuff, see the end or grep for word ``opinion''.) I started exploring details of file handling on Linux and similar systems and wondered what ``cd ""'' will do. I was experimenting with various shells. Let's start with some non-GNU shells on one Fr