Split. . .

[krp]

I have just started playing with "split." It splits a large file into smaller, defined files. Works great. What I have been unable to find out is how to put the split files back together again as a single large file.

I have read the man and info pages and googled as well. I cannot find anything pertaining to putting the files back together again.

Does anyone have any ideas or, better yet, the answer?

krp

[fos]

You might try the "cat" command from a command prompt.

ie. cat file1 file2 file3 > bigfile

bigfile will will be a concatenation of the three original files.

fos....

[krp]

You might try the "cat" command from a command prompt.

ie. cat file1 file2 file3 > bigfile

bigfile will will be a concatenation of the three original files.

fos....

Just tried it. No joy. Saw all kinds of things scroll quickly with numerous beeping.

krp

[bluesdog]

I just tried this with a text file.. I split it into about 200 little teeny files, then joined 'em with the cat command

split splitmindtwo.txt -b 10

You can use a wildcard in the cat command

cat x* > joinedfile.txt

[krp]

I just tried this with a text file.. I split it into about 200 little teeny files, then joined 'em with the cat command

split splitmindtwo.txt -b 10

You can use a wildcard in the cat command

cat x* > joinedfile.txt

Okay, I haven't tried that yet. Will it handle .tar files? What I did was tar a series of sub-directories under my home directory. I saved the file as "test1.tar". I then used split to split the single tar file into little pieces. When I tried using cat to ... unsplit or join the series of small files into the original large file, well that is when things went south.

krp

[fos]

The problem is that the compressed file is a binary file. You are losing coding that is built into the file but the compression algorithim.

Try splitting the original text file and then using cat to join them.

cat will concatenate split binary files but I don't think it will work on compressed binary files.

fos.....

[krp]

The problem is that the compressed file is a binary file. You are losing coding that is built into the file but the compression algorithim.

Try splitting the original text file and then using cat to join them.

cat will concatenate split binary files but I don't think it will work on compressed binary files.

fos.....

I tried what you said and you are quite correct. Split and Cat on text files work fine.

Sigh, now I need to find something which will work on tar files. It is, I would think, easier and quicker to perform backups by backing up specified files and directories as a single tar (possibly tar.bz2) file and then splitting the single file into multiple cd sized chunks.

krp

[tom_servo]

I think you are seeing a different problem then you think. When you used cat, and got a bunch of crap on the screen, with a bunch of beeping, it seems that the output of cat had gone to the screen, instead of being captured into a file with the > or >> operators. So I will focus on that part especially.

Split works just fine on both text, and binary (even compressed) files. An example is worth a thousand words of man page (that don't have examples). Here I have temp.tar.gz, a 34MB gziped tar file containing 19 mp3 files (I know, mp3 files are already compressed, so the gzip is a waste of time, but this is just an example, and the mp3 files conveniently were in a directory about the right size).


alain:/tmp/split$ split -b 10m temp.tar.gz temp.tar.gz_part_
alain:/tmp/split$ cat temp.tar.gz_part_aa temp.tar.gz_part_ab temp.tar.gz_part_ac temp.tar.gz_part_ad >reassembled
alain:/tmp/split$ diff -s reassembled temp.tar.gz
Files reassembled and temp.tar.gz are identical


The cat command can be broken into parts (this is useful if each part is on a separate disk, like one each on CDs). Take note that the first time, a single > is used to make sure that the data from this first part overwrites the destination file (if it already exists), but that each time after that, a double > is used to append to the destination file.

cat temp.tar.gz_part_aa > reassembled
cat temp.tar.gz_part_ab >> reassembled
cat temp.tar.gz_part_ac >> reassembled
cat temp.tar.gz_part_ad >> reassembled


Also, one should not depend on the * wild card to return the files in the correct order, so "cat temp.tar.gz_part_a* > reassembled" is potentially dangerous. Instead, try: cat `echo temp.tar.gz_part_a* | sort` > reassembled


Alain

[krp]

I think you are seeing a different problem then you think. When you used cat, and got a bunch of crap on the screen, with a bunch of beeping, it seems that the output of cat had gone to the screen, instead of being captured into a file with the > or >> operators. So I will focus on that part especially.

Split works just fine on both text, and binary (even compressed) files. An example is worth a thousand words of man page (that don't have examples). Here I have temp.tar.gz, a 34MB gziped tar file containing 19 mp3 files (I know, mp3 files are already compressed, so the gzip is a waste of time, but this is just an example, and the mp3 files conveniently were in a directory about the right size).

[...]

Alain

Thanks for the info! Will be giving it a whirl later today! :)

krp

[krp]

Works like a champ!!!

This shall make back ups so much simpler.

Ahh, the power of the command line is truly awesome.

I shall assume that initial and/or reassembled file size cannot exceed 2gb.

I wish to thank everyone on this forum who helped me out. Thanks again, y'all are the best.

krp

[tom_servo]

I just tested it, and a source file greater then 2 GB (3.6 in my test case) can be spilt into small, and large files (I tried 1.5G, and 2.5G). Then it can be reassembled into one large file again without problem, so long as the FS you store the large files on supports >2GB files (so not FAT32).


Alain

[krp]

I just tested it, and a source file greater then 2 GB (3.6 in my test case) can be spilt into small, and large files (I tried 1.5G, and 2.5G). Then it can be reassembled into one large file again without problem, so long as the FS you store the large files on supports >2GB files (so not FAT32).


Alain

Rock on!

Again I say *thanks*!

krp