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

[Christoph Anton Mitterer]

On Tue, 2021-06-01 at 09:26 -0400, Chet Ramey wrote:
> > I wondered whether there were any plans to implement proper support
> > for
> > command substitutions that preserves trailing newlines?
> 
> "Proper" is doing a lot of work in ths sentence.

What do you mean? That would be much work to get it implemented in the
shell?


> 
> That implies it's something that people want to standardize. I
> haven't
> seen any evidence of that.

And there is no guarantee it would ever happen. But at least with e.g.
$'...' strings it seems to work and POSIX might sooner or later
standardise it.

I just though it's a better chance to get it standardised if
implementations already have something like it - and not the other way
round.

> 
> So this is a problem that people encounter infrequently, one that has
> a
> solution that works 100% of the time in bash (your construct above
> plus
> temporarily setting LANG=C before removing the last character), and
> doesn't
> occur at all in the majority of situations (locales with UTF-8
> encodings).
> 
> Why is inventing new syntax the right approach?

I guess no normal developer writing shell scripts will typically use
these workarounds. It's not even easy to spot all the places where it
would be needed.

Even if, it's quite impractical to constantly change LC_ALL or read the
value via IFS='' read -rd '' var < <(cmd).

So in practise people will just ignore the issue - which arguably works
for most cases - but there are likely corner cases where things break.


Just imagine a script should delete a file, the path is e.g. previously
normalised with realpath or maybe one just gets the basename first.

If the file had a trailing newlines in it names the best that can
happen is that the rm simply fails - or in the worst case another file
of the same name (but without the trailing newlines) is taken.



Cheers,
Chris.