Christoph Anton Mitterer wrote, on 28 Jan 2022:
>
> And just for the record if anyone else should ever stumble over that
> thread here in the archives... this is what I'd consider *the* solution
> which works in any POSIX compatible shell (and there in any scope,
> global or function) that handles locales in a sane way... with any
> locale/encoding:
>
> result="$(command ; e=$?; print '.' ; exit $?)"
The print should be printf, and I assume you intended exit $e here.
This will not work correctly in the unlikely event that the command
succeeds and printf fails. Also, having carefully arranged the exit
status you want, you don't do anything with it.
Personally I would use:
result="$(some_command && printf '.')" || exit
> #optionally error out if OLD_LC_ALL is already set
> unset -v OLD_LC_ALL ; [ "${LC_ALL+is_set}" ] && OLD_LC_ALL="${LC_ALL}"
>
> LC_ALL=C
> result="${result%.}"
>
> [ "${OLD_LC_ALL+is_set}" ] && LC_ALL="${OLD_LC_ALL}" || unset -v LC_ALL
You should unset -v OLD_LC_ALL here.
> > > 3) Does POSIX define anywhere which values a shell variable is
> > > required
> > > to be able to store?
> > > I only found that NUL is excluded, but that alone doesn't mean
> > > that
> > > any other byte value is required to work.
> >
> > Kind of circular, but POSIX clearly requires that a variable can be
> > assigned any value obtained from a command substitution that does not
> > include a NUL byte, and specifies utilities that can be used to
> > generate arbitrary byte values, therefore a variable can contain any
> > sequence of bytes that does not include a NUL byte.
>
> From the replies given by Harald van Dijk it's probably clear that it's
> not so 100% clear ;-)
>
>
> Would you recommend to open tickets asking for clarification for the
> following cases that came up?
>
> a) The question of my very original thread, i.e. whether the last line
> of output in a command substitution needs to have a trailing \n for it
> to be guaranteed to be considered.
> (Should be doable with a single sentence in the section.)
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 ...
> 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.
> c) Something that might have come up[0], namely whether
> setting/unsetting/assigning LANG/LC_* needs to have an immediate effect
> on the shell (script/interactive session).
> E.g. the LC_ALL=C ; var="${var%.}"
> Is that "voluntary" or mandated.
I think that was discussed before during the work we did on shell
parsing, but I don't remember the details.
--
Geoff Clare <[email protected]>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
