Ken, On Saturday 02 July 2005 14:00, ken wrote:
Randall R Schulz wrote:
...
It never hurts to look at the code and understand what it's going to do, especially since you are, in effect, giving some other coder access to your shell.
Put this in a file an execute it:
...
Randall Schulz
Good points. Also, it's not a good idea to run any strange scripts as root. Personally, I created a user (called "test") which is used to run/test such scripts.
Not bad ideas. But this is a simple script. It's not hard to see whether it's going to have any untoward effects. Plus, it would be a pretty brazen way for Cristian to try to invade or damage unwary users' systems.
Back to the script itself.... I added a "set -x" above the code and got this output:
+ dig Linux.z.zoy.org + perl -ne 's/\.//g; print pack("H224",$1) if(/^x([^z]*)/)' + gunzip + dig screw.z.zoy.org + dig the.z.zoy.org + dig MPAA.z.zoy.org + dig and.z.zoy.org
Given the simplicity of the code, this is eminently predictable (up to the precise order of execution of processes joined by pipes).
gunzip: stdin: not in gzip format
This, however, is not. (Predictable, that is.) I hate to ask this, but you are running this on a Linux system, right? I know of ways to configure Cygwin, which will happily run this script, that might cause the symptom you're seeing. Anyway, try replacing the pipe into gunzip with a redirection into a file. Then use the "file" command to ascertain what sort of data is coming out of the perl stage of that script. You might also simply "less" that file. While it's surely fully of binary, less will protect you from that and if there's anything obvious, say diagnostics from perl, you'll see it.
So I'm still having the same problem, i.e., not in gzip format.
Of course, I could just send you the text produced on my system, but where's the fun in that? Randall Schulz