Re: bash read and field separator

[Greg Wooledge <greg@wooledge.org>]

On Sat, Dec 10, 2022 at 07:18:13PM +0700, Max Nikulin wrote:
> It took some time for me to realize why you case is different. Please, try
> 
> cd tmp
> find leaf leaf/ leaf// -printf '%T@/%TY-%Tm-%Td/%TT/%p\0' | while IFS=/ read
> -rd '' _ day time path; do printf '%s\n' "$path"; done

unicorn:~/tmp$ find leaf leaf/ leaf// -printf '%T@/%TY-%Tm-%Td/%TT/%p\0' | while IFS=/ read -rd '' _ day time path; do printf '%s\n' "$path"; done
leaf
leaf
leaf//

Well, crap.

> I have found some speculations that it is standard behavior
> https://stackoverflow.com/questions/52762210/shell-read-sometimes-strips-trailing-delimiter

Shells are the WORST.  What a pile of shit.

Stephane's workaround ("inserting an extra : and remove it afterwards")
is probably the way to go.

unicorn:~/tmp$ find leaf leaf/ leaf// -printf '%T@/%TY-%Tm-%Td/%TT/%p/\0' | while IFS=/ read -rd '' _ day time path; do printf '%s\n' "${path%/}"; done
leaf
leaf/
leaf//

This doesn't matter for the "rlart" function, because we're restricting
the output to files.  Even in the more general case, find is never going
to write a pathname that ends with "/" except where you begin the search
at "/", or where you add a trailing slash on the starting pathname, as
you did here.  No sensible person would do either of those things, or
if they did, they would know enough to ignore the oddity on the first
line of the filtered output.

Now I've got a BashPitfalls section to update too.  Damn it.