On Sun, Oct 30, 2022, 23:01 Dennis Williamson <dennistwilliam...@gmail.com> wrote:
> > > On Sun, Oct 30, 2022 at 4:41 PM Alex fxmbsw7 Ratchev <fxmb...@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. >
