Re: Multiline editing breaks if the previous output doesn't end in newline

[Alex fxmbsw7 Ratchev]

On Sun, Oct 30, 2022, 23:01 Dennis Williamson <dennistwilliamson@gmail.com>
wrote:

>
>
> On Sun, Oct 30, 2022 at 4:41 PM Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com>
> wrote:
>
>>
>>
>> i coded a files tree to bash code via gawk reading and printing bash code
>> i did noeol no newline at end
>> logically , cause , who wants var='from file\n'
>>
>> >
>>
>
> Because command substitution strips trailing newlines?
>

no , sir
i did simple files-in-dirs to bash-code
i cant ( i did ) generate bash via bash , but it was too slow
the current uses gawk to generate project bash code in one run with find \0
as input
for , to file , or eval , source ..

my point with the newlines i came across when processing the files 1:1 , i
think it began with mapfile usage but gawk does as well

there is to me , not knowing end newline(s) count , only a ( too ) fatal
disability
it also makes data processing , a pain

to me the ansi or whatever newline ending rule is , as i try to say ,
nothing profitable

what i mean in my example is
when normally writing a file in vim , it ends with the big time ignored
newline
say one has vars/foo with content 'bar'
my code would produce , along var stacking , foo='bar
'
to me , as data cruncher , one to one data preservance is must
so i changed vim settings to skip this ending newline

there is also another case if use for exactness
that is data stacking in sequencial files
sometimes \n sometimes not

hopes for good , /peace

$ echo -e 'foo\n\n\n'
> foo
>
>
>
> $ s=$(echo -e 'foo\n\n\n')
> $ declare -p s
> declare -- s="foo"
>
> No gyrations needed.
> --
> Visit serverfault.com to get your system administration questions
> answered.
>