Sponsored Content
Full Discussion: grep -v -f xxxxxxx
Top Forums Shell Programming and Scripting grep -v -f xxxxxxx Post 12068 by peter.herlihy on Tuesday 18th of December 2001 03:56:02 PM
Old 12-18-2001
Yeah - that works..... the only thing is that's also a workaround - and I already have one that works - which is probably less of a workaround.

I'm not adverse to using if-else, after all it's valid code and there for a good reason.... and I would think that the if-else I have is more 'pure' code than creation/deletion of a dummy file.

So I'm not all that worried about the if-else - happy to leave it there as it's no more inefficient than other methods you guys have come up with....really just curious about the empty file thing.

I played with that grep -v "" < file and got the same behaviour you suggested....do you know why null string is considered a match to everything else?
 

10 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

MEM=`ps v $PPID| grep -i db2 | grep -v grep| awk '{ if ( $7 ~ " " ) { print 0 } else

Hi Guys, I need to set the value of $7 to zero in case $7 is NULL. I've tried the below command but doesn't work. Any ideas. thanks guys. MEM=`ps v $PPID| grep -i db2 | grep -v grep| awk '{ if ( $7 ~ " " ) { print 0 } else { print $7}}' ` Harby. (4 Replies)
Discussion started by: hariza
4 Replies

2. UNIX for Dummies Questions & Answers

| help | unix | grep - Can I use grep to return a string with exactly n matches?

Hello, I looking to use grep to return a string with exactly n matches. I'm building off this: ls -aLl /bin | grep '^.\{9\}x' | tr -s ' ' -rwxr-xr-x 1 root root 632816 Nov 25 2008 vi -rwxr-xr-x 1 root root 632816 Nov 25 2008 view -rwxr-xr-x 1 root root 16008 May 25 2008... (7 Replies)
Discussion started by: MykC
7 Replies

3. UNIX for Dummies Questions & Answers

| help | unix | grep (GNU grep) 2.5.1 | advanced regex syntax

Hello, I'm working on unix with grep (GNU grep) 2.5.1. I'm going through some of the newer regex syntax using Regular Expression Reference - Advanced Syntax a guide. ls -aLl /bin | grep "\(x\)" Which works, just highlights 'x' where ever, when ever. I'm trying to to get (?:) to work but... (4 Replies)
Discussion started by: MykC
4 Replies

4. Shell Programming and Scripting

grep for certain files using a file as input to grep and then move

Hi All, I need to grep few files which has words like the below in the file name , which i want to put it in a file and and grep for the files which contain these names and move it to a new directory , full file name -C20091210.1000-20091210.1100_SMGBSC3:1000... (2 Replies)
Discussion started by: anita07
2 Replies

5. AIX

"fuser -c -k /XXX/XXXXXXX" Fails and stuck on AIX 6100-05-01-1016

Hi I was wondering if anybody has come across in a failure of fuser command. We have a backup script that is: fuser -c -k /XXX/XXXXXXX sync;sync umount /XXX/XXXXXXX/ backup -0 -f /dev/rmt0.1 -u /dev/XXXXXXXlv mount /XXX/XXXXXXX/ sync;sync The script is called from crontab via an... (2 Replies)
Discussion started by: ggovotsis
2 Replies

6. UNIX for Dummies Questions & Answers

Advanced grep'in... grep for data next to static element.

I have a directory I need to grep which consists of numbered sub directories. The sub directory names change daily. A file resides in this main directory that shows which sub directories are FULL backups or INCREMENTAL backups. My goal is to grep the directory for the word "full" and then... (2 Replies)
Discussion started by: SysAdm2
2 Replies

7. Shell Programming and Scripting

AWK/GREP: grep only lines starting with integer

I have an input file 12.4 1.72849432773174e+01 -7.74784188610632e+01 12.5 9.59432114416327e-01 -7.87018212757537e+01 15.6 5.20139995965960e-01 -5.61612429666624e+01 29.3 3.76696387248366e+00 -7.42896194101892e+01 32.1 1.86899877018077e+01 -7.56508762501408e+01 35 6.98857157014640e+00... (2 Replies)
Discussion started by: chrisjorg
2 Replies

8. UNIX for Dummies Questions & Answers

Bash - CLI - grep - Passing result to grep through pipe

Hello. I want to get all modules which are loaded and which name are exactly 2 characters long and not more than 2 characters and begin with "nv" lsmod | (e)grep '^nv???????????? I want to get all modules which are loaded and which name begin with "nv" and are 2 to 7 characters long ... (1 Reply)
Discussion started by: jcdole
1 Replies

9. UNIX for Dummies Questions & Answers

Piping grep into awk, read the next line using grep

Hi, I have a number of files containing the information below. """"" Fundallinfo 6.3950 14.9715 14.0482 """"" I would like to grep for Fundallinfo and use it to read the next line? I ideally would like to read the three numbers that follow in the next line and... (2 Replies)
Discussion started by: Paul Moghadam
2 Replies

10. Shell Programming and Scripting

Inconsistent `ps -eaf -o args | grep -i sfs_pcard_load_file.ksh | grep -v grep | wc -l`

i have this line of code that looks for the same file if it is currently running and returns the count. `ps -eaf -o args | grep -i sfs_pcard_load_file.ksh | grep -v grep | wc -l` basically it is assigned to a variable ISRUNNING=`ps -eaf -o args | grep -i sfs_pcard_load_file.ksh |... (6 Replies)
Discussion started by: wtolentino
6 Replies
Lexical::SealRequireHints(3)				User Contributed Perl Documentation			      Lexical::SealRequireHints(3)

