Christoph Anton Mitterer wrote, on 29 Jan 2022: > > On Fri, 2022-01-28 at 09:51 +0000, Geoff Clare via austin-group-l at > The Open Group wrote: > > > Also, having carefully arranged the exit > > status you want, you don't do anything with it. > That I don't understand?
There is nothing in your code that tests what the exit status of the command in the substitution was. I added "|| exit" so that it is shown to be used in some way. > > Personally I would use: > > > > result="$(some_command && printf '.')" || exit > > I don't think this works properly... or better said: > It seems to assume, that the result is only wanted/valid when > some_command succeeds (only then the sentinel would be printed and > result be valid). > [Plus if printf would fail there, while command still succeeded one > wouldn't now what actually happened (did the printf fail? did some > command fail?)] > > > But one can easily imagine commands, where the stdout would still be > valid, despite the exit status being non-zero. 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.) 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. > > I don't think an explicit statement about it needs to be added, but > > there is scope for improving the current wording so it is clearer > > what is intended. E.g. change: > > > > ... replacing the command substitution (...) with the standard > > output of the command(s), removing sequences of one or more > > <newline> characters at the end of the substitution. Embedded > > <newline> characters before the end of the output shall not be > > removed; however, they may be treated as field delimiters ... > > > > to: > > > > ... replacing the command substitution (...) with the standard > > output of the command(s); if the output ends with one or more > > bytes that have the encoded value of a <newline> character, they > > shall not be included in the replacement. Any such bytes that > > occur elsewhere shall be included in the replacement; however, > > they might be treated as field delimiters ... > > 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. > > > b) What shell variables are actually required to be able to hold? > > > Any > > > bytes except NUL ... vs. any valid character in the locale, except > > > NUL. > > > > It seems from the discussion that the requirement for environment > > variables to contain characters may be accidental. If so, that > > should > > be fixed. As a knock-on this would confirm there is no restriction > > (beyond no-NUL-bytes) on shell variables since they are initialised > > from environment variables. > > 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. -- Geoff Clare <[email protected]> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
