Re: grep -R without directory argument

2015-04-30 Thread Alexander Hall
On April 30, 2015 7:51:55 AM GMT+02:00, Martin Natano wrote: >grep reads from standard input when no files are specified. It also >does >so when -R is used, which doesn't really make sense. I think using the >current working directory as a fallback when no directories are >specified would make s

Re: grep -R without directory argument

2015-04-30 Thread Vadim Zhukov
2015-04-30 8:51 GMT+03:00 Martin Natano : > grep reads from standard input when no files are specified. It also does > so when -R is used, which doesn't really make sense. I think using the > current working directory as a fallback when no directories are > specified would make sense. POSIX says "I

Re: grep -R without directory argument

2015-04-30 Thread Stuart Henderson
On 2015/04/30 07:51, Martin Natano wrote: > grep reads from standard input when no files are specified. It also does > so when -R is used, which doesn't really make sense. I think using the > current working directory as a fallback when no directories are > specified would make sense. POSIX says "I

Re: grep -R without directory argument

2015-04-30 Thread Alexander Hall
On April 30, 2015 9:19:18 AM GMT+02:00, Alexander Hall wrote: >While the situation you describe is admittedly horribly annoying >(BTDT), we do allow 'grep -I "123"', which would also seem >"pointless". Bah. That's lowercase -i, obviously. Stupid phone. /Alexander

Re: grep -R without directory argument

2015-04-30 Thread Mark Kettenis
> Date: Thu, 30 Apr 2015 07:51:55 +0200 > From: Martin Natano > > grep reads from standard input when no files are specified. It also does > so when -R is used, which doesn't really make sense. I think using the > current working directory as a fallback when no directories are > specified would m

Re: grep -R without directory argument

2015-04-30 Thread David Vasek
On Thu, 30 Apr 2015, Stuart Henderson wrote: On 2015/04/30 07:51, Martin Natano wrote: grep reads from standard input when no files are specified. It also does so when -R is used, which doesn't really make sense. I think using the current working directory as a fallback when no directories are

Re: getsock() api modification

2015-04-30 Thread Martin Pieuchot
On 21/04/15(Tue) 17:15, Vitaliy Makkoveev wrote: > Now fd_getfile() function returns unacquired "struct file" instance > [...] > It is unacceptable on multiprocessor machine because the instance referenced > by fp can be destroyed between fd_getfile() and FREF() calls. So I want > fd_getfile() retu

Re: getsock() api modification

2015-04-30 Thread Vitaliy Makkoveev
On 30 Apr 2015, at 12:49, Martin Pieuchot wrote: > Your diff makes sense but sadly it is broken, could you send a diff that > can be applied? Index: share/man/man9/file.9 === RCS file: /cvs/src/share/man/man9/file.9,v retrieving re

Re: getsock() api modification

2015-04-30 Thread Vitaliy Makkoveev
Mail.app removes spaces from line start :(

Re: Async upd(4) - patch 7/7

2015-04-30 Thread Martin Pieuchot
On 24/04/15(Fri) 20:48, David Higgs wrote: > This is the final patch in the series. > > Utilize the pending flags and report callback for their intended purpose - to > process async behavior. > > Apply splusb() to ensure report callbacks can't fire before their data > structures have been prope

Re: grep -R without directory argument

2015-04-30 Thread Ian Darwin
On 2015-04-30 04:16, Mark Kettenis wrote: Date: Thu, 30 Apr 2015 07:51:55 +0200 From: Martin Natano grep reads from standard input when no files are specified. It also does so when -R is used, which doesn't really make sense. I think using the current working directory as a fallback when no dir

Re: grep -R without directory argument

2015-04-30 Thread Todd C. Miller
On Thu, 30 Apr 2015 07:51:55 +0200, Martin Natano wrote: > grep reads from standard input when no files are specified. It also does > so when -R is used, which doesn't really make sense. I think using the > current working directory as a fallback when no directories are > specified would make sens

Re: grep -R without directory argument

2015-04-30 Thread Todd C. Miller
On Thu, 30 Apr 2015 05:58:57 -0600, "Todd C. Miller" wrote: > GNU grep warns in this case before reading from stdin which seems reasonable. > % grep -R foo > grep: warning: recursive search of stdin > ... > > I'd rather add a warning than change the behavior. Trivial diff to add the warning. -

support 1Gb LX SFP on ix(4)

2015-04-30 Thread Stuart Henderson
Diff below allows ix(4) to support 1Gb LX SFP in its SFP+ port. It is https://github.com/torvalds/linux/commit/345be204dcbb2cc7580a63bc377a185125a6f822.patch ported to our driver. Small changes to the 3rd hunk of the ixgbe_phy.c patch as we don't have the "enforce_sfp" flag that Linux has. Goes fr

Re: support 1Gb LX SFP on ix(4)

2015-04-30 Thread Stuart Henderson
Oops obviously the bnx bit is not part of this :-) On 2015/04/30 13:13, Stuart Henderson wrote: > Diff below allows ix(4) to support 1Gb LX SFP in its SFP+ port. It is > https://github.com/torvalds/linux/commit/345be204dcbb2cc7580a63bc377a185125a6f822.patch > ported to our driver. Small changes to

