Re: freebsd problems with carriage return

[Stephane Chazelas <stephane_chazelas@xxxxxxxx>]

2009-03-26 21:09:58 +1300, Atom Smasher:
[...]
> hhmmm... it may be related to a pipe (but it works as expected on linux, 
> with a pipe or redirect)... so maybe i can use a redirect as if it's a 
> pipe...
> 	http://smasher.org/tmp/snapshot154.png
[...]

Sorry, my previous email was a bit convoluted as I was writing
it while investigating. The last part of the email explained the
reason for the problem. On FreeBSD, tcgetpgrp() on a pipe
returns the id of the process group that is meant to receive a
SIGIO on that pipe (or 0 if nobody registered for SIGIO) while
rsync() expects it to return -1 (as it should according to POSIX
and its man page).

The effect of that is that as tcgetpgrp() return 0 instead of
-1, rsync things stdout is a terminal and as 0 is not the
progress group id of the process, it thinks it is running in
background so does *not* output its progress.

>
> the top half of that split screen is `tr` converting carriage returns into 
> newlines, and reading stdin from a fifo. the bottom half is rsync, with 
> stdout redirected into the fifo. it's working as desired and expected, even 
> on freebsd.
>
> what seems to me like just a slight variation of that, once again works on 
> linux and fails on freebsd:
> 	tr '\r' '\n' < <( rsync --progress --bwlimit=5 foo_in foo_out )
>  or:
> 	rsync --progress --bwlimit=5 foo_in foo_out > >( tr '\r' '\n' )
>
> my understanding of zsh; process substitution should operate as a fifo. so 
> i really don't get why it works as desired in the screen-shot, but not with 
> process substitution.
[...]

Same thing, it's all pipes, so falls into that case.

Cheers,
Stephane