What's the difference in these commands - cat piped to dd and just cat? [duplicate]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
5
down vote

favorite
2













This question already has an answer here:



  • dd vs cat — is dd still relevant these days?

    8 answers



I'm curious to know the difference between these two commands in Linux:



$ cat ./boot.bin ./kernel.bin /dev/zero | dd bs=512 count=2880 of=devos.img


and



$ cat ./boot.bin ./kernel.bin > devos.img






share|improve this question













marked as duplicate by muru, schily, Anthony Geoghegan, slm♦ Jul 5 at 20:53


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.










  • 1




    Linux is just a kernel, it has no commands. Only commands run on it. These commands are Gnu commands.
    – ctrl-alt-delor
    Jul 5 at 13:51














up vote
5
down vote

favorite
2













This question already has an answer here:



  • dd vs cat — is dd still relevant these days?

    8 answers



I'm curious to know the difference between these two commands in Linux:



$ cat ./boot.bin ./kernel.bin /dev/zero | dd bs=512 count=2880 of=devos.img


and



$ cat ./boot.bin ./kernel.bin > devos.img






share|improve this question













marked as duplicate by muru, schily, Anthony Geoghegan, slm♦ Jul 5 at 20:53


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.










  • 1




    Linux is just a kernel, it has no commands. Only commands run on it. These commands are Gnu commands.
    – ctrl-alt-delor
    Jul 5 at 13:51












up vote
5
down vote

favorite
2









up vote
5
down vote

favorite
2






2






This question already has an answer here:



  • dd vs cat — is dd still relevant these days?

    8 answers



I'm curious to know the difference between these two commands in Linux:



$ cat ./boot.bin ./kernel.bin /dev/zero | dd bs=512 count=2880 of=devos.img


and



$ cat ./boot.bin ./kernel.bin > devos.img






share|improve this question














This question already has an answer here:



  • dd vs cat — is dd still relevant these days?

    8 answers



I'm curious to know the difference between these two commands in Linux:



$ cat ./boot.bin ./kernel.bin /dev/zero | dd bs=512 count=2880 of=devos.img


and



$ cat ./boot.bin ./kernel.bin > devos.img




This question already has an answer here:



  • dd vs cat — is dd still relevant these days?

    8 answers









share|improve this question












share|improve this question




share|improve this question








edited Jul 5 at 14:38









muru

33.1k576139




33.1k576139









asked Jul 5 at 12:57









Daniel Smith

283




283




marked as duplicate by muru, schily, Anthony Geoghegan, slm♦ Jul 5 at 20:53


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.






marked as duplicate by muru, schily, Anthony Geoghegan, slm♦ Jul 5 at 20:53


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.









  • 1




    Linux is just a kernel, it has no commands. Only commands run on it. These commands are Gnu commands.
    – ctrl-alt-delor
    Jul 5 at 13:51












  • 1




    Linux is just a kernel, it has no commands. Only commands run on it. These commands are Gnu commands.
    – ctrl-alt-delor
    Jul 5 at 13:51







1




1




Linux is just a kernel, it has no commands. Only commands run on it. These commands are Gnu commands.
– ctrl-alt-delor
Jul 5 at 13:51




Linux is just a kernel, it has no commands. Only commands run on it. These commands are Gnu commands.
– ctrl-alt-delor
Jul 5 at 13:51










1 Answer
1






active

oldest

votes

















up vote
14
down vote



accepted










dd copies exactly count blocks of bs bytes, or 2880*512 bytes in total in this case(but see below). That will truncate or pad the concatenation of the two files to a fixed size (since /dev/zero gives as many zero bytes as required). 1440 kB is looks like the size of a 3.5" HD floppy disk, so perhaps someone wanted to make images that fit the floppy exactly.



The plain cat on your second example will just concatenate the files, and the result will of whatever size it is.



Smaller example:



$ echo hello > a; echo world > b
$ cat a b | od -c
0000000 h e l l o n w o r l d n
$ cat a b /dev/zero | dd bs=1 count=8 2>/dev/null | od -c
0000000 h e l l o n w o
$ cat a b /dev/zero | dd bs=1 count=16 2>/dev/null | od -c
0000000 h e l l o n w o r l d n


