Re: [gentoo-user] 'if echo hello' in .bashrc
Alan McKinnon wrote: > On Friday 08 May 2009 16:01:14 Mike Kazantsev wrote: >> On Fri, 8 May 2009 14:38:58 +0100 >> >> Stroller wrote: >>> To find the part to which I refer you'll need to scroll down about >>> halfway through that page to "Colorize grep"; the author advises adding: >>> >>>if echo hello|grep --color=auto l >/dev/null 2>&1; then >>> export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32' >>>fi >>> >>> to ~/.bashrc >>> >>> Why does he echo hello, please? >> Some greps (like BSD one) might not support '--color' option, so "echo >> hello|grep --color=auto l" will return error code, skipping if clause, >> and won't break grep operation by adding an unsupported option. > > except that STDERR is combined with STDOUT and sent to /dev/null so the > script > will never get it, the if is always true and the entire check is redundant. > Better would be > > if echo hello|grep --color=auto l >/dev/null ; then > The redirection of output doesn't affect the return code of grep in the above case. Grep's return code is determined by matching 'l' against the output of echo hello. The desired effect of the above code is to evaluate if the --color option is supported by grep on the system. The STDERR and STDOUT redirection is an attempt to not pollute the systems screen when performing that test. To illustrate: 1. A system that supports --color $ if echo hello|grep --color=auto l >/dev/null 2>&1; then echo "Grep returned : $?"; else echo "Grep returned : $?"; fi Grep returned : 0 2. A system that doesn't support --color (simulated by supplying --unspported as an option to grep) $ if echo hello|grep --unsupported l >/dev/null 2>&1; then echo "Grep returned : $?"; else echo "Grep returned : $?"; fi -bash: echo: write error: Broken pipe [1] Grep returned : 2 3. Just to complete the examples, the result of grep not matching echo's output but still supporting the --color option. (achieved by search "hello" for the letter 'z') $ if echo hello|grep --color z >/dev/null 2>&1; then echo "Grep returned : $?"; else echo "Grep returned : $?"; fi Grep returned : 1 Regards, Carlos [1] The reason an error message is shown here is because it's bash that's reporting the broken pipe error. Grep's error message was redirected to /dev/null, which was: grep: unrecognized option '--unsupported' Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. So even when the system doesn't support --color, that original code will pollute the screen with bash's error message.
Re: [gentoo-user] HOWTO: Freezing/unfreezing (groups of) processes
On Fri, Feb 05, 2021 at 03:46:45AM -0500, Andrew Udvare wrote
>
> > On 2021-02-05, at 02:45, Walter Dnes wrote:
> >
> > done < /dev/shm/temp.txt
>
> You don't need to write a temporary file. You can pipe this directly into the
> while loop:
>
> while read
> do
> ...
> done < <(ps -ef | grep ${1} | grep -v "grep ${1}" | grep -v pstop)
I wasn't aware of the "< <" construct. Nice
> Also to avoid the second grep in Bash at least:
>
> grep "[${1:0:1}]${1:1}"
That causes some feedback about backgrounded processes.
In addition to your avoiding-the-temp-file trick, I also realized that
if I read the first 3 items of each line, I can use the 2nd parameter
directly without an intermediate assignment to an array. The latest
version of my scripts are...
=== pstop =======
while read userid pid rest_of_line
do
kill -SIGSTOP ${pid}
done < <(ps -ef | grep ${1} | grep -v "grep ${1}" | grep -v pstop)
=== pcont =======
#!/bin/bash
while read userid pid rest_of_line
do
kill -SIGCONT ${pid}
done < <(ps -ef | grep ${1} | grep -v "grep ${1}" | grep -v pcont)
=
In the course of experimentation, I've made versions that killed
critical processes, requiring a reboot. {ALT}{SYSRQ} to the rescue .
I'll stick with stuff that works.
--
Walter Dnes
I don't run "desktop environments"; I run useful applications
Re: [EXTERNAL] [gentoo-user] empty cdrom drive is busy or mounted
> On 2019-08-22, at 12:31, Laurence Perkins wrote:
>
> A common tactic is to use grep twice:
> ps auxf | grep -v grep | grep blah
Or grep with brackets:
ps aux | grep '[f]irefox'
I have a function for this:
psgrep() {
ps aux | grep "[${1:0:1}]${1:1}";
}
This works because the ps output will have "grep [f]irefox" and the regex can't
match that line (without escaping the [] again).
--
Andrew
Re: [EXTERNAL] Re: [gentoo-user] empty cdrom drive is busy or mounted
On Thu, 2019-08-22 at 10:03 +1000, Adam Carter wrote: > On Thu, Aug 22, 2019 at 5:48 AM james wrote: > > On 8/16/19 12:44 PM, Jack wrote: > > > ps auxf | grep systemd > > > > This is new turf for me. Upon issuing this command string I get:: > > > > # ps auxf | grep systemd > > root 24947 0.0 0.0 13964 996 pts/6S+ 15:43 0:00 > > | | | \_ grep --colour=auto systemd > > > > This is showing that the only process with systemd in its name is the > grep command itself; you could pass anything to grep and it will be > found in the process list, eg; > > $ ps auxf | grep blah > adam 52359 0.0 0.0 7708 940 pts/3S+ 09:55 0:00 >\_ grep --colour=auto blah > > So, there's no systemd process running on this system. A common tactic is to use grep twice: ps auxf | grep -v grep | grep blah That strips out all instances of grep from the results. Putting what you're searching for first is more efficient, but putting it last keeps the colorized output intact. LMP signature.asc Description: This is a digitally signed message part
Re: [gentoo-user] HOWTO: Freezing/unfreezing (groups of) processes
> On 2021-02-05, at 02:45, Walter Dnes wrote:
>
> done < /dev/shm/temp.txt
You don't need to write a temporary file. You can pipe this directly into the
while loop:
while read
do
...
done < <(ps -ef | grep ${1} | grep -v "grep ${1}" | grep -v pstop)
Also to avoid the second grep in Bash at least:
grep "[${1:0:1}]${1:1}"
$ ps -ef | grep '[l]vmetad'
root 965 1 0 Jan31 ?00:00:00 /sbin/lvmetad -f
^ No grep in output.
--
Andrew
Re: [EXTERNAL] Re: [gentoo-user] empty cdrom drive is busy or mounted
On 2019.08.22 12:31, Laurence Perkins wrote: On Thu, 2019-08-22 at 10:03 +1000, Adam Carter wrote: > On Thu, Aug 22, 2019 at 5:48 AM james wrote: > > On 8/16/19 12:44 PM, Jack wrote: > > > ps auxf | grep systemd > > > > This is new turf for me. Upon issuing this command string I get:: > > > > # ps auxf | grep systemd > > root 24947 0.0 0.0 13964 996 pts/6S+ 15:43 0:00 > > | | | \_ grep --colour=auto systemd > > > > This is showing that the only process with systemd in its name is the > grep command itself; you could pass anything to grep and it will be > found in the process list, eg; > > $ ps auxf | grep blah > adam 52359 0.0 0.0 7708 940 pts/3S+ 09:55 0:00 >\_ grep --colour=auto blah > > So, there's no systemd process running on this system. A common tactic is to use grep twice: ps auxf | grep -v grep | grep blah That strips out all instances of grep from the results. Putting what you're searching for first is more efficient, but putting it last keeps the colorized output intact. LMP I often deal with that by using the search function in my terminal (usually konsole) to highlight the term I'm actually looking for.
Re: [gentoo-user] linux make modules solved
On Saturday 17 June 2006 12:15, Mick wrote: > I am getting confused here: why is module building related to setting > grep's colour option? There is probably some script that parses the output of grep, and, with --color=always, this includes terminal control characters and escape sequences which confuse the parser. Using --color=auto, on the other hand, is the correct way to do the "right" thing, ie grep itself "knows" whether it should emit escape sequences to colorize the output (if it's really outputting to terminal) or not (if, for example, it's called from inside a command substitution). The following works: echo "hello" | grep ello | grep hello The following does not work, since the output of the first grep contains "garbage" (from the point of view of the second grep) between the "h" and the "e": echo "hello" | grep --color=always ello | grep hello # does not work Finally, the next one works, because the first grep knows that colorizing the output here is useless and does not emit escape sequences: echo "hello" | grep --color=auto ello | grep hello # works HTH -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] linux make modules solved
On 17/06/06, Etaoin Shrdlu <[EMAIL PROTECTED]> wrote: On Saturday 17 June 2006 12:15, Mick wrote: > I am getting confused here: why is module building related to setting > grep's colour option? There is probably some script that parses the output of grep, and, with --color=always, this includes terminal control characters and escape sequences which confuse the parser. Using --color=auto, on the other hand, is the correct way to do the "right" thing, ie grep itself "knows" whether it should emit escape sequences to colorize the output (if it's really outputting to terminal) or not (if, for example, it's called from inside a command substitution). The following works: echo "hello" | grep ello | grep hello The following does not work, since the output of the first grep contains "garbage" (from the point of view of the second grep) between the "h" and the "e": echo "hello" | grep --color=always ello | grep hello # does not work Finally, the next one works, because the first grep knows that colorizing the output here is useless and does not emit escape sequences: echo "hello" | grep --color=auto ello | grep hello # works Thanks! Nice explanation. -- Regards, Mick -- gentoo-user@gentoo.org mailing list
Re: [EXTERNAL] [gentoo-user] empty cdrom drive is busy or mounted
On 22 August 2019 22:08:41 GMT-04:00, Andrew Udvare wrote:
>
>> On 2019-08-22, at 12:31, Laurence Perkins
>wrote:
>>
>> A common tactic is to use grep twice:
>> ps auxf | grep -v grep | grep blah
>
>Or grep with brackets:
>
>ps aux | grep '[f]irefox'
>
>I have a function for this:
>
>psgrep() {
> ps aux | grep "[${1:0:1}]${1:1}";
>}
>
>This works because the ps output will have "grep [f]irefox" and the
>regex can't match that line (without escaping the [] again).
Or just use pgrep, I usually use pgrep - fa.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Firefox not killing processes on close
On Sun, Nov 10 2013, Dale wrote: > Walter Dnes wrote: >> On Sun, Nov 10, 2013 at 03:38:16PM -0600, Dale wrote >> >> ps -ef | grep firefox >> >> and you'll get something like... >> >> [i660][waltdnes][~] ps -ef | grep firefox >> waltdnes 28696 11663 2 19:35 pts/22 00:00:07 firefox >> waltdnes 28836 28825 0 19:39 pts/30 00:00:00 grep --color=auto firefox >> >> Only one Firefox process exists. (I can't seem to prevent the grep >> command from listing itself). I'll leave the heavy listing to alan, but to avoid listing the grep, I believe you want ps -ef | grep firefox | grep -v grep allan
Re: [gentoo-user] OT - grep: The -P option is not supported
Michael Sullivan wrote: I have a script I wrote a couple of weeks ago. Part of the script scans email files and returns IP addresses found in them. I did this with this command: cat * | grep -Po "\[\d+\.\d+\.\d+\.\d+\]" It worked fine right up until this afternoon. Now I get this: [EMAIL PROTECTED] ~/spam $ cat * | grep -Po "\[\d+\.\d+\.\d+\.\d+\]" grep: The -P option is not supported [EMAIL PROTECTED] ~/spam $ more /usr/portage/sys-apps/grep/ChangeLog *grep-2.5.1a-r1 (01 Aug 2006) 01 Aug 2006; Mike Frysinger <[EMAIL PROTECTED]> +grep-2.5.1a-r1.ebuild: Add back in pcre #141609. I suspect that's the issue, that your new grep is missing pcre, though it's hard to tell since you didn't mention which version of grep you have installed. Additionally pcre became a use flag in 2.5.1a-r1 kashani -- gentoo-user@gentoo.org mailing list
Re: [EXTERNAL] [gentoo-user] empty cdrom drive is busy or mounted
On 8/23/19 5:21 PM, Neil Bothwick wrote:
> On 22 August 2019 22:08:41 GMT-04:00, Andrew Udvare wrote:
>>
>>> On 2019-08-22, at 12:31, Laurence Perkins
>> wrote:
>>>
>>> A common tactic is to use grep twice:
>>> ps auxf | grep -v grep | grep blah
>>
>> Or grep with brackets:
>>
>> ps aux | grep '[f]irefox'
>>
>> I have a function for this:
>>
>> psgrep() {
>> ps aux | grep "[${1:0:1}]${1:1}";
>> }
>>
>> This works because the ps output will have "grep [f]irefox" and the
>> regex can't match that line (without escaping the [] again).
>
> Or just use pgrep, I usually use pgrep - fa.
>
Ah, that is what I was looking for
thx,
James
Re: [gentoo-user] 'if echo hello' in .bashrc
On 8 May 2009, at 14:38, Stroller wrote: ... if echo hello|grep --color=auto l >/dev/null 2>&1; then export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32' fi I'm afraid this thread has run away from me. I'm drinking the day's first cup of tea & rubbing my eyes furiously in confusion. Wha? I'm sure I'll comprehend the discussion better when I re-read later. However, is there actually any need to parse whether the grep supports colour before setting it? Let's say we use BSD grep or Schilling grep or whatever - is there actually any harm in exporting GREP_OPTIONS='--color=auto' in this case? Having written the above (so I might as well now send this message) it occurred to me to test it: $ GREP_OPTIONS='--not-suported' $ grep -i rabbit Alice\ in\ Wonderland.txt grep: unrecognized option '--not-suported' Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. $ Presumably BSD grep & all other greps also support the GREP_OPTIONS environment variable? Stroller
Re: [gentoo-user] 'if echo hello' in .bashrc
Hi Alan, Am Freitag, 8. Mai 2009 schrieb Alan McKinnon: > > Some greps (like BSD one) might not support '--color' option, so "echo > > hello|grep --color=auto l" will return error code, skipping if clause, > > and won't break grep operation by adding an unsupported option. is this really right? The result of if echo hello|grep --Acolor=auto l >/dev/null 2>&1; then echo hallo; fi is nothing. So the if clause is false although I pieped STDERR to /dev/null. > except that STDERR is combined with STDOUT and sent to /dev/null so the > script will never get it, the if is always true and the entire check is > redundant. Better would be > > if echo hello|grep --color=auto l >/dev/null ; then grep writes to STDERR if an error is occured. The result of if echo hello|grep --Acolor=auto l >/dev/null ; then echo hallo; fi is: grep: Unbekannte Option »--Acolor=auto« Aufruf: grep [OPTION]... MUSTER [DATEI]... »grep --help« gibt Ihnen mehr Informationen. Best regard Christian
Re: [gentoo-user] Bash query OT
On Sunday 09 July 2006 13:33, Dave S wrote: > chkrootkit -q\ > > | grep -v 'PACKET SNIFFER(/sbin/dhclient3'\ > | grep -v '/usr/lib/jvm/.java-gcj.jinfo'\ > | grep -v '/usr/lib/realplay-10.0.6/share/default/.realplayerrc'\ > | grep -v '/usr/lib/jvm/java-1.5.0-sun-1.5.0.06/.systemPrefs'\ > | grep -v '/usr/lib/jvm/.java-1.5.0-sun.jinfo'\ > | grep -v '/usr/lib/mindi/rootfs/root/.profile'\ > | grep -v '/usr/lib/mindi/rootfs/proc/.keep'\ > | > > $OUTFILE 2> /dev/null You could use egrep -v "/usr/lib/jvm/blah|/usr/lib/reaplay/blah|etc|etc" > val1=$(wc -l < $OUTFILE) > > if [ $val1 -ge 3 ] ; then > cat $OUTFILE | mail -s "[ckrootkit] Daily run" root > fi > > rm -f $OUTFILE > > > All works as expected except the 2> /dev/null appears not to work. I get > the following emailed to me ... chrootkit is sending output to STDERR, but you're sending STDERR from the last grep to /dev/null -- Mike Williams -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Rkhunter now showing Warnings for two files: /bin/egrep & fgrep
On Mon, Jan 26, 2015 at 6:21 PM, Tanstaafl
wrote:
> Hello all,
>
> Been on rkhunter 1.4.2 for a while, no changes made to its config file,
> been running nightly for years without these warnings...
>
> I recently did some Gentoo updates after almost 2 months of no updates
> (was out of town), and now, even after running --propupd, I continue to
> get these warnings:
>
> > # grep Warning /var/log/rkhunter.log
> > [03:10:32] Info: Emailing warnings to 'root' using command '/bin/mail
> -s "[rkhunter] Warnings found for ${HOST_NAME}"'
> > [03:10:45] /bin/egrep [ Warning ]
> > [03:10:45] Warning: The command '/bin/egrep' has been replaced by a
> script: /bin/egrep: POSIX shell script, ASCII text executable
> > [03:10:45] /bin/fgrep [ Warning ]
> > [03:10:45] Warning: The command '/bin/fgrep' has been replaced by a
> script: /bin/fgrep: POSIX shell script, ASCII text executable
>
> Anyone know if this is due to something changing in Gentoo?
>
> As stated in the previous response to your original thread, /bin/[ef]grep
come with the grep package:
file `equery -q f grep|grep /bin/`
/bin/egrep: POSIX shell script, ASCII text executable
/bin/fgrep: POSIX shell script, ASCII text executable
/bin/grep: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.16,
stripped
The shell scripts in question call the grep binary with the flags shown
below:
grep exec /bin/[ef]grep
/bin/egrep:exec $grep -E "$@"
/bin/fgrep:exec $grep -F "$@"
[gentoo-user] chrony seems to ignore configuration file
Hello.
I'd like to use net-misc/chrony-1.21-r1 on a ~x86 system to
keep my system time "correct". My chrony.conf contains:
[EMAIL PROTECTED] ~ $ grep -v ^\# /etc/chrony/chrony.conf|sort|uniq|grep -v
^\!|grep -v ^%|grep -v ^\;
cmdallow 127.0.0.1
commandkey 1
driftfile /etc/chrony/chrony.drift
keyfile /etc/chrony/chrony.keys
logdir /var/log/chrony
log measurements statistics tracking
rtcdevice /dev/misc/rtc
rtcfile /etc/chrony/chrony.rtc
rtconutc
server 0.ch.pool.ntp.org
server 1.ch.pool.ntp.org
server 2.ch.pool.ntp.org
server 3.ch.pool.ntp.org
When I now run "chronyc tracking", I get:
[EMAIL PROTECTED] ~ $ chronyc tracking
Reference ID: 0.0.0.0 (0.0.0.0)
Stratum : 0
Ref time (UTC) : Thu Jan 1 00:00:00 1970
System time : 0.00 seconds fast of NTP time
Frequency : 0.000 ppm fast
Residual freq : 0.000 ppm
Skew: 0.000 ppm
Root delay : 0.00 seconds
Root dispersion : 0.00 seconds
Also quite interesting is the output of "sources":
[EMAIL PROTECTED] ~ $ chronyc sources
210 Number of sources = 0
MS Name/IP address Stratum Poll LastRx Last sample
I had a closer look at chrony, as I discovered in the morning
that my system is 105 seconds fast - and it still IS fast:
[EMAIL PROTECTED] ~ $ ntpdate -q ch.pool.ntp.org
server 194.88.212.205, stratum 3, offset -105.866018, delay 0.03728
server 195.216.64.208, stratum 2, offset -105.870447, delay 0.03851
server 217.147.223.78, stratum 2, offset -105.869263, delay 0.03853
server 213.3.26.5, stratum 3, offset -105.864887, delay 0.08418
10 Mar 21:05:03 ntpdate[13878]: step time server 195.216.64.208 offset
-105.870447 sec
Now, as the "chronyc sources" printed "number of sources = 0",
I tend to think, that the configuration file is ignored.
[EMAIL PROTECTED] ~ $ grep -v ^\# /etc/conf.d/chronyd | grep -v ^\$
CFGFILE="/etc/chrony/chrony.conf"
ARGS="-r -s"
test -c /dev/rtc && {
grep -q '^rtcfile' "${CFGFILE}" && ARGS="${ARGS} -s"
}
grep -q '^dumponexit$' "${CFGFILE}" && ARGS="${ARGS} -r"
[EMAIL PROTECTED] ~ $ ps awux|grep -v vim|grep -v grep|grep -v tail|grep chrony
root 13997 0.0 0.1 1956 888 ?S21:07 0:00
/usr/sbin/chronyd -f /etc/chrony/chrony.conf -r -s -s
Does chrony work for you? Do I have chrony misconfigured?
Thanks,
Alexander Skwar
--
Quack!
Quack!! Quack!!
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] pants
On AD 2007 January 10 Wednesday 06:21:10 AM +0100, Bo V|GV|Grsted Andresen
wrote:
> # grep -R "PANTS=ON" /etc/bash /etc/profile* /etc/env.d ~/.bash* ~/.profile
Or better yet,
# find /etc -type f -exec grep -nI --color PANTS {} \;
$ ls -d --color=no ~/.??* | xargs -i find {} -type f -exec grep -nI --color
PANTS {} \;
OR
$ find ~ | grep "\.\/\." | xargs grep -nI --color PANTS
OR
$ find ~ -mindepth 1 -wholename './.*' | xargs -r grep -nI --color PANTS
Yeah, maybe I'm just showing off by now. (-:
Justin
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Rkhunter now showing Warnings for two files: /bin/egrep & fgrep
On Mon, Jan 26, 2015 at 11:21 AM, Tanstaafl wrote:
> Hello all,
>
> Been on rkhunter 1.4.2 for a while, no changes made to its config file,
> been running nightly for years without these warnings...
>
> I recently did some Gentoo updates after almost 2 months of no updates
> (was out of town), and now, even after running --propupd, I continue to
> get these warnings:
>
>> # grep Warning /var/log/rkhunter.log
>> [03:10:32] Info: Emailing warnings to 'root' using command '/bin/mail
> -s "[rkhunter] Warnings found for ${HOST_NAME}"'
>> [03:10:45] /bin/egrep [ Warning ]
>> [03:10:45] Warning: The command '/bin/egrep' has been replaced by a
> script: /bin/egrep: POSIX shell script, ASCII text executable
>> [03:10:45] /bin/fgrep [ Warning ]
>> [03:10:45] Warning: The command '/bin/fgrep' has been replaced by a
> script: /bin/fgrep: POSIX shell script, ASCII text executable
>
> Anyone know if this is due to something changing in Gentoo?
>
Well, for the 'not updated recently enough' baseline:
~ $ eix grep -I
[I] sys-apps/grep
Available versions: 2.16 ~2.20 ~2.20-r1 ~2.21 {nls pcre static}
Installed versions: 2.16(20:37:55 04/11/14)(nls pcre -static)
Homepage:http://www.gnu.org/software/grep/
Description: GNU regular expression matcher
~ $ file /bin/*grep
/bin/egrep: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped
/bin/fgrep: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped
/bin/grep: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped
~ $ ls -l /bin/*grep
-rwxr-xr-x 1 root root 208096 Apr 11 2014 /bin/egrep
-rwxr-xr-x 1 root root 105472 Apr 11 2014 /bin/fgrep
-rwxr-xr-x 1 root root 212256 Apr 11 2014 /bin/grep
-
And after a quick update:
~ $ eix grep -I
[I] sys-apps/grep
Available versions: 2.16 ~2.20 ~2.20-r1 ~2.21 2.21-r1 {nls pcre static}
Installed versions: 2.21-r1(11:28:57 01/26/15)(nls pcre -static)
Homepage:http://www.gnu.org/software/grep/
Description: GNU regular expression matcher
~ $ file /bin/*grep
/bin/egrep: POSIX shell script, ASCII text executable
/bin/fgrep: POSIX shell script, ASCII text executable
/bin/grep: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped
~ $ ls -l /bin/*grep
-rwxr-xr-x 1 root root158 Jan 26 11:28 /bin/egrep
-rwxr-xr-x 1 root root158 Jan 26 11:28 /bin/fgrep
-rwxr-xr-x 1 root root 154856 Jan 26 11:28 /bin/grep
--
Poison [BLX]
Joshua M. Murphy
Re: [gentoo-user] Is grep broken?
Peter Humphrey a écrit : Hello list, Can anyone explain this to me? $ /bin/grep -r hmenu *html index.html: master.html: pictures.html: $ /bin/grep -r hmenu pages/*html pages/community.html: pages/contacts.html: pages/history.html: pages/music.html: pages/news.html: pages/people.html: pages/pictures.html: Grep is clearly disobeying the recursion command. I started noticing this a few days ago, and it's making maintenance of this directory hard work. As other have pointed out, the behaviour of grep is correct in the examples above. You could use the --include directive : grep -r --include=*html hmenu . Basically, this tells grep to recursive look for hmenu in any files that include *html starting from the current directory (* would be equally fine if you didn't want to search in 'hidden' dot directories). Regards, Carlos
[gentoo-user] Re: copy a bunch of files...
Mark Knecht writes: >> locate Correlation | grep Builder | grep csv | while read file; do >> cp "$file" ~mark/CorrelationTests; done Just a minor point that would simplify the cmd by one cmd call. You could use awk instead of 2 calls to grep. It might be a tiny bit slower... but I doubt it would be noticeable at the proposed scale. awk is basic tool on linux for cmd line work... its quite a bit more powerful than grep, but of course more complicated. In this case though it would be a simple awk cmd. Instead of locate Correlation | grep Builder | grep csv | [...] You could use: locate Correlation | awk '/Builder/ && /cvs/'| [...] That should weed out the same files as the double call to grep
Re: [gentoo-user] empty cdrom drive is busy or mounted
On Thu, Aug 22, 2019 at 5:48 AM james wrote: > On 8/16/19 12:44 PM, Jack wrote: > > ps auxf | grep systemd > > This is new turf for me. Upon issuing this command string I get:: > > # ps auxf | grep systemd > root 24947 0.0 0.0 13964 996 pts/6S+ 15:43 0:00 > | | | \_ grep --colour=auto systemd > This is showing that the only process with systemd in its name is the grep command itself; you could pass anything to grep and it will be found in the process list, eg; $ ps auxf | grep blah adam 52359 0.0 0.0 7708 940 pts/3S+ 09:55 0:00 \_ grep --colour=auto blah So, there's no systemd process running on this system.
Re: [gentoo-user] Bash query OT
On Sun, 9 Jul 2006 13:33:23 +0100, Dave S wrote: > I have written a script in /etc/cron.daily for chkrootkit to screen out > known suspect files that are OK & to email me with anthing else ... > (ahem its not a gentoo system ... just thought I should come clean :)) > > #!/bin/sh > > # Adds a primitive filter of repeating false positives > > OUTFILE=`mktemp` || exit 1 > > chkrootkit -q\ > | grep -v 'PACKET SNIFFER(/sbin/dhclient3'\ > | grep -v '/usr/lib/jvm/.java-gcj.jinfo'\ > | grep -v '/usr/lib/realplay-10.0.6/share/default/.realplayerrc'\ > | grep -v '/usr/lib/jvm/java-1.5.0-sun-1.5.0.06/.systemPrefs'\ > | grep -v '/usr/lib/jvm/.java-1.5.0-sun.jinfo'\ > | grep -v '/usr/lib/mindi/rootfs/root/.profile'\ > | grep -v '/usr/lib/mindi/rootfs/proc/.keep'\ > > $OUTFILE 2> /dev/null > > val1=$(wc -l < $OUTFILE) > > if [ $val1 -ge 3 ] ; then > cat $OUTFILE | mail -s "[ckrootkit] Daily run" root > fi > > rm -f $OUTFILE > > > All works as expected except the 2> /dev/null appears not to work. You are redirecting the output of grep, not chkrootkit. Try chkrootkit -q 2>/dev/null | grep -v -f chkroot.filter >$OUTFILE with the patterns in chkroot.filter (this won't affect the error you mentioned, but it makes things a lot easier to read). -- Neil Bothwick ISDN: It Still Does Nothing signature.asc Description: PGP signature
[gentoo-user] Problem emerging bluefish
Hello list, While playing around with "equery check" as mentioned here the other day, I found myself remerging BlueFish. It fails with an error: [...] CREATED bluefish.xml Making all in images Making all in man Making all in po grep: ./LINGUAS: No such file or directory grep: ./LINGUAS: No such file or directory grep: ./LINGUAS: No such file or directory grep: ./LINGUAS: No such file or directory grep: ./LINGUAS: No such file or directory grep: ./LINGUAS: No such file or directory grep: ./LINGUAS: No such file or directory grep: ./LINGUAS: No such file or directory Making all in src Making all in pixmaps Making all in plugin_about Making all in po *** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.17 but the autoconf macros are from gettext version 0.18 [...] So I remerged gettext and autoconf: $ sudo emerge -1q =sys-devel/autoconf-2.13 =sys-devel/autoconf-2.65 =sys-devel/gettext-0.18 bluefish but got the same error. I haven't come across this problem before, and Google and Bugzilla don't help. I had run emerge -e world only last night. Anyone here have any clues? -- Rgds Peter.
Re: [gentoo-user] [OT] Which openoffice
On Monday 05 May 2008, Willie Wong wrote:
> Since we've come this far, I really want to know what is
> your virtual p*n*s length:
>
> echo `uptime|grep days|sed 's/.*up \([0-9]*\) day.*/\1\/10+/'; cat
> /proc/cpuinfo|grep '^cpu MHz'|awk '{print $4"/30 +";}';free|grep
> '^Mem'|awk '{print $3"/1024/3+"}'; df -P -k -x nfs -x smbfs | grep -v
> '1024-blocks' | awk '{if ($1 ~ "/dev/(scsi|sd)"){ s+= $2} s+= $2;}
> END {print s/1024/50"/15 +70";}'`|bc|sed 's/\(.$\)/.\1cm/'
nazgul screenlets-0.0.2 # echo `uptime|grep days|sed 's/.*up \([0-9]*\)
day.*/\1\/10+/'; cat /proc/cpuinfo|grep '^cpu MHz'|awk '{print $4"/30
+";}';free|grep '^Mem'|awk '{print $3"/1024/3+"}'; df -P -k -x nfs -x
smbfs | grep -v '1024-blocks' | awk '{if ($1 ~ "/dev/(scsi|sd)"){ s+=
$2} s+= $2;} END {print s/1024/50"/15 +70";}'`|bc|sed 's/\(.$\)/.\1cm/'
67.1cm
Fascinating, most fascinating. I get 67.1cm! Longer than yours!
Now, this command of your. Wazzitdo?
--
Alan McKinnon
alan dot mckinnon at gmail dot com
--
gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] is a nice "place" :-D
On 2011/05/17 01:33 (GMT+0200) Alan McKinnon composed:
grep "GET /Tmp/Linux/G" | /var/log/apache2/access_log | grep-v | \
awk '{print $1}' | sort | uniq | wc
In true grand Unix tradition you cannot get quicker, dirtier or more effective
than that
It almost worked too. :-)
grep "GET /Tmp/Linux/G" /var/log/apache2/access_log | grep -v |
\
awk '{print $1}' | sort | uniq | wc -l
got me almost what I wanted, 20 unique IPs, but that's a lot of stuff to
remember, which for me will never happen. So I tried converting to an alias.
grep "GET $1" | /var/log/apache2/access_log | grep -v | \
awk '{print $1}' | sort | uniq | wc -l
sort of works, except I won't always be looking for GET as part of what to
grep for, or might require more than one whitepsace instance, and am tripping
over how to deal with the whitespace if I leave GET out of the alias and only
put on cmdline if I actually want it as part of what to grep for.
grep "GET $1 $2" | /var/log/apache2/access_log | grep -v | \
awk '{print $1}' | sort | uniq | wc -l
seems to work, but I'm not sure there aren't booby traps besides 2nd or more
whitespace instances I'm not considering, even though it gets the same answer
for this particular case.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
Re: [gentoo-user] Excellent Paludis interview
Richard Marzan <[EMAIL PROTECTED]> writes:
> May i have that script? I assume it's GPLed :-)
Honestly, calling it a script is an embellishment.
Perhaps phrasing it as 'something that keeps the faster moving parts of
configuration in sync' would have been better.
echo '*/* x86' > /etc/paludis/keywords.conf
grep -h -v \# /etc/portage/package.keywords/* | grep \/ | awk -F" " '{print $1
" x86 ~x86"}' | sort -u >> /etc/paludis/keywords.conf
cat /etc/paludis/package_mask.conf | grep -v '::' | grep -v '#' | sort -u >
/etc/portage/package.mask/paludis
cat /etc/paludis/package_unmask.conf | grep -v '::' | grep -v '#' | sort -u >
/etc/portage/package.unmask/paludis
cat /etc/paludis/use.conf | grep -v '::' | grep -v '\*\/\*' | grep -v '#' |
sort -u > /etc/portage/package.use/paludis
That's all there is to it, and it makes a lot of assumptions: that
you've already configured both paludis and portage, that you consider
/etc/paludis authoritative on everything but package.keywords, that
you're running a mixed x86 and ~x86 system, and probably others I can't
spot. You also have to sync the global use flags by hand in make.conf
ans use.conf, as well as manage adding/removing overlays by hand, and it
won't touch CFLAGS settings either, etc.
Another thing to keep in mind is that if you package unmask/mask a
package from a certain repository only with cat/pkg::repo, portage won't
know about it and probably not do what you want.
János Zsitvai
--
[EMAIL PROTECTED] mailing list
[gentoo-user] Re: EAPI-6 dev-python ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/21/2016 01:31 PM, James wrote: > David M. Fellows unb.ca> writes: > > >> grep -r -l "EAPI=5" * |grep 'ebuild$' > > grep -r -l "EAPI=6" * |grep 'ebuild$' > > > yep, it works just fine. sorry for being a bit brain-dead this > am... > > > thx, James > For future reference, this would be a bit more efficient: grep -r -l --include="*.ebuild" "EAPI=6" . This way, grep only looks at the files you want to search anyway. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJW8fKGAAoJEEIQbvYRB3mgD0QP/0bfBiRldtoZRWQTxuolVnIF eF0EIxGzY2DAqcg8W/YHEoa0Wk5ohRJw6efISi463ZDAixRwy7lAqS1fsxc+JVJj 4AzKE/j+RNzO1F41PmXXMe2iaRQwm2cz1HNguok44whpUrm7ouj1y9iB0jbChi99 2i64EmsicySes4sh3KBtcqTz8x0rKtOI2cVtz13guDQlbQ8CFQFfNz5bJphvxJWw /gVT6W4Rpx/eHyJhizWqjqVpPSnd3UuAz2aO3GwTmx6eLCzHMjgZ+yTzU/KTDwQd GVvFPf8eDWFyes67V2NvBJlDvYJWZrb0izv28gi3CanGmty5TMWka0V4e/1mHfNt Ga7sCG8xbM2cCYHeMtrjG2ny/Swjhy1jvqZKG7ENOFI41/clVIcV17xcb79YZZhn 4e6PEYTleX61iNdiFFJ3+qkKjP8SxL2IeGLpLzN+iBj0coqkpLkjmC9KKvKcXWqs M6fL9IoNTI7kVpSc5PFpbtcpXmG1ZGtbLM2hQpaER2a8WIux+NxJWRp517cisP0Q 5rwjnbImdtZEBqbld6GZlxVOKTLISQDI1YNrpIiex7rUzxO03wFPBADGdZ9yql3X fbMLGmStCVeK1QAa0WvxGOmcwP5BL0qEQAauMz7jOpsmHkEiF20WMjYiIXo8qUWm VtBDE7xbF7V/sN+trt9e =S5hB -END PGP SIGNATURE-
Re: [gentoo-user] Insane load on gentoo server - possibly clamassassin related?
Steve wrote: $ ps auwx | grep clamscan | grep -v grep | wc -l 42 $ ps auwx | grep procmail | grep -v grep | wc -l 94 $ ps auwx | grep clamassassin | grep -v grep | wc -l 55 -- The first few lines from top say: -- PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 15451 usr 20 0 35944 33m 872 D 2.7 3.3 0:00.60 clamscan 216 root 15 -5 000 S 0.7 0.0 0:03.80 kswapd0 15116 usr 20 0 76136 15m 668 D 0.7 1.6 0:03.30 clamscan 15299 usr 20 0 2584 1224 840 R 0.7 0.1 0:04.36 top 15428 usr 20 0 61288 57m 872 D 0.7 5.7 0:01.38 clamscan 1 root 20 0 1648 196 172 S 0.0 0.0 0:00.64 init 2 root 15 -5 000 S 0.0 0.0 0:00.00 kthreadd -- The procmail configuration I've adopted hasn't changed in years... -- DEFAULT=$HOME/.maildir/ SHELL=/bin/sh MAILDIR=$HOME/.maildir :0fw * < 1024000 | /usr/bin/clamassassin | /usr/bin/spamc -f -- Might be bug in clamd/spamassassin. But it could also be you are being mail-bombed (e.g. infinite depth of compressed-in-compressed attachements). I recommend to include some limit for number of clamd/spamassassin instances. Don't know if procmail has such a capability, but it is easy to control it with wrappers like amavisd-new or MailScanner... Jarry -- ___ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted.
Re: [gentoo-user] net-wireless/zd1211 -> configuring kernel
Hi! first, sorry for breaking the threat... I did find ZD1211RW: Symbol: ZD1211RW [=n] │ │ Prompt: ZyDAS ZD1211/ZD1211B USB-wireless support │ │ Defined at drivers/net/wireless/zd1211rw/Kconfig:1 │ │ Depends on: NETDEVICES && !S390 && USB && IEEE80211_SOFTMAC && WLAN_80211 && EXPERIMENTAL│ │ Location: │ │ -> Device Drivers │ │ -> Network device support (NETDEVICES [=y]) │ │ -> Wireless LAN │ │ Selects: WIRELESS_EXT && FW_LOADER But it does not appear in my kernel options. Looking for dependencies: [EMAIL PROTECTED] ~ $ grep NETDEVICES /usr/src/.config |grep -v "^#" CONFIG_NETDEVICES=y NOT S390 [EMAIL PROTECTED] ~ $ grep S390 /usr/src/.config |grep -v "^#" [EMAIL PROTECTED] ~ $ grep USB /usr/src/.config |grep -v "^#" CONFIG_USB=y [EMAIL PROTECTED] ~ $ grep IEEE80211_SOFTMAC /usr/src/.config # CONFIG_IEEE80211_SOFTMAC is not set Symbol: IEEE80211_SOFTMAC_DEBUG [=n] │ │ Prompt: Enable full debugging output │ │ Defined at net/ieee80211/softmac/Kconfig:10 │ │ Depends on: NET && !S390 && IEEE80211_SOFTMAC │ │ Location: │ │ -> Networking │ │ -> Networking support (NET [=y]) │ │ -> Wireless │ │ -> Generic IEEE 802.11 Networking Stack (IEEE80211 [=y]) │ │ -> Software MAC add-on to the IEEE 802.11 networking stack (IEEE80211_SOFTMAC [=y])│ │ │ │ │ │ Symbol: IEEE80211_SOFTMAC [=y] │ │ Prompt: Software MAC add-on to the IEEE 802.11 networking stack │ │ Defined at net/ieee80211/softmac/Kconfig:1 │ │ Depends on: NET && !S390 && IEEE80211 && EXPERIMENTAL │ │ Location: │ │ -> Networking │ │ -> Networking support (NET [=y]) │ │ -> Wireless │ │ -> Generic IEEE 802.11 Networking Stack (IEEE80211 [=y]) │ │ Selects: WIRELESS_EXT && IEEE80211_CRYPT_WEP [EMAIL PROTECTED] ~ $ grep WLAN_80211 /usr/src/.config # CONFIG_WLAN_80211 is not set │ Symbol: WLAN_80211 [=y] │ │ Prompt: Wireless LAN (IEEE 802.11) │ │ Defined at drivers/net/wireless/Kconfig:109 │ │ Depends on: !S390 && NETDEVICES │ │ Location: │ │ -> Device Drivers
Re: [gentoo-user] OT - grep: The -P option is not supported
On Wednesday 25 October 2006 20:51, Michael Sullivan wrote: [SNIP] > cat * | grep -Po "\[\d+\.\d+\.\d+\.\d+\]" ;) http://www.ruhr.de/home/smallo/award.html > It worked fine right up until this afternoon. Now I get this: > > [EMAIL PROTECTED] ~/spam $ cat * | grep -Po "\[\d+\.\d+\.\d+\.\d+\]" > grep: The -P option is not supported > [EMAIL PROTECTED] ~/spam $ [SNIP] My guess would be that you need to enable a pcre use flag for sys-apps/grep. -- Bo Andresen pgpcgrLxQVMMC.pgp Description: PGP signature
Re: [gentoo-user] Is grep broken?
On Wednesday 01 July 2009 16:30:26 Peter Humphrey wrote: > Hello list, > > Can anyone explain this to me? > > $ /bin/grep -r hmenu *html > index.html: > master.html: > pictures.html: The star is evaluated /before/ grep is executed. Therefore, only files that are ending with html are searched recursively. If you had placed the files in a directory called blablahtml, then grep would have searched there. > $ /bin/grep -r hmenu pages/*html > pages/community.html: > pages/contacts.html: > pages/history.html: > pages/music.html: > pages/news.html: > pages/people.html: > pages/pictures.html: > > Grep is clearly disobeying the recursion command. I started noticing this a > few days ago, and it's making maintenance of this directory hard work. No, you just did not tell it to search in the the directory pages. :) HTH Patrick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: EAPI-6 dev-python ebuilds
David M. Fellows unb.ca> writes: > grep -r -l "EAPI=5" * |grep 'ebuild$' grep -r -l "EAPI=6" * |grep 'ebuild$' yep, it works just fine. sorry for being a bit brain-dead this am... thx, James
Re: [gentoo-user] [OT] Which openoffice
Am Montag, 5. Mai 2008 22:00:37 schrieb Willie Wong:
>
> echo `uptime|grep days|sed 's/.*up \([0-9]*\) day.*/\1\/10+/'; cat
> /proc/cpuinfo|grep '^cpu MHz'|awk '{print $4"/30 +";}';free|grep
> '^Mem'|awk '{print $3"/1024/3+"}'; df -P -k -x nfs -x smbfs | grep -v
> '1024-blocks' | awk '{if ($1 ~ "/dev/(scsi|sd)"){ s+= $2} s+= $2;}
> END {print s/1024/50"/15 +70";}'`|bc|sed 's/\(.$\)/.\1cm/'
fixed some bugs:
echo `uptime|sed 's/.*up\s*\([0-9]*\).*/\1\/10+/';grep '^cpu
MHz' /proc/cpuinfo|awk '{print $4"/30+";}';free|grep '^Mem'|awk '{print
$3"/1024/3+"}';df -P -k -x nfs -x smbfs|awk '{if ($1 ~ "/dev/(scsi|
sd)"){ s+= $2} s+= $2;} END {print s/1024/50"/15+70";}'`|sed 's/,/./'|
bc|sed 's/\(..$\)/.\1cm/'
Regards,
Joe User
--
gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] 'if echo hello' in .bashrc
On 08.05.2009 17:10, Alan McKinnon wrote: >>>if echo hello|grep --color=auto l >/dev/null 2>&1; then >>> export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32' >>>fi >>> >>> to ~/.bashrc >>> >>> Why does he echo hello, please? >> Some greps (like BSD one) might not support '--color' option, so "echo >> hello|grep --color=auto l" will return error code, skipping if clause, >> and won't break grep operation by adding an unsupported option. > > except that STDERR is combined with STDOUT and sent to /dev/null so the > script > will never get it, the if is always true and the entire check is redundant. > Better would be > > if echo hello|grep --color=auto l >/dev/null ; then No. We do not want any output from echo|grep. We just want the exit code so that the following export statement gets executed iff grep returns with no errors. -- Eray
[gentoo-user] Re: Is grep broken?
On 2009-07-01, Peter Humphrey wrote: > Can anyone explain this to me? > > $ /bin/grep -r hmenu *html > index.html: > master.html: > pictures.html: The shell expands *html to a list of html files in the current directory. IOW, you explicitly gave grep a list of html files to search. The -r flag does nothing in that case. You appear to want to search all files underneath the current directory who's name matches the shell glob pattern "*html". If that's the case, then what you meant to say was: find . -name '*html' | xargs grep hmenu > $ /bin/grep -r hmenu pages/*html > pages/community.html: > pages/contacts.html: > pages/history.html: > pages/music.html: > pages/news.html: > pages/people.html: > pages/pictures.html: > > Grep is clearly disobeying the recursion command. I started noticing this a > few days ago, and it's making maintenance of this directory hard work. Again, you gave grep an explicit list of files to search, so the -r option doesn't do anything. In this case, it's not obvious what you intend, so I'll refrain from guessing. -- Grant Edwards grante Yow! I want to kill at everyone here with a cute visi.comcolorful Hydrogen Bomb!!
Re: [gentoo-user] Upgrading from gcc-3.4.5 to gcc-3.4.6-r1
Benno Schulenberg wrote: Darren Grant wrote: # gcc-config 1 * Switching native-compiler to x86_64-pc-linux-gnu-3.4.5 ... [ ok ] # env | grep 'GCC_SPECS=' ...nothing. Log back in first. Environment is set when bash starts. Benno Ok... logged out and back in... env | grep 'GCC' ... returns nothing. env | grep 'gcc' MANPATH=/usr/local/share/man:/usr/share/man:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.16.1/man:/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.5/man PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/3.4.5 INFOPATH=/usr/share/info:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.16.1/info:/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.5/info grep GCC_SPECS /etc/env.d/* /etc/profile* ~/.bash* ~/.profile* /etc/env.d/05gcc:GCC_SPECS="" /etc/profile.csh:setenv GCC_SPECS='' /etc/profile.env:export GCC_SPECS='' /root/.bash_history:unset GCC_SPECS && emerge --oneshot glibc /root/.bash_history:grep GCC_SPECS /etc/env.d/* /etc/profile* ~/.bash* ~/.profile* /root/.bash_history:grep GCC_SPECS /etc/env.d/* /etc/profile* ~/.bash* ~/.profile* /root/.bash_history:grep GCC_SPECS /etc/env.d/* /etc/profile* ~/.bash* ~/.profile* /root/.bash_history:env | grep 'GCC_SPECS' /root/.bash_history:env | grep 'GCC_SPECS=' grep: /root/.profile*: No such file or directory -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: Kernel updates
* On 30.10.2005 Qian Qiao wrote: >>> # cat /var/lib/portage/world> grep sys-kernel I have corrupted your command, but realized it too late, sorry. You originally have written: >>> # cat /var/lib/portage/world | grep sys-kernel >> UUOC > > I stand corrected. grep sys-kernel < /var/lib/portage/world is a neater way. You don't need the less-than here. grep can work directly on the file. % grep sys-kernel /var/lib/portage/world So long, tkr -- You know you're using the computer too much when: You try and use wget to pick up that pizza. -- snakattak3 signature.asc Description: PGP signature
Re: [gentoo-user] Which process is using port 5060 ?
fire-eyes wrote: netstat -anp | grep :5060 More useful would be lsof (emerge lsof) lsof -n | grep :5060 Why do you say, that lsof is more useful? [EMAIL PROTECTED] ~/Desktop $ sudo netstat -anp | grep 514 udp0 0 0.0.0.0:514 0.0.0.0:* 7050/syslog-ng [EMAIL PROTECTED] ~/Desktop $ lsof -n | grep :514 [EMAIL PROTECTED] ~/Desktop $ sudo lsof -n | grep :514 [EMAIL PROTECTED] ~/Desktop $ So, with my test case, netstat returned me the program which is listening on port 514/udp. lsof showed nothing. Alexander Skwar -- Polymer physicists are into chains. -- gentoo-user@gentoo.org mailing list
[gentoo-user] Choosing --param l2-cache-size
>From https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87444 it appears that l2-cache-size is a misnomer; "A comment in driver-i386.c says: /* Let the L3 replace the L2. This assumes inclusive caches and single threaded program for now. */ if (level3.sizekb) level2 = level3;" "Probably the --param should be renamed to last-level-cache". So for the CPUs below that means L3. For the CPUs i have handy; AMD 3900X $ lscpu | grep '[23] cache' L2 cache: 6 MiB (12 instances) L3 cache: 64 MiB (4 instances) AMD FX-8350 $ lscpu | grep '[23] cache' L2 cache: 8 MiB (4 instances) L3 cache: 8 MiB (1 instance) Intel i5-1340P $ lscpu | grep '[23] cache' L2 cache: 9 MiB (6 instances) L3 cache: 12 MiB (1 instance) What is gcc using when using -march=native? (I use distcc so cant use =native). AMD 3900X $ gcc -v -E -x c -march=native -mtune=native - < /dev/null 2>&1 | grep cc1 | sed 's/--param/\n--param/g' | grep '^--param l2-' | cut -d' ' -f1,2 --param l2-cache-size=512 >>> so this is the l2 size divided by the number of instances, 6MB / 12 = 512 AMD FX-8350 $ gcc -v -E -x c -march=native -mtune=native - < /dev/null 2>&1 | grep cc1 | sed 's/--param/\n--param/g' | grep '^--param l2-' | cut -d' ' -f1,2 --param l2-cache-size=2048 >>> so this is the l2 size divided by the number of instances, 8MB / 4 = 2MB Intel i5-1340P $ gcc -v -E -x c -march=native -mtune=native - < /dev/null 2>&1 | grep cc1 | sed 's/--param/\n--param/g' | grep '^--param l2-' | cut -d' ' -f1,2 --param l2-cache-size=12288 >>> this is the l3 size So i'm thinking the Intel CPU l2-cache-size is correct but; for the FX-8350 it should be l3 / instances, ie 8192 / 1 = 8192 for the 3900X it should be l3 / instances, ie 65536 / 4 = 16384 Am I correct? Thanks
Re: [gentoo-user] 'if echo hello' in .bashrc
* Carlos Hendson (skyc...@gmx.net) wrote: > [1] The reason an error message is shown here is because it's bash > that's reporting the broken pipe error. Grep's error message was > redirected to /dev/null, which was: > > grep: unrecognized option '--unsupported' > Usage: grep [OPTION]... PATTERN [FILE]... > Try `grep --help' for more information. > > So even when the system doesn't support --color, that original code will > pollute the screen with bash's error message. SIGPIPE behaviour depends on the shell, how it was built and its configuration so won't always receive an error. The point of this mail however is that there is still a way around it, just call the commands within a subshell. Compare: $ (echo hello | grep --colour l >/dev/null 2>&1) && echo colour support colour support $ (echo hello | grep --broken_arg l >/dev/null 2>&1) && echo broken_arg support with the original non-subshell'd version: $ echo hello | grep --broken_arg l >/dev/null 2>&1 && echo broken_arg support -bash: echo: write error: Broken pipe Thanks, James pgpekrCaEfOdK.pgp Description: PGP signature
Re: [gentoo-user] 'if echo hello' in .bashrc
On Saturday 9 May 2009, 12:15, Stroller wrote: > On 8 May 2009, at 14:38, Stroller wrote: > > ... > > if echo hello|grep --color=auto l >/dev/null 2>&1; then > >export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32' > > fi > > I'm afraid this thread has run away from me. I'm drinking the day's > first cup of tea & rubbing my eyes furiously in confusion. Wha? > I'm sure I'll comprehend the discussion better when I re-read later. > However, is there actually any need to parse whether the grep supports > colour before setting it? > > Let's say we use BSD grep or Schilling grep or whatever - is there > actually any harm in exporting GREP_OPTIONS='--color=auto' in this > case? Yes, because if the grep implementation in question supports GREP_OPTIONS but doesn't support --color, you'll get errors when it's run. (The assumption the author made is that if --color is supported, then GREP_OPTIONS is too, which is reasonable and is what happens for GNU grep, although I cannot speak for other implementations).
[gentoo-user] Is grep broken?
Hello list, Can anyone explain this to me? $ /bin/grep -r hmenu *html index.html: master.html: pictures.html: $ /bin/grep -r hmenu pages/*html pages/community.html: pages/contacts.html: pages/history.html: pages/music.html: pages/news.html: pages/people.html: pages/pictures.html: Grep is clearly disobeying the recursion command. I started noticing this a few days ago, and it's making maintenance of this directory hard work. -- Rgds Peter
[gentoo-user] Re: OT: python, accounting & gentoo
Michael Mol gmail.com> writes: > euse -i tk|grep python > euse -i python|grep tk > euse -i gtk|grep python eix -S -c | grep python get's them all. However, I was looking for some voice of experience or wisdomatic comment on the myriad of choices to possible start testing. Maybe some similar software exist? trudging onward thx, James
Re: [gentoo-user] copy a bunch of files...
Am 08.02.2011 19:27, schrieb Mark Knecht: > Hi, >Looking for a simple way to do a big copy at the command line. I > have a bunch of files (maybe 100 right now, but it will grow) that I > can find with locate and grep: > > c2stable ~ # locate Correlation | grep Builder | grep csv > /home/mark/Builder/TF/TF.D-17M-2009_06-2010_11/Correlation/TF.D-17M-2009_06-2010_11-V1.csv > /home/mark/Builder/TF/TF.D-17M-2009_06-2010_11/Correlation/TF.D-17M-2009_06-2010_11-V2.csv > /home/mark/Builder/TF/TF.D-17M-2009_06-2010_11/Correlation/TF.D-17M-2009_06-2010_11-V3.csv > > /home/mark/Builder/TF/TF.D-31M-2009_06-2010_11/Correlation/TF.D-31M-2009_06-2010_11-V4.csv > /home/mark/Builder/TF/TF.D-31M-2009_06-2010_11/Correlation/TF.D-31M-2009_06-2010_11-V5.csv > c2stable ~ # > >I need to copy these files to a new directory > (~mark/CorrelationTests) where I will modify what's in them before > running correlation tests on the contents. > >How do I feed the output of the command above to cp at the command > line to get this done? > >I've been playing with things like while & read but I can't get it right. > > Thanks, > Mark > locate Correlation | grep Builder | grep csv | xargs -IARG cp ARG ~mark/CorrelationTests -IARG tells xargs to replace the occurrence of ARG in the parameters with the actual parameters read from stdin. or locate Correlation | grep Builder | grep csv | while read file; do cp "$file" ~mark/CorrelationTests; done BTW: Wouldn't grep 'Builder/.*\.csv' match better (some intermediate directory Builder, ending on .csv)? Even easier: locate ~mark/'*/Builder/*.csv' | xargs -IARG cp ARG ~mark/CorrelationTests Warning: I've not tested every line. Use with caution. Hope this helps, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] 'if echo hello' in .bashrc
On 9 May 2009, at 11:41, Etaoin Shrdlu wrote: ... Let's say we use BSD grep or Schilling grep or whatever - is there actually any harm in exporting GREP_OPTIONS='--color=auto' in this case? Yes, because if the grep implementation in question supports GREP_OPTIONS but doesn't support --color, you'll get errors when it's run. (The assumption ... is that if --color is supported, then GREP_OPTIONS is too, which is reasonable and is what happens for GNU grep, although I cannot speak for other implementations). So this keeps the .bashrc compatible with older versions of GNU grep. That hadn't occurred to me. My question is: Do BSD & other greps also support GREP_OPTIONS ? Stroller.
Re: [gentoo-user] Is grep broken?
On Wednesday 01 July 2009 16:30:26 Peter Humphrey wrote: > Hello list, > > Can anyone explain this to me? > > $ /bin/grep -r hmenu *html > index.html: > master.html: > pictures.html: > > $ /bin/grep -r hmenu pages/*html > pages/community.html: > pages/contacts.html: > pages/history.html: > pages/music.html: > pages/news.html: > pages/people.html: > pages/pictures.html: > > Grep is clearly disobeying the recursion command. I started noticing this a > few days ago, and it's making maintenance of this directory hard work. You equally clearly do not understand how recursion works. You told it to grep through all the html files starting from pages/ and it did so. You did not tell it to start from pages/.. so why do you think it should do so? -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] dispatch-conf spells disaster-RESOLVED
On Monday 16 October 2006 22:53, maxim wexler wrote: > But where is CONFIG_PROTECT_MASK, since grepping > make.conf only returns the one line, CONFIG_PROTECT? Looking at the output of the following commands should answer your question. # env | grep ^CONFIG_PROTECT # find /etc/env.d | xargs grep CONFIG_PROTECT # grep CONFIG_PROTECT /etc/profile.env # grep -A 1 profile.env /etc/profile -- Bo Andresen pgpFGPZt5JJJ6.pgp Description: PGP signature
Re: [gentoo-user] pants
On 1/9/07, Justin Findlay <[EMAIL PROTECTED]> wrote:
On AD 2007 January 10 Wednesday 06:21:10 AM +0100, Bo V|GV|Grsted Andresen
wrote:
> # grep -R "PANTS=ON" /etc/bash /etc/profile* /etc/env.d ~/.bash* ~/.profile
Or better yet,
# find /etc -type f -exec grep -nI --color PANTS {} \;
$ ls -d --color=no ~/.??* | xargs -i find {} -type f -exec grep -nI --color
PANTS {} \;
OR
$ find ~ | grep "\.\/\." | xargs grep -nI --color PANTS
OR
$ find ~ -mindepth 1 -wholename './.*' | xargs -r grep -nI --color PANTS
Yeah, maybe I'm just showing off by now. (-:
Justin
--
gentoo-user@gentoo.org mailing list
Thanks for the responses.
None of the grepping found anything sadly, and no one else uses this
box. It's my home workstation.
I dropped out of Xorg and noticed that it wasn't in my env any more.
Installed fluxbox and fired it up and behold, PANTS is not set.
A quick google for "enlightenment pants" was quite..enlightening.
Thanks again for all the neat ideas.
--
() The ASCII Ribbon Campaign - against HTML Email,
/\ vCards, and proprietary formats.
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] search files for "text string"
On 08/06/2015 08:05, Raffaele BELARDI wrote: > Volker Armin Hemmann wrote: >> Am 06.06.2015 um 18:45 schrieb Joseph: >>> I've bunch of php files in many directories and I need to file a text >>> string in them "Check/Money Order" >>> >>> I've tried: >>> find -type f -print0 | xargs -r0 grep -F 'Check/Money Order' >>> it doesn't work. >>> >>> What is a better method of searching files? >> >> grep -R 'whateveryourarelookingfor /path/to/directory/tree/ >> >> seriously, why make everything fucking harder with find, when grep alone >> can do it for you? >> > > I'm not the OP but I was not able to make 'grep -R' work properly with > file or directory names containing spaces. I fiddled with IFS but in the > end I found 'find -print0' was more convenient. Are there better methods > with grep and shell alone? > > raffaele > grep deals with spaces in directory and file names just fine. If you want to specify directory or file names on the command line that contain spaces, you must quote them. Standard shell technique. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Firefox not killing processes on close
On 11/11/13 at 01:44am, Dale wrote: > Yohan Pereira wrote: > > On 10/11/13 at 08:07pm, Walter Dnes wrote: > >> [i660][waltdnes][~] ps -ef | grep firefox > >> waltdnes 28696 11663 2 19:35 pts/22 00:00:07 firefox > >> waltdnes 28836 28825 0 19:39 pts/30 00:00:00 grep --color=auto firefox > >> > >> Only one Firefox process exists. (I can't seem to prevent the grep > >> command from listing itself). > > Try this hack :) > > > > $ ps -ef | grep [u]rxvt > > yohan 3559 1 0 11:50 ?00:00:00 urxvt > > yohan 3667 1 0 11:52 ? 00:00:00 urxvt > > > > That one didn't return anything. I got plenty of output without the > grep tho. Sort of close to what I usually get with ps aux. > > Dale I'm sorry, that was a hack to prevent grep from listing it self in the ps out-put, nothing to do with your problem specifically, should've made that clear :). -- - Yohan Pereira The difference between a Miracle and a Fact is exactly the difference between a mermaid and a seal. -- Mark Twain
[gentoo-user] Insane load on gentoo server - possibly clamassassin related?
Today my gentoo server that has sat happily churning my mundane (and lightweight) tasks froze and I noticed when it stopped serving DNS queries... and the server was even unresponsive from the command prompt. I rebooted and was a bit taken aback at what I found. The server currently runs, but has a load of over 60, where I'd expect a load of below 0.1. Investigations using top did not suggest that a single process was using vast amounts of processing time... but there were significantly more clamascan processes than I'd expect... and even more procmail processes -- $ ps auwx | grep clamscan | grep -v grep | wc -l 42 $ ps auwx | grep procmail | grep -v grep | wc -l 94 $ ps auwx | grep clamassassin | grep -v grep | wc -l 55 -- The first few lines from top say: -- PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 15451 usr 20 0 35944 33m 872 D 2.7 3.3 0:00.60 clamscan 216 root 15 -5 000 S 0.7 0.0 0:03.80 kswapd0 15116 usr 20 0 76136 15m 668 D 0.7 1.6 0:03.30 clamscan 15299 usr 20 0 2584 1224 840 R 0.7 0.1 0:04.36 top 15428 usr 20 0 61288 57m 872 D 0.7 5.7 0:01.38 clamscan 1 root 20 0 1648 196 172 S 0.0 0.0 0:00.64 init 2 root 15 -5 000 S 0.0 0.0 0:00.00 kthreadd -- The procmail configuration I've adopted hasn't changed in years... -- DEFAULT=$HOME/.maildir/ SHELL=/bin/sh MAILDIR=$HOME/.maildir :0fw * < 1024000 | /usr/bin/clamassassin | /usr/bin/spamc -f -- I'm assuming that my suddenly starting to have problems with this is something to do with an update to clamd/clamassassin... I've a vague recollection that one or the other of them might have been updated when I last synchronised and emerged updates... but I can't remember. Any ideas? This isn't a heavily loaded server usually - I've more procmail processes than I usually receive in emails in an hour. Something's wrong - can anyone offer any hints? Has anyone else run into this problem? Is there a known 'quick fix'?
Re: [gentoo-user] search files for "text string"
Volker Armin Hemmann wrote: > Am 06.06.2015 um 18:45 schrieb Joseph: >> I've bunch of php files in many directories and I need to file a text >> string in them "Check/Money Order" >> >> I've tried: >> find -type f -print0 | xargs -r0 grep -F 'Check/Money Order' >> it doesn't work. >> >> What is a better method of searching files? > > grep -R 'whateveryourarelookingfor /path/to/directory/tree/ > > seriously, why make everything fucking harder with find, when grep alone > can do it for you? > I'm not the OP but I was not able to make 'grep -R' work properly with file or directory names containing spaces. I fiddled with IFS but in the end I found 'find -print0' was more convenient. Are there better methods with grep and shell alone? raffaele
Re: [gentoo-user] Firefox not killing processes on close
On Mon, 11 Nov 2013 09:35:11 -0500, gottl...@nyu.edu wrote: > I'll leave the heavy listing to alan, but to avoid listing the grep, I > believe you want > > ps -ef | grep firefox | grep -v grep I see a lot of wheels being reinvented... -- Neil Bothwick NOTE: In order to control energy costs the light at the end of the tunnel has been shut off until further notice... signature.asc Description: PGP signature
Re: [gentoo-user] hostname service on lxc
Hi Nils, rc_sys from /etc/rc.conf is empty, but after removing -lxc from /etc/init.d/hostname the service is well started. Thanks! So, for the record: as112 ~ # grep rc_sys /etc/rc.conf #rc_sys="" as112 ~ # grep keyword /etc/init.d/hostname keyword -docker -lxc -prefix -systemd-nspawn as112 ~ # vim /etc/init.d/hostname as112 ~ # rc-status boot | grep hostname hostname [ started ] as112 ~ # grep keyword /etc/init.d/hostname keyword -docker -prefix -systemd-nspawn as112 ~ # Cheers, -- Alarig
Re: [gentoo-user] Firefox not killing processes on close
Yohan Pereira wrote: > On 10/11/13 at 08:07pm, Walter Dnes wrote: >> [i660][waltdnes][~] ps -ef | grep firefox >> waltdnes 28696 11663 2 19:35 pts/22 00:00:07 firefox >> waltdnes 28836 28825 0 19:39 pts/30 00:00:00 grep --color=auto firefox >> >> Only one Firefox process exists. (I can't seem to prevent the grep >> command from listing itself). > Try this hack :) > > $ ps -ef | grep [u]rxvt > yohan 3559 1 0 11:50 ?00:00:00 urxvt > yohan 3667 1 0 11:52 ?00:00:00 urxvt > That one didn't return anything. I got plenty of output without the grep tho. Sort of close to what I usually get with ps aux. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] emerge output
On 2005-08-26 01:48:36 +0200 (Fri, Aug), Holly Bostick wrote: > Idea #3: there is a way (and possibly more than one) to tail out the > einfo messages, either to a file, or to the console, but unfortunately I > don't remember what they are atm Oh, wait, they're listed on the Wiki: > > http://gentoo-wiki.com/TIP_Portage_utilities_not_in_portage > > I think what you might want is portlog-info, which is in the > Informational Utilities section. ...or something dumber^H^H^H^H^Hsimpler: # --- #!/bin/bash COUNT=60 cd /var/log/portage || exit -1 for file in $( ls -1rt | tail -n $COUNT) do if grep $'\e' "$file" | grep -q -v -e " Applying [^ ]*.patch" -e $'\e'"\[32;01mok"$'\e'"\[34;01m" then tput bold echo ' ----' ls -l "$file" echo ' ' tput sgr0 grep $'\e' "$file" | grep -v " Applying [^ ]*.patch" fi done # --- The log files are created when you set the PORT_LOGDIR in /etc/make.conf (yeah, you replace then that "cd /var/log/portage" with your - possibly different - location, or do something like eval $(grep "^PORT_LOGDIR=" /etc/make.conf)) . HTH -- No virus found in this outgoing message. Checked by 'grep -i virus $MESSAGE' Trust me. pgp1eTIxDSzsw.pgp Description: PGP signature
[gentoo-user] Re: Re: Re: Home Network Printing
Richard Fish wrote: > On 11/30/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > wrote: >> Are you running cups? > > And if so, post the output of: > > grep -v "^#" /etc/cups/cupsd.conf | grep -v "^$" > > for both systems. Thanks Richard, this is what I get from box 1 (this is the client): = # grep -v "^#" /etc/cups/cupsd.conf | grep v "^$" DocumentRoot /usr/share/cups/docs LogLevel debug2 MaxCopies 10 MaxJobs 70 MaxJobsPerPrinter 30 MaxJobsPerUser 30 User lp Group lp Listen 127.0.0.1:631 MaxClients 10 Browsing Off SystemGroup lp Order Deny,Allow Deny From All Allow From 127.0.0.1 AuthType Basic AuthClass System Order Deny,Allow Deny From All Allow From 127.0.0.1 = This is what I get from host 2 (the server): = # grep -v "^#" /etc/cups/cupsd.conf | grep -v "^$" DocumentRoot /usr/share/cups/docs LogLevel info User lp Group lp Port 631 SystemGroup lp IfRequested - Use encryption if the server requests it Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 192.168.0.2 Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 192.168.0.2 AuthType Basic AuthClass System Order Deny,Allow Deny From All Allow From 127.0.0.1 = Any wrong entries? -- Regards, Mick -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: bash upgrading problem
On 21/01/2019 20:25, Jacques Montier wrote: Le lun. 21 janv. 2019 à 19:04, Nikos Chantziaras <mailto:rea...@gmail.com>> a écrit : I can't see why "emerge -uv bash" would ever invoke sudo. So I'd say that you should first find out what command is being executed with sudo. To do that, try to emerge bash, and when the sudo prompt pops up, switch to another terminal window and do: ps aux | grep sudo What's the output of that? ps aux | grep sudo 267:root 19845 0.0 0.0 54260 4304 pts/0 S+ 19:23 0:00 sudo eix-update Well, something is trying to execute a "sudo eix-update". The bash ebuild certainly doesn't, so you should check your installation for any weird scripts or aliases you might be using. A grep on /etc for "eix-update" might also reveal something: grep -r eix-update /etc And also check your env and aliases: which emerge alias | grep emerge env | grep eix These are general hints on where to look, since I have no clue myself as to why an "emerge -uv bash" would ever try and execute "sudo eix-update", so it seems you have digging to do.
Re: [gentoo-user] search files for "text string"
On 06/06/15 20:09, Alexander Kapshuk wrote: On Sat, Jun 6, 2015 at 7:45 PM, Joseph <[1]syscon...@gmail.com> wrote: I've bunch of php files in many directories and I need to file a text string in them "Check/Money Order" I've tried: find -type f -print0 | xargs -r0 grep -F 'Check/Money Order' it doesn't work. What is a better method of searching files? -- Joseph grep -ls 'Check/Money Order' `du -a | sed '/\.php$/!d;s/.*\t//'` # grep will complain that the args list is too long if the number of files found is too great. Otherwise, this might work for you: find dir -type f -name \*.php | xargs grep -sl 'Check/Money Order' Thanks, this worked for me, it searches in current and below dir. find -type f -print0 | xargs -r0 grep -F 'Check/Money Order' -- Joseph
[gentoo-user] Cannot mount USB stick using Dolphin
Both consolekit and polkit are running. What could be the problem? $ ps axf | grep polkit 8961 pts/1SN+0:00 \_ grep --color=auto polkit 5678 ?Sl 0:00 /usr/libexec/polkitd $ ps axf | grep console 5594 ?Ssl0:00 /usr/sbin/console-kit-daemon 9088 pts/1SN+0:00 \_ grep --color=auto console I'm starting e17 WM running startx on this box, unlike another similarly configured machine where mounting devices works fine but I start that with /etc/init.d/xdm (kdm). -- Regards, Mick
Re: [gentoo-user] dispatch-conf spells disaster-RESOLVED?
> If you really have an empty CONFIG_PROTECT, > dispatch-conf didn't touch > this file, it was replaced during emerge. You must > fix this before > emerging anything else or you will overwrite more > config files. > > What do > emerge --info | grep CONFIG > and > grep CONFIG /etc/make.conf > show? localhost heathen # emerge --info | grep CONFIG CONFIG_PROTECT="" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/terminfo" localhost heathen # grep CONFIG /etc/make.conf CONFIG_PROTECT="-*" __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- gentoo-user@gentoo.org mailing list
[gentoo-user] bash script question
I want to use an if/then that tests for the existence of a string in 4 files. Usually I do this by checking the exit code of grep, when i'm checking a single file. However, I cant get the syntax right for multiple checks. To troubleshoot I’ve dropped back to just checking two files, and i’ve tried things like If [ $(grep blah file1.txt) –a $(grep blah file2.txt) ]; then But this matches if grep fails both times as well as when it matches both time. Any ideas?
Re: [gentoo-user] Re: bash upgrading problem
Le lun. 21 janv. 2019 à 14:16, Alexander Kapshuk < alexander.kaps...@gmail.com> a écrit : > > > What is the output of: > env | grep libsandbox.so > > There is no output of env | grep libsandbox.so, but with env | grep sandbox, i get this : $ env | grep sandbox 13:CONFIG_PROTECT_MASK=/etc/sandbox.d /etc/php/cli-php7.2/ext-active/ /etc/php/cgi-php7.2/ext-active/ /etc/php/apache2-php7.2/ext-active/ /etc/fonts/fonts.conf /etc/gentoo-release /etc/gconf /etc/terminfo /etc/dconf /etc/ca-certificates.conf /etc/revdep-rebuild -- Jacques
Re: [gentoo-user] 'if echo hello' in .bashrc
On Friday 08 May 2009 16:59:19 Etaoin Shrdlu wrote: > On Friday 8 May 2009, 16:10, Alan McKinnon wrote: > > On Friday 08 May 2009 16:01:14 Mike Kazantsev wrote: > > > On Fri, 8 May 2009 14:38:58 +0100 > > > > > > Stroller wrote: > > > > To find the part to which I refer you'll need to scroll down about > > > > halfway through that page to "Colorize grep"; the author advises > > > > adding: > > > > > > > >if echo hello|grep --color=auto l >/dev/null 2>&1; then > > > > export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32' > > > >fi > > > > > > > > to ~/.bashrc > > > > > > > > Why does he echo hello, please? > > > > > > Some greps (like BSD one) might not support '--color' option, so > > > "echo hello|grep --color=auto l" will return error code, skipping if > > > clause, and won't break grep operation by adding an unsupported > > > option. > > > > except that STDERR is combined with STDOUT and sent to /dev/null so > > the script will never get it, the if is always true and the entire > > check is redundant. Better would be > > > > if echo hello|grep --color=auto l >/dev/null ; then > > That will output an uncaptured error message if --color is not supported. which is the desired effect. It causes the if to be false and the grep options are not enabled (as they are not supported) -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] kernel 2.6.12-r9 : sensors don't work
On Thu, 01 Sep 2005 21:48:50 +0200, Holly Bostick wrote: > Or... since you know (sometimes) which of such packages need to be > re-emerged, and you also know when you have upgraded your kernel, you > *could* just write a (one line) script to re-emerge the relevant > packages, throw it in /usr/sbin or whatever (optional), and run > it after you upgraded a kernel. > > I've been meaning to do that for some time now, since it's much easier > to maintain (you only have to add any new packages the first time you > emerge them, then you're free to forget what you want :) ). Some packages only compile against the running kernel, others use the /usr/src/linux symlink to decide. So I have a few lines in /etc/conf.d/local.start to take care of such re-emerges when I reboot with a new kernel. # Re-emerge NVidia drivers after a kernel compile lsmod | grep --quiet nvidia || grep --quiet softlevel /proc/cmdline || \ (FEATURES="-distcc -buildpkg -sandbox" emerge --oneshot nvidia-kernel && modprobe -v nvidia && /etc/init.d/xdm stop zap start) # Rebuild VMware modules if needed lsmod | grep --quiet vmnet || grep --quiet softlevel /proc/cmdline || /opt/vmware/bin/vmware-config.pl default # Re-emerge fuse lsmod | grep --quiet fuse || FEATURES="-distcc -buildpkg" emerge --oneshot sys-fs/fuse && modprobe -v fuse #Re-emerge wlan-ng if [ ! -f /lib/modules/$(uname -r)/linux-wlan-ng/prism2_usb.ko ] ; then if rc-status -nc | grep -q net\.eth0.*started && ethtool eth0 | grep -q 'Link detected: yes' ; then FEATURES="-distcc -buildpkg" emerge --oneshot linux-wlan-ng fi fi -- Neil Bothwick Southern DOS: Y'all reckon? (Yep/Nope) pgpgx2zZ1HlRr.pgp Description: PGP signature
Re: [gentoo-user] Failed to load driver: Nouveau
iceamber@localhost:~ $ grep NOUVEAU /usr/src/linux/.config CONFIG_DRM_NOUVEAU=m CONFIG_NOUVEAU_DEBUG=5 CONFIG_NOUVEAU_DEBUG_DEFAULT=3 CONFIG_DRM_NOUVEAU_BACKLIGHT=y iceamber@localhost:~ $ grep -E 'nvidia|VIDEO_CARDS' /etc/portage/make.conf VIDEO_CARDS="nouveau" here is the `grep -si nouveau /var/log/*` <https://paste.pound-python.org/show/PhfcfeZzzECTIEw15B3R/> I have rebuilt the xorg-server, it is built for kernel 4.12.5 now. And I have set the USEs of "gallium" and "video_cards_nouveau" On Sun, Aug 27, 2017 at 4:54 PM, Alexander Kapshuk < alexander.kaps...@gmail.com> wrote: > On Sun, Aug 27, 2017 at 5:49 PM, Alexander Kapshuk > wrote: > > On Sun, Aug 27, 2017 at 5:45 PM, Alexander Kapshuk > > wrote: > >> On Sun, Aug 27, 2017 at 2:27 PM, IceAmber > wrote: > >>> I have tried, but the same result > >>> > >>> On Sun, Aug 27, 2017 at 10:04 AM, Adam Carter > wrote: > >>>>> > >>>>> yes, here is the eselect > >>>> > >>>> > >>>> When i have X problems i can resolve i run emerge -av > @x11-module-rebuild > >>>> xorg-server mesa but its generally an act of desperation after > running out > >>>> of intelligent options. > >>> > >>> > >> > >> Your xorg-server was built for kernel 4.9.34. > >> [24.014] Build Operating System: Linux 4.9.34-gentoo x86_64 Gentoo > >> [ 24.014] Current Operating System: Linux localhost 4.12.5-gentoo > >> #10 SMP Sat Aug 26 13:15:20 UTC 2017 x86_64 > >> > >> Might be a good idea to rebuild x11-base/xorg-server for your current > kernel. > >> > >> What's the output of the command lines below? > >> grep NOUVEAU linux/.config > >> grep -E 'nvidia|VIDEO_CARDS' /etc/portage/make.conf > > > > This one too please: > > grep -si nouveau /var/log/* > > Also, let's make sure mesa has the USE flags below enabled: > > equery -q u mesa | grep -E 'gallium|nouveau' > +gallium > +video_cards_nouveau > >
Re: [gentoo-user] emerge -avt xfce4-meta; haven't got startxfce4. Help, please!
firefly ~ # emerge -ep xfce4-meta | grep xfce | grep utils [ebuild R ] xfce-base/xfce-utils-4.6.1 firefly ~ # On Tue, Feb 9, 2010 at 10:36 AM, Mark Knecht wrote: > firefly ~ # which startxfce4 > /usr/bin/startxfce4 > firefly ~ # equery belongs /usr/bin/startxfce4 > [ Searching for file(s) /usr/bin/startxfce4 in *... ] > xfce-base/xfce-utils-4.6.1 (/usr/bin/startxfce4) > firefly ~ # > > m...@firefly ~ $ cat .xinitrc > exec startxfce4 > m...@firefly ~ $ Possibly you installed something other than xfce4-meta? firefly ~ # emerge -ep xfce4-meta | grep xfce | grep utils [ebuild R ] xfce-base/xfce-utils-4.6.1 firefly ~ #
Re: [gentoo-user] copy a bunch of files...
On Tue, Feb 8, 2011 at 11:02 AM, Florian Philipp wrote: > Am 08.02.2011 19:27, schrieb Mark Knecht: >> Hi, >> Looking for a simple way to do a big copy at the command line. I >> have a bunch of files (maybe 100 right now, but it will grow) that I >> can find with locate and grep: >> >> c2stable ~ # locate Correlation | grep Builder | grep csv >> /home/mark/Builder/TF/TF.D-17M-2009_06-2010_11/Correlation/TF.D-17M-2009_06-2010_11-V1.csv >> /home/mark/Builder/TF/TF.D-17M-2009_06-2010_11/Correlation/TF.D-17M-2009_06-2010_11-V2.csv >> /home/mark/Builder/TF/TF.D-17M-2009_06-2010_11/Correlation/TF.D-17M-2009_06-2010_11-V3.csv >> >> /home/mark/Builder/TF/TF.D-31M-2009_06-2010_11/Correlation/TF.D-31M-2009_06-2010_11-V4.csv >> /home/mark/Builder/TF/TF.D-31M-2009_06-2010_11/Correlation/TF.D-31M-2009_06-2010_11-V5.csv >> c2stable ~ # >> >> I need to copy these files to a new directory >> (~mark/CorrelationTests) where I will modify what's in them before >> running correlation tests on the contents. >> >> How do I feed the output of the command above to cp at the command >> line to get this done? >> >> I've been playing with things like while & read but I can't get it right. >> >> Thanks, >> Mark >> > > locate Correlation | grep Builder | grep csv | xargs -IARG cp ARG > ~mark/CorrelationTests > > -IARG tells xargs to replace the occurrence of ARG in the parameters > with the actual parameters read from stdin. > Thanks! This worked nicely and is relatively easy to remember. > or > > locate Correlation | grep Builder | grep csv | while read file; do > cp "$file" ~mark/CorrelationTests; done > This is what I was trying to do but was unsuccessful. > BTW: Wouldn't grep 'Builder/.*\.csv' match better (some intermediate > directory Builder, ending on .csv)? > Yes, that does seem to work. I guess that's grepping for the path of a file starting with Builder and ending with CSV? Good one. > Even easier: > locate ~mark/'*/Builder/*.csv' | xargs -IARG cp ARG ~mark/CorrelationTests > > Warning: I've not tested every line. Use with caution. > > Hope this helps, > Florian Philipp It did very much. Thanks! Now to work on modifying the files, again with a loop for all the files in ~mark/CorrelationTests - Mark
Re: [gentoo-user] 'if echo hello' in .bashrc
On Friday 08 May 2009 16:01:14 Mike Kazantsev wrote: > On Fri, 8 May 2009 14:38:58 +0100 > > Stroller wrote: > > To find the part to which I refer you'll need to scroll down about > > halfway through that page to "Colorize grep"; the author advises adding: > > > >if echo hello|grep --color=auto l >/dev/null 2>&1; then > > export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32' > >fi > > > > to ~/.bashrc > > > > Why does he echo hello, please? > > Some greps (like BSD one) might not support '--color' option, so "echo > hello|grep --color=auto l" will return error code, skipping if clause, > and won't break grep operation by adding an unsupported option. except that STDERR is combined with STDOUT and sent to /dev/null so the script will never get it, the if is always true and the entire check is redundant. Better would be if echo hello|grep --color=auto l >/dev/null ; then -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] 'if echo hello' in .bashrc
On Friday 08 May 2009 16:38:30 Christian wrote: > Hi Alan, > > Am Freitag, 8. Mai 2009 schrieb Alan McKinnon: > > > Some greps (like BSD one) might not support '--color' option, so "echo > > > hello|grep --color=auto l" will return error code, skipping if clause, > > > and won't break grep operation by adding an unsupported option. > > is this really right? > > The result of > > if echo hello|grep --Acolor=auto l >/dev/null 2>&1; then echo hallo; fi > > is nothing. Which is equal to ), which in shell terms is true Yes, it's the opposite to other languages. Yes, it really should be that way. The return value of successful process is by convention 0, which therefore is evaluated as true. Non-zero is false > So the if clause is false although I pieped STDERR to > /dev/null. > > > except that STDERR is combined with STDOUT and sent to /dev/null so the > > script will never get it, the if is always true and the entire check is > > redundant. Better would be > > > > if echo hello|grep --color=auto l >/dev/null ; then > > grep writes to STDERR if an error is occured. > > The result of > > if echo hello|grep --Acolor=auto l >/dev/null ; then echo hallo; fi ^ What's this? I didn't type it. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] 'if echo hello' in .bashrc
Etaoin Shrdlu wrote: > On Saturday 9 May 2009, 12:15, Stroller wrote: > > On 8 May 2009, at 14:38, Stroller wrote: > > > ... > > > if echo hello|grep --color=auto l >/dev/null 2>&1; then > > >export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32' > > > fi > > > > I'm afraid this thread has run away from me. I'm drinking the day's > > first cup of tea & rubbing my eyes furiously in confusion. Wha? > > I'm sure I'll comprehend the discussion better when I re-read later. > > However, is there actually any need to parse whether the grep supports > > colour before setting it? > > > > Let's say we use BSD grep or Schilling grep or whatever - is there > > actually any harm in exporting GREP_OPTIONS='--color=auto' in this > > case? > > Yes, because if the grep implementation in question supports GREP_OPTIONS > but doesn't support --color, you'll get errors when it's run. My "grep" is called "match" and it does not look at environment variables. There are few commands that have codumented (by POSIX) environment variables for options. I think of e.g. "make", that needs this in order to pass options to sub-makes. A safe method in shell scripts is to use lower case variable names. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [SOLVED - MAYBE]: [gentoo-user] pysol problems
On 9/27/06, Bo Ørsted Andresen <[EMAIL PROTECTED]> wrote: # grep -i rgbpath /var/log/Xorg.0.log (==) RgbPath set to "/usr/share/X11/rgb" # equery files x11-apps/rgb | grep rgb.txt /usr/share/X11/rgb.txt # equery check x11-apps/rgb [ Checking x11-apps/rgb-1.0.1 ] * 9 out of 9 files good It seems that at this point both machine look the same. dragonfly was the machine having the problem: [EMAIL PROTECTED] ~ $ su - Password: lightning ~ # grep -i rgbpath /var/log/Xorg.0.log (==) RgbPath set to "/usr/share/X11/rgb" lightning ~ # equery files x11-apps/rgb | grep rgb.txt /usr/share/X11/rgb.txt lightning ~ # equery check x11-apps/rgb [ Checking x11-apps/rgb-1.0.1 ] * 12 out of 12 files good lightning ~ # lightning ~ # ssh dragonfly Password: Last login: Wed Sep 27 08:38:28 2006 from lightning dragonfly ~ # grep -i rgbpath /var/log/Xorg.0.log (==) RgbPath set to "/usr/share/X11/rgb" dragonfly ~ # equery files x11-apps/rgb | grep rgb.txt /usr/share/X11/rgb.txt dragonfly ~ # equery check x11-apps/rgb [ Checking x11-apps/rgb-1.0.1 ] * 12 out of 12 files good dragonfly ~ # I guess the correct solution if it doesn't work without the RgbPath specified is to specify it correctly in xorg.conf... Note that my problem was that I had specified the wrong path. Yes, that was not my situation. Thanks for the help! Cheers, Mark -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] 'if echo hello' in .bashrc
On Fri, 8 May 2009 14:38:58 +0100 Stroller wrote: > To find the part to which I refer you'll need to scroll down about > halfway through that page to "Colorize grep"; the author advises adding: > >if echo hello|grep --color=auto l >/dev/null 2>&1; then > export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32' >fi > > to ~/.bashrc > > Why does he echo hello, please? Some greps (like BSD one) might not support '--color' option, so "echo hello|grep --color=auto l" will return error code, skipping if clause, and won't break grep operation by adding an unsupported option. -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature
Re: [gentoo-user] somebody using x11-drm?
=== On Thursday 24 April 2008, Florian Philipp wrote: === ... > > Yep, I'm using it (and the kernel module) and I get the same output > of "dmesg | grep drm" > > If I remember correctly, only =x11-base/x11-drm-20071019 worked for > me (at least there was a reason for me to put it > in /etc/portage/package.keywords) How to determine "drm works"? 'dmesg | grep drm' out is: [drm] Initialized drm 1.1.0 20060810 [drm] Initialized i915 1.6.0 20060119 on minor 0 'lsmod | grep drm' out is: drm92648 3 i915 and 'lspci | grep -i vga' out is: 00:02.0 VGA compatible controller: Intel Corporation 82G965 Integrated Graphics Controller (rev 02) Andrew -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Grep question
On Mon, 2 Mar 2009 13:01:31 +1100 Adam Carter wrote: > I need to select all the lines between string1 and string2 in a file. String1 > exists on an entire line by itself and string2 will be at the start of a > line. What's the syntax? I cant use -A as there is a variable number of lines. I doubt there's a solution involving grep, unless you use it twice in the same pipe: grep -A string1 /some/file | grep -B string2 But there can be any amount of more elegant solutions, involving sed: sed -n '/string1/,/string2/p' /some/file -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature
[gentoo-user] Re: How's the openrc update going for everyone?
On 05/11/2011 06:53 PM, Nikos Chantziaras wrote: On 05/11/2011 06:42 PM, Dale wrote: That was quick: root@fireball / # grep LC_ALL /etc/env.d/* root@fireball / # Guess that is not in env.d anywhere. :/ Then I guess you can create it on your own. See: http://www.gentoo.org/doc/en/guide-localization.xml#doc_chap3 Heh, according to the guide I linked to, setting LC_ALL is a bad idea :-D So I guess the grep should have been: grep LANG /etc/env.d/* And the contents of 02locale (or something else in case the grep above finds some other *locale file) should be: LANG="en_US.UTF-8" LC_COLLATE="C"
[gentoo-user] Lost SCSI support
When I try to mount camera or USB stick I get:
mount: /dev/sda1 is not a valid block device
No SCSI support from kernel (using Kernel 2.6.14-4r)
Doing dmesg |grep sd (I only get):
dmesg |grep sd
Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]).
In Kernel I have enabled:
Device Drivers
SCSI device support --->
[*] legacy /proc/scsi/ support
<*> SCSI disk support
<*> SCSI generic support
USB support --->
[*] USB device filesystem
<*> EHCI HCD (USB 2.0) support
<*> UHCI HCD (most Intel and VIA) support
<*> USB Mass Storage support
cat /usr/src/linux/.config | grep SCSI | grep =
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y
CONFIG_SCSI_QLA2XXX=y
Where else to look?
--
#Joseph
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] search files for "text string"
On Sat, Jun 6, 2015 at 7:45 PM, Joseph wrote: > I've bunch of php files in many directories and I need to file a text > string in them "Check/Money Order" > > I've tried: > find -type f -print0 | xargs -r0 grep -F 'Check/Money Order' > it doesn't work. > > What is a better method of searching files? > -- > Joseph > > grep -ls 'Check/Money Order' `du -a | sed '/\.php$/!d;s/.*\t//'` # grep will complain that the args list is too long if the number of files found is too great. Otherwise, this might work for you: find dir -type f -name \*.php | xargs grep -sl 'Check/Money Order'
Re: [gentoo-user] Firefox not killing processes on close
On 10/11/13 at 08:07pm, Walter Dnes wrote: > [i660][waltdnes][~] ps -ef | grep firefox > waltdnes 28696 11663 2 19:35 pts/22 00:00:07 firefox > waltdnes 28836 28825 0 19:39 pts/30 00:00:00 grep --color=auto firefox > > Only one Firefox process exists. (I can't seem to prevent the grep > command from listing itself). Try this hack :) $ ps -ef | grep [u]rxvt yohan 3559 1 0 11:50 ?00:00:00 urxvt yohan 3667 1 0 11:52 ?00:00:00 urxvt -- - Yohan Pereira The difference between a Miracle and a Fact is exactly the difference between a mermaid and a seal. -- Mark Twain
Re: [gentoo-user] problems with usb audio and midi
On Thursday 24 Apr 2014 17:32:25 luis jure wrote: > > lspci | grep OHCI should show if you need it. > > mmm... lspci | grep OHCI gives nothing, so i guess i'll disable these > modules in the kernel. Oops! I gave a bum steer, my apologies! I meant to have typed: lspci -v | grep -i OHCI As an example, this is what my firewire is using: # lspci -v | grep -i OHCI 09:00.3 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 PCIe IEEE 1394 Controller (rev 01) (prog-if 10 [OHCI]) Kernel driver in use: firewire_ohci Kernel modules: firewire_ohci HTH. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] 'if echo hello' in .bashrc
On Friday 8 May 2009, 16:10, Alan McKinnon wrote: > On Friday 08 May 2009 16:01:14 Mike Kazantsev wrote: > > On Fri, 8 May 2009 14:38:58 +0100 > > > > Stroller wrote: > > > To find the part to which I refer you'll need to scroll down about > > > halfway through that page to "Colorize grep"; the author advises > > > adding: > > > > > >if echo hello|grep --color=auto l >/dev/null 2>&1; then > > > export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32' > > >fi > > > > > > to ~/.bashrc > > > > > > Why does he echo hello, please? > > > > Some greps (like BSD one) might not support '--color' option, so > > "echo hello|grep --color=auto l" will return error code, skipping if > > clause, and won't break grep operation by adding an unsupported > > option. > > except that STDERR is combined with STDOUT and sent to /dev/null so > the script will never get it, the if is always true and the entire > check is redundant. Better would be > > if echo hello|grep --color=auto l >/dev/null ; then That will output an uncaptured error message if --color is not supported.
Re: [gentoo-user] How to prevent documentation in /usr/share/doc from being bzip2'ed ?
On Thu, Oct 30, 2008 at 5:40 PM, <[EMAIL PROTECTED]> wrote: > On Fri, Oct 31, 2008 at 08:20:40AM +0930, Iain Buchanan wrote: > > > less /usr/share/doc/libxcb/manual/blah.doc.bz2 > > cat /usr/share/doc/libxcb/manual/blah.doc.bz2 | bzip2 -d > > cp /usr/share/doc/libxcb/manual/blah.doc.bz2 ~/; bzip2 -d ~/blah.doc.bz2 > > and grep? You don't need bzgrep or what everjust bzcat /ab/def/sd/blah.bz2 | grep yay Or if you want to use the cases above, a "| grep yay" should be more than enough...plus you get the colors in the results. It does get a little annoying when you want to use grep for all files in the directory, but nothing a little for loop cannot fix: for i in /path/to/dir/*; do echo $i; bzcat $i | grep yay; done > > > -- >... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. > Felix Finch: scarecrow repairman & rocket surgeon / [EMAIL PROTECTED] > GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license > #4933 > I've found a solution to Fermat's Last Theorem but I see I've run out of > room o > >
Re: [gentoo-user] Where is CONFIG_MICROCODE gone in kernel 4.4.6-gentoo?
On Saturday 30 Apr 2016 08:50:55 Alec Ten Harmsel wrote: > On Sat, Apr 30, 2016 at 09:29:08AM +0100, Neil Bothwick wrote: > > On Sat, 30 Apr 2016 09:07:29 +0100, Mick wrote: > > > I seem to have mislaid my microcode somewhere, in the latest stable > > > gentoo kernel: > > > > > > # grep -i MICROCODE .config > > > # > > > > Grepping .config is unreliable, and always has been. > > I usually use something like: > > grep MICROCODE $(find . -name Kconfig) > > Alec # grep -i MICROCODE /boot/config-4.4.6-gentoo # # grep -i MICROCODE .config # # grep MICROCODE $(find . -name Kconfig) ./arch/x86/Kconfig:config MICROCODE ./arch/x86/Kconfig:config MICROCODE_INTEL ./arch/x86/Kconfig: depends on MICROCODE ./arch/x86/Kconfig: default MICROCODE ./arch/x86/Kconfig:config MICROCODE_AMD ./arch/x86/Kconfig: depends on MICROCODE ./arch/x86/Kconfig:config MICROCODE_OLD_INTERFACE ./arch/x86/Kconfig: depends on MICROCODE # Now you see it ... now you don't! I am getting really confused. :-/ Why on this PC the MICROCODE options become available only when I enable INITRD, but on other PCs such a problem does not exist? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Upgrading from gcc-3.4.5 to gcc-3.4.6-r1
Darren Grant wrote:
Benno Schulenberg wrote:
Darren Grant wrote:
# gcc-config 1
* Switching native-compiler to x86_64-pc-linux-gnu-3.4.5
... [ ok ]
# env | grep 'GCC_SPECS='
...nothing.
Log back in first. Environment is set when bash starts.
Benno
Ok... logged out and back in...
env | grep 'GCC' ... returns nothing.
env | grep 'gcc'
MANPATH=/usr/local/share/man:/usr/share/man:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.16.1/man:/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.5/man
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/3.4.5
INFOPATH=/usr/share/info:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.16.1/info:/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.5/info
grep GCC_SPECS /etc/env.d/* /etc/profile* ~/.bash* ~/.profile*
/etc/env.d/05gcc:GCC_SPECS=""
/etc/profile.csh:setenv GCC_SPECS=''
/etc/profile.env:export GCC_SPECS=''
/root/.bash_history:unset GCC_SPECS && emerge --oneshot glibc
/root/.bash_history:grep GCC_SPECS /etc/env.d/* /etc/profile* ~/.bash*
~/.profile*
/root/.bash_history:grep GCC_SPECS /etc/env.d/* /etc/profile* ~/.bash*
~/.profile*
/root/.bash_history:grep GCC_SPECS /etc/env.d/* /etc/profile* ~/.bash*
~/.profile*
/root/.bash_history:env | grep 'GCC_SPECS'
/root/.bash_history:env | grep 'GCC_SPECS='
grep: /root/.profile*: No such file or directory
Back in May I thought I was streamlining my make.conf file by changing
from this...
CFLAGS="-mtune=k8 -O2 -pipe"
CFLAGS="-march=athlon64 -O2 -pipe"
MAKEOPTS="-j3"
CHOST="x86_64-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
USE="session unicode cli pcre xml zlib threads mpm-prefork mysql imap
libwww maildir sasl ssl gnome gtk2 -kde -qt dvdr alsa cdr apache2 nvidia
opengl"
to this...
CFLAGS="-march=athlon64 -mtune=k8 -O2 -pipe"
MAKEOPTS="-j3"
CHOST="x86_64-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
USE="nptl nptlonly session unicode cli pcre xml zlib threads mpm-prefork
mysql imap libwww maildir sasl ssl gnome gtk2 -kde -qt dvdr alsa cdr
apache2 nvidia opengl"
Any chance that's what's causing my gcc problems now?
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] [OT] Which openoffice
On Monday 5 May 2008, 22:12, Alan McKinnon wrote:
> nazgul screenlets-0.0.2 # echo `uptime|grep days|sed 's/.*up
> \([0-9]*\) day.*/\1\/10+/'; cat /proc/cpuinfo|grep '^cpu MHz'|awk
> '{print $4"/30 +";}';free|grep '^Mem'|awk '{print $3"/1024/3+"}'; df
> -P -k -x nfs -x smbfs | grep -v '1024-blocks' | awk '{if ($1 ~
> "/dev/(scsi|sd)"){ s+= $2} s+= $2;} END {print s/1024/50"/15
> +70";}'`|bc|sed 's/\(.$\)/.\1cm/' 67.1cm
>
> Fascinating, most fascinating. I get 67.1cm! Longer than yours!
>
> Now, this command of your. Wazzitdo?
It builds a bc expression, which is then fed to bc and the result is
divided by 10 and has "cm" added to it.
uptime|grep days|sed 's/.*up \([0-9]*\) day.*/\1\/10+/'
This checks the uptime, and outputs "n/10+", where "n" is the uptime in
days. In my case, the expression is "2/10+".
cat /proc/cpuinfo|grep '^cpu MHz'|awk '{print $4"/30 +";}'
This outputs "n/30 +", where "n" is the CPU speed in mhz. In my case
(hyperthreding cpu) it outputs
3000.000/30 +
3000.000/30 +
free|grep '^Mem'|awk '{print $3"/1024/3+"}'
This outputs "n/1024/3+", where "n" is the "used memory" from free's
output. On my desktop, that is "1721716/1024/3+", but obvioulsy it
changes almost every time you run the command. Not sure why the used
memory is used instead of the total.
df -P -k -x nfs -x smbfs | grep -v '1024-blocks' | awk '{if ($1
~ "/dev/(scsi|sd)"){ s+= $2} s+= $2;} END {print s/1024/50"/15
+70";}'
This outputs "n/15 +70", where "n" is the sum of the 1024-blocks as per
df's output (excluding nfs and smbfs file systems), divided by 1024 and
further divided by 50. The block count of /dev/scsi* or /dev/sd* devices
is counted twice (not sure why though). On my system, the output
is "5313.33/15 +70".
So, the final expression fed to bc is
2/10+ 3000.000/30 + 3000.000/30 + 1721716/1024/3+ 5313.33/15 +70
bc does the math, and sed divides the result by 10 and adds "cm" to the
result. For me, that gives 118.4cm.
It would be interesting to know why Willie chose those values, those
scaling factors, and what's the purpose of the constants.
Nice script though! Thanks!
--
gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Insane load on gentoo server - possibly clamassassin related?
On Monday 29 June 2009 19:04:44 Steve wrote: > Today my gentoo server that has sat happily churning my mundane (and > lightweight) tasks froze and I noticed when it stopped serving DNS > queries... and the server was even unresponsive from the command > prompt. I rebooted and was a bit taken aback at what I found. > > The server currently runs, but has a load of over 60, where I'd expect a > load of below 0.1. Investigations using top did not suggest that a > single process was using vast amounts of processing time... but there > were significantly more clamascan processes than I'd expect... and even > more procmail processes.... > > -- > $ ps auwx | grep clamscan | grep -v grep | wc -l > 42 > $ ps auwx | grep procmail | grep -v grep | wc -l > 94 > $ ps auwx | grep clamassassin | grep -v grep | wc -l > 55 > -- > > The first few lines from top say: > > -- > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 15451 usr 20 0 35944 33m 872 D 2.7 3.3 0:00.60 clamscan > 216 root 15 -5 000 S 0.7 0.0 0:03.80 kswapd0 > 15116 usr 20 0 76136 15m 668 D 0.7 1.6 0:03.30 clamscan > 15299 usr 20 0 2584 1224 840 R 0.7 0.1 0:04.36 top > 15428 usr 20 0 61288 57m 872 D 0.7 5.7 0:01.38 clamscan > 1 root 20 0 1648 196 172 S 0.0 0.0 0:00.64 init > 2 root 15 -5 000 S 0.0 0.0 0:00.00 kthreadd > -- > > The procmail configuration I've adopted hasn't changed in years... > -- > DEFAULT=$HOME/.maildir/ > SHELL=/bin/sh > MAILDIR=$HOME/.maildir > > :0fw > > * < 1024000 > > | /usr/bin/clamassassin | /usr/bin/spamc -f > > -- > > I'm assuming that my suddenly starting to have problems with this is > something to do with an update to clamd/clamassassin... I've a vague > recollection that one or the other of them might have been updated when > I last synchronised and emerged updates... but I can't remember. > > Any ideas? This isn't a heavily loaded server usually - I've more > procmail processes than I usually receive in emails in an hour. > Something's wrong - can anyone offer any hints? Has anyone else run > into this problem? Is there a known 'quick fix'? Looks like you have 200 processes sitting there blocking I/O. Is there anything related in the logs? Your best bet is to examine emerge.log (better still - genlop) and find all recent upgrades that might affect this. Then roll them back one by one till the problem goes away. Once you know the errant package, we can start to examine diffs and see why it might behave like that. -- alan dot mckinnon at gmail dot com
[gentoo-user] Better than equery list|grep something
A while back some posted a way to avoid doing: equery list|grep package to get info like version or whatever. It involved limiting what list returned by some method before it gets to grep. Anyone remember or know what it is. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] recompiling vim linked to libncursesw
050727 Richard Fish wrote: > Fernando Canizo wrote: >> $ ldd `which vim` | grep curses >> libncurses.so.5 => /lib/libncurses.so.5 (0xb7f98000) >> $ ldd `which mutt` | grep curses >> libncursesw.so.5 => /lib/libncursesw.so.5 (0xb7f8f000) I too use Mutt + Vim -- ie Gvim -- & sometimes Vim + UTF8 (not with Mutt) & I never have problems. However, my Mutt doesn't seem to use Curses : root: log> ldd `which vim` | grep curses libncurses.so.5 => /lib/libncurses.so.5 (0xb7f9a000) root: log> ldd `which mutt` | grep curses root: log> emerge -pv mutt ... [ebuild R ] mail-client/mutt-1.5.8-r2 -buffysize -cjk +crypt -imap -mbox -nls -nntp -sasl +slang +ssl -vanilla -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] 'if echo hello' in .bashrc
On 8 May 2009, at 15:01, Mike Kazantsev wrote: On Fri, 8 May 2009 14:38:58 +0100 Stroller wrote: To find the part to which I refer you'll need to scroll down about halfway through that page to "Colorize grep"; the author advises adding: if echo hello|grep --color=auto l >/dev/null 2>&1; then export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32' fi to ~/.bashrc Why does he echo hello, please? Some greps (like BSD one) might not support '--color' option, so "echo hello|grep --color=auto l" will return error code, skipping if clause, and won't break grep operation by adding an unsupported option. Ah! I see! Many thanks! Stroller.
Re: [gentoo-user] Re: OT: python, accounting & gentoo
On Fri, Aug 24, 2012 at 2:20 PM, James wrote: > Randolph Maaßen gmail.com> writes: > > >> I cant tell you much about accounting software, but what i know >> is that there are python binding for qt and gtk, just look for >> PyQt4 and pygtk. Another toolkit with bindings i I know about >> is wxWidgets with wxPython. > >> I'm sure, there are bindings for your preferred toolkit. > > OK, I was hoping to avoid going through /usr/portage/dev-python > manually to discover the possible relevant packages euse, combined with grep, will help you greatly. euse -i tk|grep python euse -i python|grep tk euse -i gtk|grep python etc. That's how I'd tackle it. -- :wq
[gentoo-user] OT - Extracting IP addresses with grep
I have a mail directory with several hundred spammish emails that have been collecting over the past month. I haven't gotten around to processing them yet ([EMAIL PROTECTED] if available, blocked if not) I would like to write a script that would extract the IP addresses from all these emails, but I can't figure out how to get grep to cooperate. I created a perl regular expression for matching against IP addresses and tried to pass it to grep, but it wouldn't return anything. I don't know what I'm doing wrong. Here's my command: [EMAIL PROTECTED] ~/.maildir/.SPAM/cur $ cat * | grep -P m/\d+\.\d+\.\d +\.\d+/ -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] uninstall a bunch
On Wed, 2006-05-31 at 17:59 +0200, Rakotomandimby Mihamina wrote:
> Hi,
> I emerged gnome and gdm.
> It installed more than 100 other dependencies.
To be precise, I had to install 283 softwares.
So, I did:
# grep 283 /var/log/emerge.log | grep completed
114911668: completed emerge (1 of 283) dev-libs/glib-2.10.3 to /
[...]
1149116482: completed emerge (7 of 283) virtual/xft-7.0 to /
Then :
# grep 283 /var/log/emerge.log | grep completed \
| awk '{print $8}' > /root/unmerge.txt
Then I just have to loop to unmerge all.
--
A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL).
Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
http://www.cps-project.org for downloads & documentation.
--
gentoo-user@gentoo.org mailing list
RESOLVED: [gentoo-user] emerge output
Neil, Mariusz~ Thanks for the input. Just setting up PORT_LOGDIR has gone a long way to providing exactly what I'm looking for. It's a shame that this isn't setup by default, but I can think of a few reasons why it isn't. John D -Original Message- From: Mariusz Pêkala [mailto:[EMAIL PROTECTED] Sent: Friday, August 26, 2005 4:33 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] emerge output On 2005-08-26 01:48:36 +0200 (Fri, Aug), Holly Bostick wrote: > Idea #3: there is a way (and possibly more than one) to tail out the > einfo messages, either to a file, or to the console, but unfortunately I > don't remember what they are atm Oh, wait, they're listed on the Wiki: > > http://gentoo-wiki.com/TIP_Portage_utilities_not_in_portage > > I think what you might want is portlog-info, which is in the > Informational Utilities section. ...or something dumber^H^H^H^H^Hsimpler: # --- #!/bin/bash COUNT=60 cd /var/log/portage || exit -1 for file in $( ls -1rt | tail -n $COUNT) do if grep $'\e' "$file" | grep -q -v -e " Applying [^ ]*.patch" -e $'\e'"\[32;01mok"$'\e'"\[34;01m" then tput bold echo ' ----' ls -l "$file" echo ' ' tput sgr0 grep $'\e' "$file" | grep -v " Applying [^ ]*.patch" fi done # --- The log files are created when you set the PORT_LOGDIR in /etc/make.conf (yeah, you replace then that "cd /var/log/portage" with your - possibly different - location, or do something like eval $(grep "^PORT_LOGDIR=" /etc/make.conf)) . HTH -- No virus found in this outgoing message. Checked by 'grep -i virus $MESSAGE' Trust me. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Mounting USB sticks automagically.
Mick, On Thursday, 2019-12-19 18:30:47 +, you wrote: > ... > consolekit will work for this purpose - is it running? It should be in your > default runlevel. $ rc-update show|grep consolekit $ Gosh! It's missing! Maybe I just started it to see whether or not it works and then forgot to add it to default. So add and start it now: $ sudo rc-update add consolekit default Password: * service consolekit added to runlevel default $ sudo rc-service consolekit start * Caching service dependencies ... [ ok ] * Starting consolekit ... * start-stop-daemon: /usr/sbin/console-kit-daemon is already running * Failed to start consolekit [ !! ] * ERROR: consolekit failed to start $ ps -ef|grep console rainer3928 12250 0 19:53 pts/0 00:00:00 grep console root 11675 1 0 Dec18 ?00:00:00 /usr/sbin/console-kit-daemon --no-daemon $ So it's not in the default run-level, but it's running anyway? Whazzat? So I decided to reboot and see what happens. But this helped neither with automounting nor with hibernating. The only thing that changed was the command line of the console-kit command: $ ps -ef|grep console root 7320 1 0 Dec19 ?00:00:00 /usr/sbin/console-kit-daemon rainer 32639 10242 0 12:21 pts/000:00:00 grep console $ By the way, these are its USE flags for consolekit, in case it matters: $ eix -l consolekit|grep Installed Installed versions: 1.2.1(15:11:46 22/10/19)(acl pam pm-utils policykit udev -cgroups -debug -doc -evdev -selinux -test KERNEL="linux") $ Sincerely, Rainer
[gentoo-user] How does OpenRC know if a service is crashed?
Hi,
Some times ago, I wrote a basic init script for a service I’m running
but that is not in the tree.
It’s just a python script behind a reverse-proxy.
bulbizarre ~ # cat /etc/init.d/paste-py
#!/sbin/openrc-run
# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#depend() {
#
#}
start() {
start-stop-daemon --start --user pastepy --exec paste-py.sh --name
paste-py
eend $?
}
stop() {
kill $(cat /opt/paste-py/paste.pid)
}
bulbizarre ~ # cat $(which paste-py.sh)
#!/bin/sh
port="$(grep port /opt/paste-py/paste-py.conf | cut -d '=' -f 2)"
addr="$(grep addr /opt/paste-py/paste-py.conf | cut -d '=' -f 2)"
cd /opt/paste-py
source bin/activate
./daemonize.py --port=${port} --addr=${addr}
bulbizarre ~ # cat /opt/paste-py/paste.pid
9480
bulbizarre ~ # ps aux | grep 9480
root 493 0.0 0.0 11440 924 pts/3S+ 11:14 0:00 grep
--colour=auto 9480
pastepy 9480 0.0 0.4 113548 16848 ?S08:05 0:00 python
./daemonize.py --port=8087 --addr=127.0.0.1
So, the process is running (and responding), but OpenRC shows it as
crashed
bulbizarre ~ # rc-status | grep crash
paste-py [ crashed ]
What do I have to change?
Thanks,
--
alarig
[gentoo-user] HOWTO: Freezing/unfreezing (groups of) processes
Thanks for all the help over the years fellow Gentoo'ers. Maybe I can
return the favour. So you've got a bunch of programs like Gnumeric or
QEMU or Pale Moon ( or Firefox or Chrome or Opera ) sessions open, that
are chewing up cpu and ram. You need those resouces for another
program, but you don't want to shut those programs down and lose your
place. If the programs could be frozen, cpu usage would go away, and
memory could be swapped out. Here's a real-life example subset of a
"ps -ef" output on my system. Replace "palemoon" with "firefox" or
"chrome" or whatever browser you're using.
waltdnes 4025 3173 0 Jan20 ?01:54:21
/home/waltdnes/pm/palemoon/palemoon -new-instance -p palemoon
waltdnes 7580 3173 4 Jan21 ?17:45:11
/home/waltdnes/pm/palemoon/palemoon -new-instance -p dslr
waltdnes 9813 3173 4 Jan21 ?16:24:23
/home/waltdnes/pm/palemoon/palemoon -new-instance -p wxforum
waltdnes 22455 3173 58 01:31 ?00:08:29
/home/waltdnes/pm/palemoon/palemoon -new-instance -p slashdot
waltdnes 22523 3173 0 01:31 ?00:00:05
/home/waltdnes/pm/palemoon/palemoon -new-instance -p youtube
waltdnes 22660 3173 12 01:45 ?00:00:04 /usr/bin/gnumeric
/home/waltdnes/worldtemps/temperatures/temperatures.gnumeric
waltdnes 20346 20345 4 Jan28 ?08:10:50 /usr/bin/qemu-system-x86_64
-enable-kvm -runas waltdnes -cpu host -monitor vc -display gtk -drive
file=arcac.img,format=raw -netdev user,id=mynetwork -device
e1000,netdev=mynetwork -rtc base=localtime,clock=host -m 1024 -name ArcaOS VM
-vga std -parallel none
You might want to RTFM on the "kill" command if you're skeptical. It
does a lot more than kill programs. "kill -L" will give you a nicely
formatted list of available signals. For this discussion we're
interested in just "SIGCONT" and "SIGSTOP" ( *NOT* "SIGSTP" ). If I
want to freeze the Slashdot session, I can run "kill -SIGSTOP 22455". To
unfreeze it, I can run "kill -SIGCONT 22455". You can "SIGSTOP" on a
pid multiple times consecutively without problems; ditto for "SIGCONT".
So far, so good, but running "ps -ef | grep whatever" and then
typing the kill -SIGSTOP/SIGCONT command on the correct pid is grunt
work, subject to typos. I've set up a couple of scripts in ~/bin to
stop/continue processes, or groups thereof. The following scripts do a
"dumb grep" of "ps -ef" output, redirecting to /dev/shm/temp.txt. That
file is then read, and the second element of each line is the pid, which
is fed to the "kill" command. I store the scripts as ~/bin/pstop and
~/bin/pcont.
== pstop (process stop) script ==
#!/bin/bash
ps -ef | grep ${1} | grep -v "grep ${1}" | grep -v pstop > /dev/shm/temp.txt
while read
do
inputarray=(${REPLY})
kill -SIGSTOP ${inputarray[1]}
done < /dev/shm/temp.txt
pcont (process continue) script
#!/bin/bash
ps -ef | grep ${1} | grep -v "grep ${1}" | grep -v pcont > /dev/shm/temp.txt
while read
do
inputarray=(${REPLY})
kill -SIGCONT ${inputarray[1]}
done < /dev/shm/temp.txt
=
To stop all Pale Moon instances, execute "pstop palemoon". To stop
only the Slashdot session, run "pstop slashdot". Ditto for the pcont
command. I hope people find this useful.
--
Walter Dnes
I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Re: AMD microcode updates - where are they?!
On Saturday, 13 July 2019 02:13:00 BST Adam Carter wrote: > grep fam /proc/cpuinfo > > -> 21 = 15h > -> 22 = 16h Yep, here's the laptop: $ grep fam -m1 /proc/cpuinfo cpu family : 21 and here's the dekstop: $ grep fam -m1 /proc/cpuinfo cpu family : 21 -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Plasma-runtime compilation problems
Am Mittwoch, 24. August 2011, 23:43:09 schrieb Michael Schreckenbauer:
> Am Mittwoch, 24. August 2011, 23:27:46 schrieb Alex Schuster:
> > wonko@weird ~ $ grep -r /usr/include/plasma/service.h /var/db/pkg/
> > /var/db/pkg/kde-base/kdelibs-4.7.0-r1/CONTENTS:obj
> > /usr/include/plasma/service.h e9ddea9052c900f1f87c57025a0f36f0
> > 1308840546
> >
> > Emulating qfile as a shell function for nicer output:
> >
> > wonko@weird ~ $ myqfile()
> >
> > > {
> > >
> > > grep -r "$1" /var/db/pkg | sed 's#/CONTENTS:.*##g'
> > >
> > > }
> >
> > wonko@weird ~ $ myqfile /usr/include/plasma/service.h
> > /var/db/pkg/kde-base/kdelibs-4.7.0-r1
>
> I would use find and grep -H instead of grep -r
>
> On my system your version greps in
> ~ $ find /var/db/pkg | wc -l
> 33791
Silly me...
Your version greps in
~ $ find /var/db/pkg -type f| wc -l
32527
files.
Michael
Re: [gentoo-user] [OT]: grep -Z not working ???
On 07/18/11 23:12, meino.cra...@gmx.de wrote:
> Hi,
>
> the manual page of grep mentioned the following:
>
> -Z, --null
> Output a zero byte (the ASCII NUL character) instead of the
> character that normally follows a file name. For example, grep -lZ outputs a
> zero byte
> after each file name instead of the usual newline. This option
> makes the output unambiguous, even in the presence of file names containing
> unusual
> characters like newlines. This option can be used with
> commands like find -print0, perl -0, sort -z, and xargs -0 to process
> arbitrary file names,
> even those that contain newline characters.
>
> for me (as a non-native English speak ;) ) this means:
>
> Replace a newlie after a filename with a zero-byte.
>
> So when doing
>
> find /tmp | grep -Z tmp | xargs -0 md5sum
>
> it should work comparable to
>
> find /tmp -print0 | xargs -0 md5sum
>
> but for me it does not.
>
> If my logic is not complete nonsense I dont understand the second
> part of the text of the manual page:
>
>
> This option can be used with commands like find -print0, perl
> -0, sort -z, and xargs -0 to process arbitrary file names,
> even those that contain newline characters.
>
>
> If I would do
>
>
> find /tmp -print0 | grep -Z tmp | xargs -0 md5sum
>
> there are no newlines which could be printed "instead of the character that
> normally follows a file name. For example, grep -lZ outputs a zero byte
> after each file name instead of the usual newline. "
This took me a few minutes to actually figure out exactly what -Z in
supposed to do. But I *think* it does exactly this. Whatever character
comes directly after the filename is replaces by NUL. As you can see in
my example below, the character that normally follows a filename is ':'
(a colon), but with the -Z option, the colon is replace with NUL, this
no 'character' follows it.
~/joe/sullivan $ grep -Z document ./*
./core.js$(document).ready(function() {
./core.js$(document).pngFix();
./core.jsvar map = new
google.maps.Map(document.getElementById("map_of_region"), myOptions);
~/joe/sullivan $ grep document ./*
./core.js:$(document).ready(function() {
./core.js:$(document).pngFix();
./core.js:var map = new
google.maps.Map(document.getElementById("map_of_region"), myOptions);
But please do correct me if I'm wrong.
>
> At this point confusion fills my head and nonsense follows my commands
> on the command line.
>
> What does that all mean?
>
> Thank you very much for any help and de-confusion in advance! :)
>
> Best regards,
> mcc
HTH (and that I'm not totally off track)
- Matt
