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