Actually, dd will read and write less if it gets less data than the block size on a single read() call. This might happen with large block sizes but probably isn't an issue with 512 since cat will write the data in blocks of at least that size. In GNU dd, this can be prevented with iflag=fullblock.



We could do the same with head -c:



$ cat a b /dev/zero | head -c 16 ...





share|improve this answer























  • Would the plain cat risk, say, leaving unused data on the disk, and possible corruption if that code ends up executed?
    – Nic Hartley
    Jul 5 at 18:28










  • @NicHartley, yeah, if you had an image saved to a floppy, and then wrote another one that was shorter, it would leave remains of the first image there. But the new image would need to be buggy to try to read past the length of the files. It's not like zero-padding would help much in that case either, it's not very useful as code anyway...
    – ilkkachu
    Jul 5 at 19:04

















1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
14
down vote



accepted










dd copies exactly count blocks of bs bytes, or 2880*512 bytes in total in this case(but see below). That will truncate or pad the concatenation of the two files to a fixed size (since /dev/zero gives as many zero bytes as required). 1440 kB is looks like the size of a 3.5" HD floppy disk, so perhaps someone wanted to make images that fit the floppy exactly.



The plain cat on your second example will just concatenate the files, and the result will of whatever size it is.



Smaller example:



$ echo hello > a; echo world > b
$ cat a b | od -c
0000000 h e l l o n w o r l d n
$ cat a b /dev/zero | dd bs=1 count=8 2>/dev/null | od -c
0000000 h e l l o n w o
$ cat a b /dev/zero | dd bs=1 count=16 2>/dev/null | od -c
0000000 h e l l o n w o r l d n


Actually, dd will read and write less if it gets less data than the block size on a single read() call. This might happen with large block sizes but probably isn't an issue with 512 since cat will write the data in blocks of at least that size. In GNU dd, this can be prevented with iflag=fullblock.



We could do the same with head -c:



$ cat a b /dev/zero | head -c 16 ...





share|improve this answer























  • Would the plain cat risk, say, leaving unused data on the disk, and possible corruption if that code ends up executed?
    – Nic Hartley
    Jul 5 at 18:28










  • @NicHartley, yeah, if you had an image saved to a floppy, and then wrote another one that was shorter, it would leave remains of the first image there. But the new image would need to be buggy to try to read past the length of the files. It's not like zero-padding would help much in that case either, it's not very useful as code anyway...
    – ilkkachu
    Jul 5 at 19:04














up vote
14
down vote



accepted










dd copies exactly count blocks of bs bytes, or 2880*512 bytes in total in this case(but see below). That will truncate or pad the concatenation of the two files to a fixed size (since /dev/zero gives as many zero bytes as required). 1440 kB is looks like the size of a 3.5" HD floppy disk, so perhaps someone wanted to make images that fit the floppy exactly.



The plain cat on your second example will just concatenate the files, and the result will of whatever size it is.



Smaller example:



$ echo hello > a; echo world > b
$ cat a b | od -c
0000000 h e l l o n w o r l d n
$ cat a b /dev/zero | dd bs=1 count=8 2>/dev/null | od -c
0000000 h e l l o n w o
$ cat a b /dev/zero | dd bs=1 count=16 2>/dev/null | od -c
0000000 h e l l o n w o r l d n


Actually, dd will read and write less if it gets less data than the block size on a single read() call. This might happen with large block sizes but probably isn't an issue with 512 since cat will write the data in blocks of at least that size. In GNU dd, this can be prevented with iflag=fullblock.



We could do the same with head -c:



$ cat a b /dev/zero | head -c 16 ...





share|improve this answer























  • Would the plain cat risk, say, leaving unused data on the disk, and possible corruption if that code ends up executed?
    – Nic Hartley
    Jul 5 at 18:28










  • @NicHartley, yeah, if you had an image saved to a floppy, and then wrote another one that was shorter, it would leave remains of the first image there. But the new image would need to be buggy to try to read past the length of the files. It's not like zero-padding would help much in that case either, it's not very useful as code anyway...
    – ilkkachu
    Jul 5 at 19:04












up vote
14
down vote



accepted







up vote
14
down vote



accepted






