4 ms·

Can anyone explain what this section is talking about? I'm completely not following it: cat $1 printf "X" cat $0 exit

quasse 14y ago
Say I have an original file: AAAAAAAAXAAAAAAA If I split it into two files, $1 and $2 that look like this: $1 - AAAAAAAA $2 - AAAAAAA I have now "saved" one byte by dropping the X. The script "cat $1 printf "X" cat $0 exit" will combine those two files and reinsert the X, thus "decompressing" the data. Basically, he has replaced the byte "X", which counted towards the total size, with the EOF marker on the filesystem, which technically didn't count. No space was actually saved, because he basically moved the information from the X character to metadata (the file splits).
- tocomment 14y ago
  but the script is longer than the one byte that he saves, right? So the total is greater than the original file. That's where I'm getting confused.
  - im3w1l 14y ago
    He won one byte per file.
  - deleted 14y ago
    [deleted]
breadbox 14y ago
If you asked for a big enough file of random bytes, eventually, chances are that the file would just happen to contain the substring "Xcat $1\nprintf X\ncat $0\nexit\n". You then do the following: 1. Copy the part of the file preceding that substring to a file named "foo". 2. Take the rest of the file, including all of the substring EXCEPT for the initial X character, and put it in an executable file called "decompressor". When you run "./decompressor foo > out", you will then recreate the original file. The length of decompressor + foo will be one byte shorter than the original file.
qntm 14y ago
Suppose the random file is 3,000,000 bytes long and happens to contain 135 bytes "X". Split the file on the letter "X" into 136 smaller files, each with no X in it. Then, return the files along with a "decompressor" script which says something like: return(join("X", files 1 to 136)) Since the script takes up fewer bytes than the 136 "X" bytes would, the total size of the 136 files + decompressor script is less than the size of the original file.

Say I have an original file: AAAAAAAAXAAAAAAA If I split it into two files, $1 and $2 that look like this: $1 - AAAAAAAA $2 - AAAAAAA I have now "saved" one byte by dropping the X. The script "cat $1 printf "X" cat $0 exit" will combine those two files and reinsert the X, thus "decompressing" the data. Basically, he has replaced the byte "X", which counted towards the total size, with the EOF marker on the filesystem, which technically didn't count. No space was actually saved, because he basically moved the information from the X character to metadata (the file splits).

tocomment 14y ago
but the script is longer than the one byte that he saves, right? So the total is greater than the original file. That's where I'm getting confused.
- im3w1l 14y ago
  He won one byte per file.
- deleted 14y ago
  [deleted]

breadbox 14y ago

If you asked for a big enough file of random bytes, eventually, chances are that the file would just happen to contain the substring "Xcat $1\nprintf X\ncat $0\nexit\n". You then do the following: 1. Copy the part of the file preceding that substring to a file named "foo". 2. Take the rest of the file, including all of the substring EXCEPT for the initial X character, and put it in an executable file called "decompressor". When you run "./decompressor foo > out", you will then recreate the original file. The length of decompressor + foo will be one byte shorter than the original file.

qntm 14y ago

Suppose the random file is 3,000,000 bytes long and happens to contain 135 bytes "X". Split the file on the letter "X" into 136 smaller files, each with no X in it. Then, return the files along with a "decompressor" script which says something like: return(join("X", files 1 to 136)) Since the script takes up fewer bytes than the 136 "X" bytes would, the total size of the 136 files + decompressor script is less than the size of the original file.