'dd' is a JCL utility from IBM mainframes. Both the Unix command name and syntax are directly lifted from the mainframe version of the ... data definition ... utility.
Oh, really? Interesting. While... odd, I always thought it appropriate to be extra explicit with dd, where for some common uses you've the chance of nuking the wrong disk.
As mentioned in the online manual at http://gnu.org/software/coreutils/dd that command line syntax is inspired by the DD (data definition) statement of OS/360 JCL
Other than the missing dash/double-dash, what exactly is "highly nonstandard" about `dd`?
"f" has been a shortcut for "stream" for decades
fprintf
the `arg=value` syntax is common to many command line tools
grep --color=auto
; and i/o are literally the abbreviations for, well, Input/Output. So we have "input-stream=" and "output-stream=". How is that "highly nonstandard"? Because the dashes are missing?
> But otherwise, try to stick to more standard Unix tools.
`dd` is literally part of POSIX, it doesn't get more standard than that;
Yeah disk destroyer or data deleter or whatever is the old joke, not it's actual name. For those unaware, dd has often been used for stuff like overwriting a file with random noise as a homespun secure delete function, and it can do a lot of damage with small typos in the command.
The double dash was indeed from the GNU project and specifically RMS (though I think it was at the recommendation of someone else whose name I am blanking on). This followed an earlier GNU approach, also from RMS, of using + to signal long options.
The idea, though not the syntax, came from the installation of a TOPS-20 machine and some VMS machines on a lower floor. Our own homegrown OS (ITS) used control characters as commands and had DDT as a shell.
> In the beginning, in the first year or so of Unix, an ideal was formed for what a Unix program would be like…
Note that the approach you’re talking about came straight from the Multics of that era, though Multics already supported some short options at that time.
> None of this explains dd.
Because just as Unix in many ways copied Multics, the dd command copied IBM.
absolutely the case. i'm new to Linux and wasn't around in the good old terminal only days - the abbreviations are arcane
why is ch change directory but chmod is change mode? why not cm? or chd?
i had to look this one up because the only explanation i was given for the name of the command dd was 'disk destroyer'. had to go into some old forum to learn that cc was already taken for make and so they just went to the next letter down the line??
it's buck wild in there. i like it, but i've taken to just treating some commands like magic spells because the commands are so impenetrable
At this point recommending dd really is kind of telling the other person to go fuck themselves. It doesn't even follow the arg format of every other unix command. I had to double check to see if anyone fixed that in the interim. Nope, still a=b syntax, rather than -i device1 -o device2.
That really should be a giant clue that it shouldn't be used by anyone, for any reason. "It could be that the purpose of your life is only to serve as a warning to others."
You could replace ‘dd’ with ‘cat’ here, as in “ssh user@rsync.net "cat > d_dump"”. The ‘dd’ command has absolutely no reason to be used in the vast majority of cases.
This one really made me think. I have never thought about dd before. Although I have wondered about other commands. Perhaps the author should also have added some command options not requiring a minus prefix, e.g. tar, ps.
The manpage [0] reads:
In the first (legacy) form, all option flags except for -C and -I must be contained within the first argument to tar and must not be prefixed by a hyphen (`-'). Option arguments, if any, are processed as subsequent arguments to tar and are processed in the order in which their corresponding option flags have been presented on the command line.
In the second and preferred form, option flags may be given in any order and are immediately followed by their corresponding option argument values.
> The very few executable programs provided with the OS did not have any command-line options
PIP was part of CP/M – it was an external executable rather than a command processor builtin, what in MS-DOS terminology is called an "external command", in CP/M terminology a "transient command" – and PIP did have command line options. It didn't use either hyphen or forward slash, instead it put switches (which it called "parameters") in square brackets, for example:
PIP LPT:=X.ASM[NT8U]
Prints the X.ASM file on the LPT: device (line printer). Option "N" means line add line numbers, "T8" means expand tabs at every 8th position, and "U" means convert lowercase to uppercase. [0]
This is different syntax from DEC operating systems, such as RSX-11M [1] or OS/8 [2], where PIP indeed used slash as an option character.
This "switches in square brackets" convention was used by other commands as well, for example the LINK linker [3]. This convention is (obviously to me) influenced by the IBM CMS mainframe operating system, [4] albeit with the parenthesises of CMS replaced by square brackets. We know Gary Kildall used CMS at the Naval Postgraduate School, and it also (I'd say) influenced CP/M's use of drive letters A-Z (as in CMS file modes) instead of the multi-character disk device names generally used by DEC operating systems.
Square brackets is CP/M's native convention for command line switches. Forward slash is something not native to CP/M, but a convention spread by certain ISVs. I think the linked blog post is likely right that Microsoft introduced this convention in its products, and I'd say it likely spread to other ISVs due to the widespread adoption of Microsoft's development tools. The fact that many larger ISVs used DEC minicomputers as a cross-development platform, not just Microsoft, was likely also a factor. While IBM mainframes influenced Kildall personally, and through him CP/M, IBM mainframes were much less likely to be used by CP/M ISVs than DEC minicomputers, because they were a lot more expensive.
I also use the notation as a convention to indicate that I'm referring to a Unix command (or library function, etc.). E.g., "cat" might refer to a feline, but "cat(1)" should more clearly refer to the Unix / Linux command.
(Where I've got proper markup, I'll typically set commands or references in monospace using backtick notation: `dd`, `cat`, etc.
I wish articles like this would say what ^D means. I remember when I was new to Unix it took me a while to realize that I wasn't supposed to type a literal caret (^) followed by a D.
For reference it means Ctrl+D, unless you you have a strange keyboard from Sun or something.
Legend is wrong, this clearly derived from the mainframe JCL DD command. This is also why the syntax is so non unix-like.
https://en.wikipedia.org/wiki/Job_Control_Language#In-stream...
reply