Linda A. Walsh wrote: > Steven W. Orr wrote: > >I think there's a fundamental misunderstanding between the > >difference of an error code returned by a system call and the exit > >status of a process. They're two completely different things. > ---- > It's not a fundamental misunderstanding. It's a fundamental belief > in using data bandwidth and not wasting it. If 0=ok, as it does in bash and > with errno, and, it is the case (still is), that errno's fit in 1 byte, > there's no reason not to return the exact failure mode from a util...
I still think there is the misunderstanding of the OP's case between bash and the run of it under valgrind. I think you are still talking about the valgrind part of the run. But in any case, is there anything in there that is about bash? If so the we need an exact test case. If not then let's not discuss it here. > That's not to say that many or most do -- some even return a status > of '0' on fatal errors (xfs_mkfile -- on running out of room returns a status > 0). What xfs utils do or don't do is off topic for the bug-bash list. > >Just for fun, look at the man page for grep. It is advertised to > >return a 0, 1 or 2. The actual values of errno that might happen > >in the middle are a separate problem. > ---- > Like I said, it's a fundamental waste of bits. > > But -- if it encountered an error, should it issue a SEGV and > coredump message, or should it terminate the wayward script/function > and return to the prompt? This is just the result of "Worse is Better". It is one of the fundamentals that made Unix the wondeful system that we know it to be today. You may not like it but it is a principle that has strongly shaped the system. http://en.wikipedia.org/wiki/Worse_is_better The problem you are fighting is that every program on the system is governed by kernel stack limits. If the program exceeds the policy limit then it will get a SIGSEGV for stack growth failure. Now it is possible for a program to go to extreme efforts to trap that case and to deal explicitly with it. But it isn't worth it. Worse is better. Better is an easy to maintain portable program. Trying to deal with every possible problem on every possible system in every possible context will yield a worse solution. Don't do it. In the immortal words of Smith & Dale: SMITH: Doctor, it hurts when I do this. DALE: Don't do that. > Hey you can do whatever, but if the linux kernel crashed on every > resource strain, most people would consider that bad. This is a reductio ad absurdum ("reduction to absurdity") argument that doesn't apply here. The linux kernel was not crashing. This is off the topic. Bob