procmail
[Top] [All Lists]

gzip acts weirly from withing procmail

1998-01-16 06:19:32

    I'm lost here, why does my standard gzip behave this way?

/usr/contrib/bin/gzip                               (% which gzip)
gzip 1.2.4 (18 Aug 93)                              (% gzip -V)
Compilation options:
D
/usr/contrib/bin/gzip:  s800 shared executable      (% file gzip)

    I created one test file T1 with "echo 1 > ~/T1" and used recipes:

:0 whic:
| gzip -9c $HOME/T1 > $HOME/T2

dummy = `gzip -9c $HOME/T1  > $HOME/T3`

    The results were unbelieving:

-rw-------   1 jaalto     nms          73647 Jan 16 14:47 /users/jaalto/T3
-rw-------   1 jaalto     nms          73647 Jan 16 14:47 /users/jaalto/T2
-rw-------   1 jaalto     nms              2 Jan 16 14:47 /users/jaalto/T1

    But if I run the same command from the shell promt, all goes ok:

% gzip -9c $HOME/T1  > $HOME/T3; ls -l $HOME/T3

-rw-------   1 jaalto     nms             25 Jan 16 15:00 /users/jaalto/T3

    If I unzip the content of T2, it contains some weird HP-UX link
    library binary:
        
        ...binary
        $Header: crt0.s,v 70.8 92/05/19 15:52:46        
        ...binary
        1                   << and the real T1 contents at the end

    What I wanted, was to include gzipped file to email with folowing,
    but as you saw above, I started wondering why the gzipped body 
    wasn't correct after few experiments.

:0 fbwi
| gzip -9c $FILE

    

<Prev in Thread] Current Thread [Next in Thread>
  • gzip acts weirly from withing procmail, jari.aalto <=