NAME
Lexical::SealRequireHints - prevent leakage of lexical hints SYNOPSIS
use Lexical::SealRequireHints; DESCRIPTION
This module works around two historical bugs in Perl's handling of the "%^H" (lexical hints) variable. One bug causes lexical state in one file to leak into another that is "require"d/"use"d from it. This bug, [perl #68590], was present from Perl 5.6 up to Perl 5.10, fixed in Perl 5.11.0. The second bug causes lexical state (normally a blank "%^H" once the first bug is fixed) to leak outwards from "utf8.pm", if it is automatically loaded during Unicode regular expression matching, into whatever source is compiling at the time of the regexp match. This bug, [perl #73174], was present from Perl 5.8.7 up to Perl 5.11.5, fixed in Perl 5.12.0. Both of these bugs seriously damage the usability of any module relying on "%^H" for lexical scoping, on the affected Perl versions. It is in practice essential to work around these bugs when using such modules. On versions of Perl that require such a workaround, this module globally changes the behaviour of "require", including "use" and the implicit "require" performed in Unicode regular expression matching, so that it no longer exhibits these bugs. The workaround supplied by this module takes effect the first time its "import" method is called. Typically this will be done by means of a "use" statement. This should be done as early as possible, because it only affects "require"/"use" statements that are compiled after the workaround goes into effect. For "use" statements, and "require" statements that are executed immediately and only once, it suffices to invoke the workaround when loading the first module that will set up vulnerable lexical state. Delayed-action "require" statements, however, are more troublesome, and can require the workaround to be loaded much earlier. Ultimately, an affected Perl program may need to load the workaround as very nearly its first action. Invoking this module multiple times, from multiple modules, is not a problem: the workaround is only applied once, and applies to everything subsequently compiled. This module is implemented in XS, with a pure Perl backup version for systems that can't handle XS modules. The XS version has a better chance of playing nicely with other modules that modify "require" handling. The pure Perl version can't work at all on some Perl versions; users of those versions must use the XS. PERL VERION DIFFERENCES
The history of the "%^H" bugs is complex. Here is a chronological statement of the relevant changes. Perl 5.6.0 "%^H" introduced. It exists only as a hash at compile time. It is not localised by "require", so lexical hints leak into every module loaded, which is bug [perl #68590]. The "CORE::GLOBAL" mechanism doesn't work cleanly for "require", because overriding "require" loses the necessary special parsing of bareword arguments to it. As a result, pure Perl code can't properly globally affect the behaviour of "require". Pure Perl code can localise "%^H" itself for any particular "require" invocation, but a global fix is only possible through XS. Perl 5.7.2 The "CORE::GLOBAL" mechanism now works cleanly for "require", so pure Perl code can globally affect the behaviour of "require" to achieve a global fix for the bug. Perl 5.8.7 When "utf8.pm" is automatically loaded during Unicode regular expression matching, "%^H" now leaks outward from it into whatever source is compiling at the time of the regexp match, which is bug [perl #73174]. It often goes unnoticed, because [perl #68590] makes "%^H" leak into "utf8.pm" which then doesn't modify it, so what leaks out tends to be identical to what leaked in. If [perl #68590] is worked around, however, "%^H" tends to be (correctly) blank inside "utf8.pm", and this bug therefore blanks it for the outer module. Perl 5.9.4 "%^H" now exists in two forms. In addition to the relatively ordinary hash that is modified during compilation, the value that it had at each point in compilation is recorded in the compiled op tree, for later examination at runtime. It is in a special representation- sharing format, and writes to "%^H" are meant to be performed on both forms. "require" does not localise the runtime form of "%^H" (and still doesn't localise the compile-time form). A couple of special "%^H" entries are erroneously written only to the runtime form. Pure Perl code, although it can localise the compile-time "%^H" by normal means, can't adequately localise the runtime "%^H", except by using a string eval stack frame. This makes a satisfactory global fix for the leakage bug impossible in pure Perl. Perl 5.10.1 "require" now properly localises the runtime form of "%^H", but still not the compile-time form. A global fix is once again possible in pure Perl, because the fix only needs to localise the compile-time form. Perl 5.11.0 "require" now properly localises both forms of "%^H", fixing [perl #68590]. This makes [perl #73174] apparent without any workaround for [perl #68590]. The special "%^H" entries are now correctly written to both forms of the hash. Perl 5.12.0 The automatic loading of "utf8.pm" during Unicode regular expression matching now properly restores "%^H", fixing [perl #73174]. BUGS
The operation of this module depends on influencing the compilation of "require". As a result, it cannot prevent lexical state leakage through a "require" statement that was compiled before this module was invoked. Where problems occur, this module must be invoked earlier. SEE ALSO
perlpragma AUTHOR
Andrew Main (Zefram) <zefram@fysh.org> COPYRIGHT
Copyright (C) 2009, 2010, 2011, 2012 Andrew Main (Zefram) <zefram@fysh.org> LICENSE
This module is free software; you can redistribute it and/or modify it under the same terms as Perl itself. perl v5.18.2 2017-10-06 Lexical::SealRequireHints(3)
All times are GMT -4. The time now is 07:29 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy