Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am trying to pull some links out of text that I downloaded of off the internet using grep, but keep getting "Aborted (core dumped)". When using grep I tend to use -P as I prefer to use perl syntax (and I like to prevent greediness using ?). Grep itself has no troubles applying a pattern to the file without -P.

Now, I am fairly new to the command line (and loving it!), so I can't work out how to sort this.

Note that this issue occurs with almost any pattern. Example : grep '\.jpg' file.txt -oP

I would like to run: grep '.+?\.jpg' file.txt -oP

Update: It seems that the root of the problem is infact this piece of "code":

    <script type="text/javascript">

/***********************************************
* Bookmark site script- © Dynamic Drive DHTML code library (www.dynamicdrive.com)
* This notice MUST stay intact for legal use
* Visit Dynamic Drive at http://www.dynamicdrive.com/ for full source code
***********************************************/

/* Modified to support Opera */
function bookmarksite(title,url){
if (window.sidebar) // firefox
    window.sidebar.addPanel(title, url, "");
else if(window.opera && window.print){ // opera
    var elem = document.createElement('a');
    elem.setAttribute('href',url);
    elem.setAttribute('title',title);
    elem.setAttribute('rel','sidebar');
    elem.click();
} 
else if(document.all)// ie
    window.external.AddFavorite(url, title);
}
</script>

source: http://www.dynamicdrive.com/dynamicindex9/addbook.htm
I first assumed that the "*" was causing problems. Testing indicates that the copyright symbol was infact the problem. Is it possible that this is an issue with different encodings? Even copying and pasting into a new document causes the same issues though.

My environment is: "Cygwin, Windows 8.1 64bit" Locale output:

$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=

Grep version:

  $ grep --version
grep (GNU grep) 2.14.56-1e3d
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and others, see <http://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS>.
share|improve this question
    
Could we see a minimal example of the file that reproduces the error? I tried with a file with 100 lines of 224000 characters and it worked fine. –  terdon Jan 3 at 3:21
    
I too tried with about 50 lines with each line 227500 char long and grep worked fine. –  Ketan Jan 3 at 3:28
    
May be you are hitting this bug: savannah.gnu.org/bugs/?36842 –  Ketan Jan 3 at 3:31
1  
Still works fine here. Please show us the output of locale, also tell us something about your system. Is this Linux? What version of grep? –  terdon Jan 3 at 3:41
1  
Is LC_ALL=C give the same error? –  Gnouc Jan 3 at 4:02
show 7 more comments

1 Answer

up vote 3 down vote accepted

I don't have access to a cygwin system so I can't test this, but since you want to use Perl regexes, why not use Perl?

perl -ne 'print "$_\n" for /.+?\.jpg/g;' file.txt 

or

awk '{for(i=1;i<=NF;i++){if($(i)~/.+?\.jpg/){print $(i)}}}' file.txt 

However, I suspect that you want to match the shortest string of non-whitespace characters that end in .jpg which is not what that regex matches (though the awk solution will work anyway since the fields are split on whitespace). You might want to run this instead:

perl -ne '@a=/[^\s]+\.jpg/g; print "$_\n" for @a' file.txt 

or

awk '{for(i=1;i<=NF;i++){if($(i)~/.+?\.jpg/){print $(i)}}}' file.txt 

or, simple grep:

grep -o '[^[:space:]]*.jpg' file.txt        
share|improve this answer
    
Thanks for your solution and thanks to @Gnouc. Gnouc's is a good quick fix, but these ones are very impressive. Thanks! –  Sam Jan 3 at 7:36
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.