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

Clash Royale CLAN TAG#URR8PPP
up vote
5
down vote
favorite
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
pipe dd cat boot-loader
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.
add a comment |Â
up vote
5
down vote
favorite
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
pipe dd cat boot-loader
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
add a comment |Â
up vote
5
down vote
favorite
up vote
5
down vote
favorite
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
pipe dd cat boot-loader
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
pipe dd cat boot-loader
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
add a comment |Â
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
add a comment |Â
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 ...
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
add a comment |Â
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 ...
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
add a comment |Â
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 ...
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
add a comment |Â
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 ...
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 ...
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
add a comment |Â
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
add a comment |Â
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