On Wed, Jul 08, 2009 at 06:21:27PM +0100, Alasdair G Kergon wrote: > > ill effects and certainly doesn't warrant an obnoxious warning I can only > > turn off by relying on an undocumented feature. > > What stops you closing the fd just before the execve()?
Nothing, I suppose, other than that it adds a difficult to read line with no obvious purpose to the script (nothing a comment couldn't explain, to be sure). But I agree it's a workaround (whether it's nicer than the magic envvar, I couldn't say). > lvm will not write to pre-existing fds other than 0, 1 & 2 and lvm is > currently > imposing it as a requirement that other fds, which lvm will not use, should be > closed before invocation. I'm still not sure I understand why this is such a big deal that it's unacceptable to just close them silently, but I don't want to argue this point ad nauseam. > > I think --quiet should get rid of these warnings too; > > Unfortunately the program structure makes that impossible: these checks > are performed during initialisation, before even looking at any command line. Well, the fact that it's difficult to fix doesn't mean it's not broken. :) Currently, --quiet doesn't work properly because LVM still prints messages that aren't critical errors. I wouldn't object to this bug being downgraded to wishlist and retitled to something like "Please fix --quiet so that it suppresseses the warning about FDs left open" (it's not my bug, so I won't mess with it myself). Add a wontfix tag if you think it's never going to be fixed. However, I think at the very least the magic envvar should be documented for use in those cases where a stay FD is known to be present and LVM should be silent. This would help avoid kludges like lvsomething 2>&1 | fgrep -v ... (And hey, maybe there are even valid uses for stray FDs, only we can't think of any right now - so that not even closing them may always be desirable.) Andras -- Andras Korn <korn at elan.rulez.org> - <http://chardonnay.math.bme.hu/~korn/> Bathroom scale: Something you stand on and swear at. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org