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.
