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 a|head|bzip2|bzgrep -c a 10 $ yes a|head -100|bzip2|bzgrep -c a 100 $ yes a|head -1000|bzip2|bzgrep -c a 1000 $ yes a|head -1|bzip2|bzgrep -c a 1 $ yes a|head -10|bzip2|bzgrep -c a 10 $ yes a|head -100|bzip2|bzgrep -c a 100 $ yes a|head -1000|bzip2|bzgrep -c a 1000 $ yes a|head|gzip|zgrep -c a 10 $ yes a|head -100|gzip|zgrep -c a 100 $ yes a|head -1000|gzip|zgrep -c a 1000 $ yes a|head -1|gzip|zgrep -c a 1 $ yes a|head -10|gzip|zgrep -c a 10 $ yes a|head -100|gzip|zgrep -c a 100 $ yes a|head -1000|gzip|zgrep -c a 1000 $ yes a|head|grep -c a 10 $ yes a|head -100|grep -c a 100 $ yes a|head -1000|grep -c a 1000 $ yes a|head -1|grep -c a 1 $ yes a|head -10|grep -c a 10 $ yes a|head -100|grep -c a 100 $ yes a|head -1000|grep -c a 1000 they are single binary (linked statically) $ for f in xzgrep bzgrep zgrep grep; do ls -l $(which $f); done -r-xr-xr-x 15 root wheel 578352 Feb 2 00:39 /usr/bin/xzgrep* -r-xr-xr-x 15 root wheel 578352 Feb 2 00:39 /usr/bin/bzgrep* -r-xr-xr-x 15 root wheel 578352 Feb 2 00:39 /usr/bin/zgrep* -r-xr-xr-x 15 root wheel 578352 Feb 2 00:39 /usr/bin/grep* -- kuro ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: umass regression
At Tue, 3 Jan 2012 18:15:32 +0100, Hans Petter Selasky wrote: The following transaction shows that the device supports two luns. I suspect that there is a miscommunication between UMASS and CAM layer. Hi, I have posted about the same issue some days ago to -scsi@. http://docs.FreeBSD.org/cgi/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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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 appear. I submitted a patch in the following PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=163932 Hi, I now aware of why my da1 did not appear once I tried this quirk the other day; I set it FIXED device. It should be REMOVABLE device as yours. ugen0.5: vendor 0x091e at usbus0 umass0: vendor 0x091e product 0x2271, class 0/0, rev 1.10/5.09, addr 5 on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4000 umass0:10:0:-1: Attached to scbus10 da0 at umass-sim0 bus 0 scbus10 target 0 lun 0 da0: Garmin Edge 705 Flash 1.00 Removable Direct Access SCSI-5 device da0: 1.000MB/s transfers da0: 976MB (1998848 512 byte sectors: 64H 32S/T 976C) da1 at umass-sim0 bus 0 scbus10 target 0 lun 1 da1: Garmin Edge 705 SD Card 1.00 Removable Direct Access SCSI-5 device da1: 1.000MB/s transfers da1: 1910MB (3911680 512 byte sectors: 255H 63S/T 243C) Thanks for the pointers and discussion that led to this solution. Thank you very much. Great analysis. -- kuro ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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# ddb(8) config file.
grep: /etc/bluetooth/hcsecd.conf: Permission denied
grep: /etc/ntp: Permission denied
==
==
$ gnugrep -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# ddb(8) config file.
gnugrep: /etc/bluetooth/hcsecd.conf: Permission denied
gnugrep: /etc/ntp: Permission denied
gnugrep: /etc/ppp/ppp.conf: Permission denied
/etc/rc.d/ddb:# $FreeBSD: head/etc/rc.d/ddb 208307 2010-05-19 19:03:19Z dougb $
/etc/rc.d/ddb:# PROVIDE: ddb
/etc/rc.d/ddb:name=ddb
/etc/rc.d/ddb:start_precmd=ddb_prestart
/etc/rc.d/ddb:ddb_prestart()
/etc/rc.d/ddb: # Silently exit if ddb is not enabled
/etc/rc.d/ddb: if [ -z `sysctl -Nq debug.ddb.scripting.scripts` ]; then
/etc/rc.d/ddb:required_files=${ddb_config}
/etc/rc.d/ddb:command_args=${ddb_config}
/etc/rc.d/initrandom:# REQUIRE: dumpon ddb
/etc/rc.d/savecore:# REQUIRE: dumpon ddb syslogd
gnugrep: /etc/security/audit_control: Permission denied
gnugrep: /etc/security/audit_user: Permission denied
gnugrep: /etc/security/audit_warn: Permission denied
gnugrep: /etc/ssh/ssh_host_key: Permission denied
gnugrep: /etc/ssh/ssh_host_dsa_key: Permission denied
gnugrep: /etc/ssh/ssh_host_rsa_key: Permission denied
gnugrep: /etc/ssh/ssh_host_ecdsa_key: Permission denied
/etc/ddb.conf:# $FreeBSD: src/etc/ddb.conf,v 1.1 2008/03/05 18:32:58 brooks Exp
$
/etc/ddb.conf:# ``ddb'' to define debugging scripts.
/etc/ddb.conf:# see ``man 4 ddb'' and ``man 8 ddb'' for details.
/etc/sysctl.conf:#debug.ddb.textdump.pending=1
gnugrep: /etc/namedb/s: Permission denied
gnugrep: /etc/namedb/rndc.key: Permission denied
gnugrep: warning: /etc/namedb/namedb: recursive directory loop
/etc/portsnap.conf:KEYPRINT=9b5feee6d69f170e3dd0a2c8e469ddbd64f13f978f2f3aede40c98633216c330
gnugrep: /etc/master.passwd: Permission denied
gnugrep: /etc/nsmb.conf: Permission denied
gnugrep: /etc/opieaccess: Permission denied
gnugrep: /etc/spwd.db: Permission denied
gnugrep: /etc/opiekeys: Permission denied
/etc/rc.conf.local:ddb_enable=YES
gnugrep: /etc/malloc.conf: No such file or directory
==
--
kuro
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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 pts/12, nothing is wrong. == $ script /dev/null tty; lastcomm tty|head -1; lastcomm tty|head -1 Script started, output file is /dev/null /dev/pts/13 Script done, output file is /dev/null tty - user pts/130.001 secs Tue Oct 11 20:46 tty - user #C:0x8b 0.001 secs Tue Oct 11 20:46 == Please look at the second entry of lastcomm. These two entries should describe the identical tty(1) process, and a tty field in the second entry does not look good. It looks stored accounting information is correct, but lastcomm failed to represent device name gently after it has been destroyed. Funnier case: == $ jot 1000|while read n; do script /dev/null tty /dev/tty done /dev/null 21 ; wait; lastcomm tty|head == And you'll see variety of output. Some devices are still alive and others has been destroyed. Without head(1) you'll see a swarm of them, of course. (After this one-liner, my tty always goes mad and have to reset(1) to be back sane. This is another issue though.) -- kuro ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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 0123456789x == result: 1 2 90123456789. 3 0123456789. 4 90123456789. 5 90123456789x == (1) this should match but does not. (2) without -F it matches. (3) trim leading 1 byte from input string it matches. (4) trim last period from query string it matches. (5) replace period with another character (no matter what it is) it matches. bsdgrep in -CURRENT and GNU grep match all cases. -- kuro ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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 $? 1 $ echo |grep -qv '^'; echo $? 0 $ echo |gnugrep -q '^'; echo $? 0 $ echo |gnugrep -qv '^'; echo $? 1 I believe GNU grep is correct, and bsdgrep inverts logic when input is a newline. Imagine my astonishment when yes |grep -v '^$' scrolled out console text instantly. :) I also tested stock GNU grep on RELENG_8 chroot sandbox, bsd-grep-20110912 from ports on both RELENG_8 and 9-CURRENT, and found they work all OK as GNU grep. So I think this has been fixed in the latest bsdgrep but not checked in to -CURRENT yet. Am I correct? Does anyone see this on your 9-CURRENT box? -- kuro ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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 linking so weird things might happen. Like unexpected font selected, flash movie malfunctioning in firefox, some port compilation failure[*3], etc, etc. They all have happened on me and already gone. Hope this helps. -- kuro [*1] r216695: http://docs.FreeBSD.org/cgi/mid.cgi?201012250851.oBP8pLLm017014 [*2] r216728: http://docs.FreeBSD.org/cgi/mid.cgi?201012270030.oBR0UTq9004790 [*3] problem with port gobject-introspection on 9.0-CURRENT http://docs.FreeBSD.org/cgi/mid.cgi?alpine.LRH.2.02.1012261329550.8533 and http://docs.FreeBSD.org/cgi/mid.cgi?alpine.LRH.2.02.1012282053100.28301 (He is my hero.) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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 http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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 10 -- kuro ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
