I believe you are wrong about prior behavior. sudo is from a port and
is in /usr/local/bin. Any shell is going to expand the list of args
*before* giving control to the executable. So the system will churn
for a while before sudo gets to ask for the password.
On Thu, Oct 08, 2009 at 12:59:36AM -0400, jhell wrote:>
> ------------------------------------------------------------------------
> r197748 | jilles | 2009-10-04 13:16:11 -0400 (Sun, 04 Oct 2009) | 7 lines
>
> MFC r197371: Mention that NUL characters are not allowed in sh(1) input.
>
> I do not consider this a bug because POSIX permits it and argument strings
> and environment variables cannot contain '\0' anyway.
>
> PR: bin/25542
>
> ------------------------------------------------------------------------
>
> Recently I have been noticing strange happenings of what I believe to be
> coming from the latest revision of /bin/sh. Prior to this revision it had
> not happened to the following examples. I am taking this as it could just
> be a following behavior in sudo due to fixing the first behavior in sh(1)
> but I am not sure and looking for feedback.
>
> How to repeat: ( Let me know if this is only me. )
> # sudo rm -rf /usr/ports/*/*/work
>
> After issuing the above command the process waits for the list of (work)
> directories to be collected and ends by bombing out with pam timeout
> error. This could probably be easier seen with higher IO load but it has
> struck me kind of odd since I have not seen it at all till now. Also once
> it gets started you can not ^C the process until it has run the full
> directory tree.
>
> Behavior before, you could issue the command and it would ask you for your
> password before it would issue any IO to the disk. Is the new behavior
> called for adjusting your command to sh -c "rm -rf
/usr/blah/bloo/bla*" ?
--
Barney Wolff I never met a computer I didn't like.