bsdgrep: xzgrep gives up searching too early

This is -CURRENT of r231204, 9 Feb. xzgrep seems to give up at first read(). $ yes a|head|xz|xzgrep -c a 10 $ yes a|head -100|xz|xzgrep -c a 100 $ yes a|head -1|xz|xzgrep -c a 1 $ yes a|head -10|xz|xzgrep -c a 16384 bzgrep, zgrep and grep works as expected. $ yes

Re: umass regression

/mid.cgi?86r4zkx50t.wl%poyopoyo To: freebsd-s...@freebsd.org Subject: Garmin Edge705: LUN1 of umass device not recognized I follow your suspicion as I figured out this regression happened at r208911, modification to LUN discovery code. -- kuro

Re: umass regression

At Sun, 08 Jan 2012 21:06:57 +0200, Bartosz Fabianowski wrote: Replying to myself one last time, the kind of quirk I was thinking of actually does exist already. It is called CAM_QUIRK_NORPTLUNS. Enabling this quirk fixes the issue for me - both LUNs are detected and two umass devices

bsdgrep: does anyone see this?

Hi, On the latest -CURRENT of r227785, I found bsdgrep acts differently from GNU grep; bsdgrep -R exits at first unreadable directory. == $ bsdgrep -R ddb /etc/ /etc/defaults/rc.conf:ddb_enable=NO # Set to YES to load ddb scripts at boot. /etc/defaults/rc.conf:ddb_config=/etc/ddb.conf

MPSAFE tty and lastcomm output

Hi, Does anyone see this on -CURRENT (and stable/9)? It doesn't look so smart output to me. I was aware of this issue first back in Aug 2009. == $ tty; lastcomm tty|head -1 /dev/pts/12 tty - user pts/120.002 secs Tue Oct 11 20:41 == OK, As this was run on

bsdgrep-20110912: -F/fgrep enbug

Hi, I found another issue, this time in bsdgrep-20110912 in port. == #! /bin/sh echo 1 echo 90123456789.|grep -F 0123456789. echo 2 echo 90123456789.|grep0123456789. echo 3 echo 0123456789.|grep -F 0123456789. echo 4 echo 90123456789.|grep -F 0123456789 echo 5 echo 90123456789x|grep -F

bsdgrep: does anyone see this?

Hi, On the latest -CURRENT of r225642 built with single line WITH_BSD_GREP=yes in src.conf, $ type -a grep grep is /usr/bin/grep $ grep -V grep (BSD grep) 2.5.1-FreeBSD $ locale LANG= LC_CTYPE=C LC_COLLATE=C LC_TIME=C LC_NUMERIC=C LC_MONETARY=C LC_MESSAGES=C LC_ALL= $ echo |grep -q '^'; echo $?

Re: bsdgrep: does anyone see this?

http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/bsdgrep/Makefile#rev1.16 | - Update to 20110912 | Chabgelog: .. | + Bugfix: fix handling of ^$ anchors Oh I found it. Perhaps this one? -- kuro ___ freebsd-current@freebsd.org mailing list

Re: userland weirdness between r216351 and r216738

A happy new yaer Ren$(D+1(B, At Fri, 31 Dec 2010 22:35:05 +0100, Ren$(D+1(B Ladan wrote: somewhere between 9.0-amd64 r216351 and r216738, I've noticed some userland weirdness. I suppose you've been hit by rtld bug between r216695[*1] and r216728[*2]. It broke certain kind of dynamic

Re: bsdgrep does not work with tail -f | grep combination

Hi Gabor and others, As Gabor committed r211364, bsdgrep now works nicely with tail -f. http://svn.freebsd.org/changeset/base/211364 Thank you very much. -- kuro ___ freebsd-current@freebsd.org mailing list

bsdgrep does not work with tail -f | grep combination

Hi, It seems bsdgrep does not work when piped from tail -f. I'm running r210728. term0$ jot 10 /tmp/1 term0$ tail -f /tmp/1 | grep 0 [no output] otherterm$ jot 10 /tmp/1 [no output to term0] = with GNU grep: term0$ tail -f /tmp/1 | gnugrep 0 10 otherterm$ jot 10 /tmp/1 [on term0] 10