0

Disclaimer: Yes, finding files in a script with ls is bad, but find can't sort by modification date.

Using ls and xargs with echo everything is fine:

$ ls -t1 ssl-access*.gz | xargs -n 1 echo
ssl-access.log.2.gz
ssl-access.log.3.gz
ssl-access.log.4.gz
[...]

Changing echo to zcat:

$ ls -t1 ssl-access*.gz | xargs -n 1 zcat
gzip: ssl-access.log.2.gz.gz: No such file or directory
gzip: ssl-access.log.3.gz.gz: No such file or directory
gzip: ssl-access.log.4.gz.gz: No such file or directory
[...]

Duplicate file suffixes?! What is going on here?


UPDATE:

OS is Debian 5.

zcat is a shell script at /bin/zcat:

#!/bin/sh
PATH=${GZIP_BINDIR-'/bin'}:$PATH
exec gzip -cd "$@"
9
  • Unable to reproduce. Perhaps try taking a look at your zcat executable (probably a shell script) and see if it is auto-appending a .gz extension.
    – jw013
    Commented Oct 21, 2011 at 20:51
  • 3
    You actually can sort by modified time if you use -printf %t (gnu-only) or -exec stat -c '%X' {}\; then pipe it to sort. Commented Oct 21, 2011 at 21:10
  • What happens on your system when you zcat a file that is not compressed? Commented Oct 21, 2011 at 23:14
  • @ShawnJ.Goff: I get the error message gzip: test.txt: not in gzip format with return code 1. Commented Oct 21, 2011 at 23:19
  • 2
    See Shell script for moving oldest files? for better ways to sort files by date. The only advantage of xargs is running the command for a batch of files at once, and you're not using this capability, so don't even consider using it. About the strange behavior you observe: what does type zcat show? What is the full output from ls -t1 ssl-access*.gz? Commented Oct 22, 2011 at 2:11

2 Answers 2

4

I found this problem on my system caused by color ls. In my .bash_profile, I had this:

alias ls="ls --color"

I found the result by sending it to stat, which printed something handy:

$ ls local4.notice-201207* | xargs -n1 -P4 -I{} stat {}
stat: cannot stat `\033[0mlocal4.notice-20120711.gz\033[0m': No such file or directory

Look at those null color codes! It was confusing zcat, which attempted to add a .gz suffix to find a file. The problem was easily solved by changing the ls to color=auto, which disables color output when STDOUT is glued to another process instead of a terminal

alias ls="ls --color=auto"

Good luck!

1
  • Wow, after such a time. :-) Commented Aug 30, 2012 at 19:19
1

You might be using an OS where zcat is for compressed files while gzcat is for gzipped ones. In such case, this should work:

   ls -t ssl-access*.gz | xargs -n 1 gzcat

Edit:

I reproduced a similar but not identical behavior on Solaris:

$ ls -t1 *.gz | xargs -n 1 zcat          
c.gz.Z: No such file or directory
b.gz.Z: No such file or directory
a.gz.Z: No such file or directory

On a Debian based distribution (Ubuntu), I do not reproduce your problem.

This might work anyway:

cat $(ls -t ssl-access*.gz) | zcat

or the equivalent:

zcat <(cat $(ls -t ssl-access*.gz))

or this simpler one that avoids an unnecessary cat

zcat $(ls -t ssl-access*.gz)

None of these will handle odd filenames like the ones with embedded spaces.

1
  • No gzcat on my system. Commented Oct 21, 2011 at 23:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .