1

In Vidar Holen's blog entry Useless Use of dd, he argues that dd is effectively useless, primarily because everything is a file and files can be piped.

We have also seen regularly on all the *nix sites the active discouragement of using cat.

However, then Vidar puts forward this example:

# Rip a cdrom to a .iso file
cat /dev/cdrom > myfile.iso

...and I wonder, is it possible to do this without using cat?

Obviously, the POSIX shell is presuming that the first group of chars is a command (hence "["="test", etc) which is unusual in modern languages with in-place operators. And, being as a shell is really an interpreter, why have we not got to the point where both cat and dd are redundant?

Are there any POSIX-based shells which have fully implemented in-place operators to the point where just /dev/cdrom > myfile.iso would be enough to copy the data from a device to a file?

Or

Is there something in the POSIX specification which makes this kind of feature impossible?

Note that this question is slightly different from the UUOC question in that the example still uses a command at the beginning ("<") and not in-place operators. So it still conforms to the first-word-is-a-command rule.

(BTW, I personally like dd because, without it, speaking Welsh would be a lot less fun. :-p)

  • 2
    Possible duplicate of Is it a UUOC (useless use of cat) to redirect one file to another? – muru Aug 20 '19 at 0:21
  • Works in zsh: unix.stackexchange.com/a/249872/70524 – muru Aug 20 '19 at 0:22
  • 3
    Vidar Holen ignores the fact that dd can be used both at the filesystem level and at the raw disk sector/block level. For example, how would you use cp make a copy of an MBR? Very easy to do using dd, i.e. dd if=/dev/sda of=mbr.backup bs=512 count=1 – fpmurphy Aug 20 '19 at 1:24
  • 1
    < is not a command. – muru Aug 20 '19 at 2:41
  • You can cook up some form of busybox shell including the requested functionality. But the whole idea of shell builtins is to streamline very frequently used commands (at the cost of inevitable incompatibilities, check e.g. the differences between the bash(1) builtin test with the standalone test(1)). – vonbrand Aug 20 '19 at 15:17
5

zsh:

</dev/cdrom >myfile.iso

will do that with only operators (when not in sh emulation). It's still running the $NULLCMD command (cat by default) to do the actual reading and writing, though.


Your proposed syntax

/dev/cdrom > myfile.iso

could actually work now in any POSIX shell — because it doesn't necessarily implicate the shell at all.

What is required is that /dev/cdrom is executable, and that it outputs the contents of the CD when executed. That is something that your kernel or a device driver could provide. Alternatively, the system could have execl (and friends) use /dev/cdrom or its contents as a key to launch another executable (such as cat) with that filename.

In either case, with a suitably-execable /dev/cdrom you'd be absolutely able to run that command in any shell. I don't know of any system that does behave that way, probably for very good reason, but it is theoretically permissible and possible.


POSIX

POSIX requires that the first word of the command be treated as a command name, and it defines how that command must be run:

the shell shall execute the utility in a separate utility environment with actions equivalent to calling the execl() function defined in the System Interfaces volume of POSIX.1-2017 with the path and arg0 arguments set to the command name [...]

If the execl() function fails due to an error equivalent to the [ENOEXEC] error, the shell [...] shall write an error message and shall return an exit status of 126.

It is thus not permitted for a conforming shell to open and print the file for data. There is no particular reason that a shell could not support that behaviour as a non-POSIX extension, however. I suspect that the form you propose has major drawbacks, but zsh's version is largely fine.

  • Great! I thought so. The second part of this answer is what makes in-place operators technically impossible. So cat or any first-place operator can't be completely removed due to the POSIX specification, as I expected. Nonetheless, with all the caveats in the first part it's nice to see that it's theoretically possible. – tu-Reinstate Monica-dor duh Aug 20 '19 at 0:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.