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

[Alex fxmbsw7 Ratchev]

when will u beginningly stop disrespecting the bash and co and stop giving
misadvises like 'not possible in scripts' - 'dont use shell scripting' and
'bash is no codung language'
sorry to say so but my full disrespect to not true anti shell \ bash claims
- the same as overinsulting ppl like me
oh and yea not helping instead of helping

have fun typing books of crap here, not all are happy about it

On Tue, Jun 1, 2021, 13:58 Greg Wooledge <greg@wooledge.org> wrote:

> On Tue, Jun 01, 2021 at 11:46:38AM +0800, konsolebox wrote:
> > On Mon, May 31, 2021 at 11:46 PM Christoph Anton Mitterer
> > <calestyo@scientia.net> wrote:
> > > I wondered whether there were any plans to implement proper support for
> > > command substitutions that preserves trailing newlines?
> >
> > As an alternative, you can use `IFS= read -rd '' var < <(cmd)`.
>
> Not picking on this answer in particular, but... I'm skeptical of the
> original question.  The OP is concerned about some theoretical failure
> of the workaround for trailing newlines in command substitutions when
> using a variable-width character encoding and receiving malformed data
> as input.
>
> In a freaking *shell script*.
>
> Is the OP actually trying to store *binary* data in a shell variable?
> This is doomed to fail because you can't handle NUL bytes.  I'd worry
> about that long before I'd worry about malformed strings in Asian
> character encodings interfering with one's attempts to read binary data
> in a shell script.
>
> The correct response to "I'm trying to read binary data" is "don't do it
> in a shell script".
>
> Is the OP actually concerned that the user may supply input that is a
> malformed string in their own locale?  Just let it fail.  The user is
> responsible for their own self-imposed problems in that case.
>
>