Re: Async upd(4) - patch 7/7

2015-04-30 Thread David Higgs
On Thu, Apr 30, 2015 at 7:09 AM, Martin Pieuchot wrote: > On 24/04/15(Fri) 20:48, David Higgs wrote: > > This is the final patch in the series. > > > > Utilize the pending flags and report callback for their intended purpose > - to process async behavior. > > > > Apply splusb() to ensure report c

Re: support 1Gb LX SFP on ix(4)

2015-04-30 Thread Jonathan Gray
On Thu, Apr 30, 2015 at 01:13:36PM +0100, Stuart Henderson wrote: > Diff below allows ix(4) to support 1Gb LX SFP in its SFP+ port. It is > https://github.com/torvalds/linux/commit/345be204dcbb2cc7580a63bc377a185125a6f822.patch > ported to our driver. Small changes to the 3rd hunk of the ixgbe_phy.

Re: support 1Gb LX SFP on ix(4)

2015-04-30 Thread Stuart Henderson
On 2015/04/30 22:48, Jonathan Gray wrote: > On Thu, Apr 30, 2015 at 01:13:36PM +0100, Stuart Henderson wrote: > > Diff below allows ix(4) to support 1Gb LX SFP in its SFP+ port. It is > > https://github.com/torvalds/linux/commit/345be204dcbb2cc7580a63bc377a185125a6f822.patch > > ported to our drive

Re: support 1Gb LX SFP on ix(4)

2015-04-30 Thread Jonathan Gray
On Thu, Apr 30, 2015 at 01:13:36PM +0100, Stuart Henderson wrote: > Diff below allows ix(4) to support 1Gb LX SFP in its SFP+ port. It is > https://github.com/torvalds/linux/commit/345be204dcbb2cc7580a63bc377a185125a6f822.patch > ported to our driver. Small changes to the 3rd hunk of the ixgbe_phy.

[no subject]

2015-04-30 Thread Todd C. Miller
Merge two identical if() statements. The change in ip_spd.c 1.59 makes it appear that there is a cut & pasto. We should merge the two identical and adjacent if() statements to avoid confusing people (and static analyzers). - todd Index: sys/netinet/ip_spd.c

Re:

2015-04-30 Thread Todd C. Miller
On Thu, 30 Apr 2015 10:21:13 -0600, "Todd C. Miller" wrote: > Merge two identical if() statements. The change in ip_spd.c 1.59 > makes it appear that there is a cut & pasto. We should merge the > two identical and adjacent if() statements to avoid confusing people > (and static analyzers). Forg

Re: grep -R without directory argument

2015-04-30 Thread Alexander Hall
On April 30, 2015 2:02:23 PM GMT+02:00, "Todd C. Miller" wrote: >On Thu, 30 Apr 2015 05:58:57 -0600, "Todd C. Miller" wrote: > >> GNU grep warns in this case before reading from stdin which seems >reasonable. >> % grep -R foo >> grep: warning: recursive search of stdin >> ... >> >> I'd rather

kernel patch available

2015-04-30 Thread Philip Guenther
Patches are now available for 5.6 and 5.7 which fix local security issues in the kernel's handling of malformed ELF executables, which could be used to panic the kernel or view some kernel memory. Our thanks to Alejandro Hernandez for test cases and Maxime Villard for providing the basis for one o

tar/pax/cpio patch available

2015-04-30 Thread Philip Guenther
Patches are now available for 5.6 and 5.7 which fix security issues in the combined tar, pax, and cpio program's handling of malicious archives, as well as archives with large pax extension headers. Our thanks to Daniel Cegielka for reporting this. Note that the patches for 5.6 and 5.7 have sever