dd copies exactly count blocks of bs bytes, or 2880*512 bytes in total in this case(but see below). That will truncate or pad the concatenation of the two files to a fixed size (since /dev/zero gives as many zero bytes as required). 1440 kB is looks like the size of a 3.5" HD floppy disk, so perhaps someone wanted to make images that fit the floppy exactly.



The plain cat on your second example will just concatenate the files, and the result will of whatever size it is.



Smaller example:



$ echo hello > a; echo world > b
$ cat a b | od -c
0000000 h e l l o n w o r l d n
$ cat a b /dev/zero | dd bs=1 count=8 2>/dev/null | od -c
0000000 h e l l o n w o
$ cat a b /dev/zero | dd bs=1 count=16 2>/dev/null | od -c
0000000 h e l l o n w o r l d n


Actually, dd will read and write less if it gets less data than the block size on a single read() call. This might happen with large block sizes but probably isn't an issue with 512 since cat will write the data in blocks of at least that size. In GNU dd, this can be prevented with iflag=fullblock.



We could do the same with head -c:



$ cat a b /dev/zero | head -c 16 ...





share|improve this answer















dd copies exactly count blocks of bs bytes, or 2880*512 bytes in total in this case(but see below). That will truncate or pad the concatenation of the two files to a fixed size (since /dev/zero gives as many zero bytes as required). 1440 kB is looks like the size of a 3.5" HD floppy disk, so perhaps someone wanted to make images that fit the floppy exactly.



The plain cat on your second example will just concatenate the files, and the result will of whatever size it is.



Smaller example:



$ echo hello > a; echo world > b
$ cat a b | od -c
0000000 h e l l o n w o r l d n
$ cat a b /dev/zero | dd bs=1 count=8 2>/dev/null | od -c
0000000 h e l l o n w o
$ cat a b /dev/zero | dd bs=1 count=16 2>/dev/null | od -c
0000000 h e l l o n w o r l d n


Actually, dd will read and write less if it gets less data than the block size on a single read() call. This might happen with large block sizes but probably isn't an issue with 512 since cat will write the data in blocks of at least that size. In GNU dd, this can be prevented with iflag=fullblock.



We could do the same with head -c:



$ cat a b /dev/zero | head -c 16 ...






share|improve this answer















share|improve this answer



share|improve this answer








edited Jul 5 at 15:51


























answered Jul 5 at 13:01









ilkkachu

47.3k668130




47.3k668130











  • Would the plain cat risk, say, leaving unused data on the disk, and possible corruption if that code ends up executed?
    – Nic Hartley
    Jul 5 at 18:28










  • @NicHartley, yeah, if you had an image saved to a floppy, and then wrote another one that was shorter, it would leave remains of the first image there. But the new image would need to be buggy to try to read past the length of the files. It's not like zero-padding would help much in that case either, it's not very useful as code anyway...
    – ilkkachu
    Jul 5 at 19:04
















  • Would the plain cat risk, say, leaving unused data on the disk, and possible corruption if that code ends up executed?
    – Nic Hartley
    Jul 5 at 18:28










  • @NicHartley, yeah, if you had an image saved to a floppy, and then wrote another one that was shorter, it would leave remains of the first image there. But the new image would need to be buggy to try to read past the length of the files. It's not like zero-padding would help much in that case either, it's not very useful as code anyway...
    – ilkkachu
    Jul 5 at 19:04















Would the plain cat risk, say, leaving unused data on the disk, and possible corruption if that code ends up executed?
– Nic Hartley
Jul 5 at 18:28




Would the plain cat risk, say, leaving unused data on the disk, and possible corruption if that code ends up executed?
– Nic Hartley
Jul 5 at 18:28












@NicHartley, yeah, if you had an image saved to a floppy, and then wrote another one that was shorter, it would leave remains of the first image there. But the new image would need to be buggy to try to read past the length of the files. It's not like zero-padding would help much in that case either, it's not very useful as code anyway...
– ilkkachu
Jul 5 at 19:04




@NicHartley, yeah, if you had an image saved to a floppy, and then wrote another one that was shorter, it would leave remains of the first image there. But the new image would need to be buggy to try to read past the length of the files. It's not like zero-padding would help much in that case either, it's not very useful as code anyway...
– ilkkachu
Jul 5 at 19:04


Popular posts from this blog

Peggy Mitchell

Palaiologos

The Forum (Inglewood, California)