PDA

View Full Version : UNIX PC "dd" command failing to copy ASCII Carriage Return characters



firebirdta84
November 3rd, 2014, 11:47 PM
For reasons unknown to me, using the dd command on my UNIX PC is stripping out or ignoring all ASCII Carriage Return characters (Hex 0D). I am writing directly to the floppy. By the way, I've tried many different floppies, in case it was the destination media that is the issue, but I don't think so. I've formatted each with both 8 and 10 formatting options, it seems to make no difference.

The resulting data contains a file identical to the source, but without those carriage returns (ascii hexadecimal 0D).

I'm using the command:
dd if=/loader14cust of=/dev/rfp020

The source file that I am dd-ing can be downloaded from here: http://bit.ly/1oeuNZe

Thanks all for your suggestions.

-AJ

PS: If you're interested in more background on this chapter of my project, I created an introduction page on my website at

http://bit.ly/1wU1k8c

deathshadow
November 4th, 2014, 12:08 AM
dd is a convert, not just a copy -- if you don't want it to change out characters or do format conversions why are you using dd instead of cp? (well, apart from the whole image to device thing...)

firebirdta84
November 4th, 2014, 12:18 AM
Good question. I do need to write this file to the very beginning of the disk...so that is why I am using /dev/rfp020. Can I do that with cp? I'm new to this old-school 1985-era UNIX System V, so I really don't know.

Or, with dd, can I specify a parameter to tell it not to convert? (preferably a parameter that was available on UNIX PC OS version 3.51).

Thanks!
-AJ

Tor
November 4th, 2014, 04:04 AM
Good question. I do need to write this file to the very beginning of the disk...so that is why I am using /dev/rfp020. Can I do that with cp? I'm new to this old-school 1985-era UNIX System V, so I really don't know.

Or, with dd, can I specify a parameter to tell it not to convert? (preferably a parameter that was available on UNIX PC OS version 3.51).
Instead of cp you can simply use 'cat': cat loader14cust > /dev/rfp020
The thing with 'dd' is that for devices where record size can actually be specified (as for variable-sized tape drives, for example), the record length specified with 'dd' is what gets written (default size is 2KB, at least on those systems I know about). In this case 'cat' will probably do the right thing. If not, then you'll have to figure out the right additional parameter for 'dd'. Do you have a man page? 'man dd'. Although it's new to me that there could be a 'dd' option or default behaviour to remove carriage returns.. never seen that on any SYSV or BSD system.

-Tor

Trixter
November 4th, 2014, 07:20 AM
For reasons unknown to me, using the dd command on my UNIX PC is stripping out or ignoring all ASCII Carriage Return characters (Hex 0D). I am writing directly to the floppy. By the way, I've tried many different floppies, in case it was the destination media that is the issue, but I don't think so. I've formatted each with both 8 and 10 formatting options, it seems to make no difference.

The resulting data contains a file identical to the source, but without those carriage returns (ascii hexadecimal 0D).

I'm using the command:
dd if=/loader14cust of=/dev/rfp020

The source file that I am dd-ing can be downloaded from here: http://bit.ly/1oeuNZe


dd is not supposed to perform an ASCII conversion unless you specify conv=, however that's SysVr4 behavior -- the version of unix running on UNIX PCs is more like system 7 from the late 70s so it's possible the default options DO perform conversion. Type "man dd" and see if there are any options for explicitly disabling ASCII/EBCDIC conversion.

firebirdta84
November 4th, 2014, 09:33 AM
Thanks for these suggestions, guys. The UNIX PC predates man pages. Some commands display a guide/parameters when I specify -h, but dd is not one of them.

I'll see if I can find some dd rules/details in the UNIX PC programmer manuals.

I'll also try cat, and let you guys know the results tonight.

Thanks, all!
-AJ

firebirdta84
November 5th, 2014, 01:00 AM
My initial test tells me that cat has removed the 0D characters just like dd has.

It appears that the iv command is doing something "magic" by preserving these characters.

Does anybody here know how the iv command works, what it does "behind the scenes"?

For the context of how I am using the iv command, see the section on this page that I dedicate to iv:

http://bit.ly/1wU1k8c

Thanks again for your insights, everybody...

firebirdta84
November 5th, 2014, 01:21 AM
Just to follow up with more details, here's the dd-out result files for comparison:

floppy loader created using iv (http://6reoquestions.com/misc/MightyFrame/ATT7300/Files/vhb.fdmf.dd.85)

floppy loader created using dd (http://6reoquestions.com/misc/MightyFrame/ATT7300/Files/vhb.fdddmf.dd.85)

floppy loader created using cat (http://6reoquestions.com/misc/MightyFrame/ATT7300/Files/vhb.020.cat.1)

*NOTE* The source file for the iv process is the unmodified loader14cust (http://6reoquestions.com/misc/MightyFrame/ATT7300/Files/loader14cust), while I modified the source for the dd and cat files to match the VHB that the iv process creates "on top of" the loader. Here is my modified source file for dd and cat only (http://6reoquestions.com/misc/MightyFrame/ATT7300/Files/loader14SourceTOdd).

I'm using HxD - Hexeditor
Version 1.7.7.0
Running on Windows 7
http://www.mh-nexus.de/

I can see 0D characters throughout on the floppy loader created using iv.

However, I cannot see any 0D characters on either of the other 2 using dd or cat. It seems that the 0D characters are the only characters.

Can anyone else see the 0D characters in the iv file, and not see them in the dd or the cat files?

Now, maybe it's missing something else too, but I'm not seeing it.

As the page on my site ( http://bit.ly/1wU1k8c ) discusses in great detail, the iv file works "better" in operation than the dd or the cat, and the 0D characters are the only difference that I can see. The obvious question is "well, then, just use the iv process", but it truncates the file, so it hangs after some processing, while the dd and the cat files just won't even start the process. Again, great detail on my page.

This is a really interesting scenario.

Again, I appreciate everyone's input.

-AJ

Trixter
November 5th, 2014, 07:59 AM
My initial test tells me that cat has removed the 0D characters just like dd has.

Are you using the right device for the floppy? There should be a "cooked" and a "raw" device. You want the raw device; the cooked device will translate.

firebirdta84
November 5th, 2014, 06:00 PM
Thanks for asking, Trixter.

Yes, I believe I am. /dev/rfp020 should be the raw device on the UNIX PC. So, I'm wondering, if that terminology you are using, "raw" and "cooked", is somewhat standard nomenclature, than could the "r" in "rfp020" stand for "raw"?

I can access the floppy drive using /dev/fp020 also, but none of the examples of utilities (such as iv) that write a VHB and boot loader use that, they all use only /dev/rfp020.

Trixter
November 5th, 2014, 06:16 PM
Then I believe you are indeed using the raw device... and I'm afraid I'm stumped as well.

Tor
November 6th, 2014, 12:11 AM
It does look like it's the device (well, the driver) that's removing the 0Ds.. 'cat' does nothing of the sort, and it's strange that 'dd' would also. 'dd' does other kinds of conversions if you ask it to, but I've never heard about a '0d' stripping mode. Unfortunately I've no further ideas either, it's the first time I've heard about a floppy driver doing that. Must be possible to solve though.

-Tor