On Mon, 2022-01-31 at 10:45 +0000, Geoff Clare via austin-group-l at The Open Group wrote: > > > Okay, I was assuming the typical case where the output is only > valid for exit status 0. If other exit statuses also have valid > output then they would need to be allowed for (such as grep > exiting with 1 for no matches) but the code should still check for > errors, e.g. by doing: test "$e" -le 1 > (Personally I would put that inside the command substitution, so it > is as tightly coupled as possible with the command whose exit status > is being checked.)
My goal was rather to most closely resemble the behaviour of a "normal" command substitution (i.e. one should get the commands exit status afterwards). > If the command produces valid output but the printf fails, I don't > see why there is any need to handle that differently from the > command failing. The end result is still that the captured output > isn't usable (because it will have had trailing newlines removed). > The diagnostic message from the command and/or printf should be > sufficient to identify what failed. Well diagnostic output is not easy to use in scripting. Imagine you have a command where you still need to act in some way, whether it failed (regardless of the output in the command substituion being unusable). E.g. a file was downloaded, the output of wget (if it would have any trailing newlines) is caught,... so one may want to know the status of the original command (does one have to clean up any half downloaded files?) or whether it was just the printf that failed. I guess that depends on what one actually wants to do with the stdout of the command. > > > > Seems to perfectly clarify it. (And already give it a meaning of > > bytes > > ;-) ). > > Are you going to take care of it or should I make a request for it? > > Since you raised the issue originally, you should be the one to > submit it in Mantis. Done in: https://www.austingroupbugs.net/view.php?id=1560 > > Same here... are you taking care... or should I file a request? > > I'm happy to leave this one to you as well, but I'll do it if you > prefer. Done in: https://www.austingroupbugs.net/view.php?id=1561 Btw: I've noted that in the mailing list archives, several messages always have an empty body... perhaps some bug there. Thanks. Chris.
