On Sat, Oct 23, 2010 at 08:03:05PM -0400, Jameson Rollins wrote: > I think that's an even falser analogy. Because we're using bash, we're > calling out to a lot of secondary processes. You really think the > program should just blithely continue running if one of those > subprocesses fails? I certainly don't. I think that's probably a
No, and that is why in every other programming language people do proper error-checking rather than relying on a hack that presumes the meaning of every single command's exit status. > Your proposal to not use "set -e" would make everything much harder. > Not using "set -e" means we either just ignore all return codes, which I > already said I think is a bad idea, or we have to capture the return > code of *every* call, and check to make sure that it's returned what we > expect (which is usually just 0). That's a much more onerous task, and > one much more prone to failure. As it is now, we just have to capture > the return of the calls that we *expect* to occasionally return > non-zero. If this were written in Perl, how would you achieve the same effect? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
