Capturing only the first "image data" from file output: anchoring lazy grep patterns (and why MIME types are the better tool)

To keep only the first image data token from file output, anchor the pattern to the start of the line and use a single lazy quantifier: grep -Po '\A.*?image data'. For scripts, the sturdier answer is to skip prose parsing entirely and ask file --mime-type, which returns a stable, machine-readable token such as image/jpeg.

Why the match runs past the first occurrence

PCRE tries to start each match at the earliest possible position, so leftmost matching is not the problem here — your pattern does begin at position zero. The problem is what happens next. In a pattern like .*:.*?image data, the .*: part is greedy: it consumes as much of the line as it can, then backtracks only until it finds a colon that still lets the rest of the pattern match. On a line with EXIF metadata, the last usable colon sits inside Exif Standard:, immediately before the embedded TIFF description.

Only after that greedy prefix has eaten its way to the last colon does the lazy .*?image data, get to work — and it lazily grabs the nearest following occurrence, which is the second one, inside the TIFF dump. The lazy quantifier never had a chance to stop at the first occurrence, because everything up to and including it had already been swallowed. You can confirm this by deleting the colon segment: grep -Po '\A.*?image data,' stops exactly where you wanted.

The anchored, lazy pattern that works

file * | grep -Po '\A.*?image data'

Output for the sample file:

Heart2.jpg: JPEG image data

Two details make this behave:

• \A asserts the start of the subject string. Since grep hands each line to PCRE as its own subject, this pins the match to the very beginning of the line. ^ works identically here, but \A states the intent explicitly and is immune to any multiline-mode surprises.
• .*? is lazy: it matches the shortest span that still lets the pattern succeed, so the match ends at the first image data.

Note that the trailing comma was dropped on purpose. Not every format prints a comma after that phrase — GIF and PNG summaries differ — so anchoring on the words alone travels better across file types. Also remember that lazy quantifiers require PCRE, i.e. grep -P; plain BRE/ERE grep has no non-greedy matching at all.

Prefer MIME output when a script is doing the choosing

The human-readable summary from file is prose, and that prose is not a contract: wording shifts between releases of the magic database, EXIF blocks can inject a second image data, and different formats append different trivia. If your actual goal is "find all image files regardless of type," ask file for its designed-for-machines vocabulary instead:

file --mime-type Heart2.jpg
Heart2.jpg: image/jpeg

The legacy -i/--mime flag does the same job for images (it may append a charset for text files). Add -b/--brief when you want the bare type with no filename prefix. A single token like image/png is trivial to compare, sort, and filter — no regex surgery required.

Listing every image in a directory

With a simple glob, one line suffices:

file --mime-type * | grep 'image/'

For anything beyond a plain glob — hidden files, spaces, odd names — let find supply the files and use NUL-safe piping:

find . -maxdepth 1 -type f -print0 |
  xargs -0 file --mime-type |
  grep 'image/'

If you want custom formatting, print the name yourself and use -b so the filename can never leak into the type field:

for f in *; do
  printf '%s: %s\n' "$f" "$(file -b --mime-type -- "$f")"
done

The general rule, so it does not recur

Whenever you want the first occurrence of a phrase in a line:

1. Anchor the pattern at the start (\A or ^).
2. Make every quantifier between the anchor and the target phrase lazy.
3. Keep greedy sub-expressions — especially .*x constructs — out of the middle; they decide where the rest of the pattern begins looking.
4. Test against worst-case input that contains the phrase twice, like a JPEG with embedded TIFF metadata.

And as a habit: prefer structured output (--mime-type, --mime-encoding) over parsing descriptive text whenever the tool offers it.

Frequently Asked Questions

Didn't the lazy ? already mean "stop at the first match"?

Lazy means "match as little as possible from where the match attempt currently stands." A greedy prefix earlier in the pattern determines that starting point. Your .*: pushed the attempt past the first occurrence, so the lazy part only ever saw the second one.

Is \A different from ^ in grep -P?

Practically, no. grep treats each input line as a complete subject string, so both anchors match at the line's start. \A is simply the explicit "start of subject" assertion and behaves predictably even if multiline semantics change.

My grep rejects -P. What now?

PCRE support is a compile-time option; check grep --version. As a fallback, use perl -ne 'print "$1\n" if /\A(.*?image data)/', or split fields in awk with image data as the separator and reattach it.

How do I print just the type, without the filename?

Use file -b --mime-type (-b is short for --brief). It emits only the token, e.g. image/jpeg, which is ideal inside command substitution.

Would grep -m 1 have helped?

No. -m limits the number of matching lines, not matches within a line. Combined with -o, every match on that first matching line is still printed — including the second image data.

What if a filename itself contains "image data"?

The filename is part of file's output line, so an anchored match could stop inside the name. Avoid the ambiguity by using file -b and printing the filename separately from the shell, as in the loop shown above.