Re: any plans for command substitution that preserves trailing newlines?

[Christoph Anton Mitterer]

Hey.


Guess everything is really clear now :-) Thanks a lot!


On Fri, 2022-01-28 at 11:19 -0500, Chet Ramey wrote:
> It's not good form to force your own locale on the user, who might
> not
> even have it installed. So some shells dodge the question entirely:
> you get
> what you got when the shell started.

> Others, like bash, treat everything as
> multibyte characters whose interpretation is subject to the current
> locale.

You mean if one has a fixed string like:
foo="b€r"
and changed the locale before, bash would parse "foo" still with the
old, but "b€r" with the new locale?


That's what I'd have followed from POSIX' wording:

"Changing the value of LC_CTYPE after the shell has started shall not
affect the lexical processing of shell commands in the current shell
execution environment or its subshells."



> Probably. Or "POSIX".
But these are equivalent.




> There's just not a portable way to do that that's guaranteed to work.
> Even
> if you change `environ', there's nothing prohibiting a libc getenv
> implementation from reading the environment on the first call and
> caching
> it internally.

Ah.. uhm ok... I didn't think about that... I thought it would always
have to use `environ`.

And then my thinking was, that every time the shell wants to call
setlocale() it, could swap `environ` with a char** that just contains
its LANG/LC_* shell vars,... but for everything else, the "true"
`environ` would be use (so that one gets the right things exported).
But as you say, even the latter has the problem, that a libc
implementation might not pick that up.


> It gets tricky. Say you unset LC_ALL, which the shell inherited from
> the
> environment, and that `unshadows' a value of, for instance, LC_CTYPE
> that
> the shell also inherited in its environment. Child processes will see
> a 
> different value for that category than you may have intended.

Sure that's clear,... but for that reason we only change the locale
around the substitution, and we only unset LC_ALL afterwards, if it was
already unset before.



> > result="$(command ; e=$?; print '.' ; exit $?)"
> 
> You've already seen the problems with this in another message thread.

Yes... and sorry for any confusion this might bring to future readers
of the archive.


It should have read:

result="$(command ; e=$?; printf '.' ; exit $e)"


But even that might be further improved, namely for the rather unlikely
case that the printf fails, and I'd now probably use:

result="$(command ; e=$?; printf '.' && exit $e || exit 666 )"

With 666 being replaced with some special value like GNU's:
EXIT_CANCELED      125      internal error



> The wide-character behavior of yash aside, any shell that doesn't
> treat
> a character that is not part of any other encoding as the character
> itself
> (e.g., `.') has a bug.

Okay, but if we'd see it that way,.. one could again just strip off "."
without any locale changes,... just as mirabilos suggested over at the
other list.

Anyway... better safe than sorry.


> > whereas POSIX would mandate:
> > export DESKTOP_SESSION='cinnamon'
> > export DISPLAY=':0'
> 
> Only if you use `export -p'. Otherwise the output is unspecified.

Ah, I had tried export -p ... but haven't tried it in POSIX mode. :D


Thanks,
Chris.