161–170 of 178 posts
Earlier quoted context omitted.
>pv /dev/sdb Huh? pv can cat stuff on it's own, and it will be able to make a progress bar based on the filesize pv image.img > /dev/sdb
So I suppose that the command pv /dev/sdb would actually need to buffer the complete file, before commencing to write to the device (and showing the progress), which would defeat the whole idea of showing progress.
Earlier quoted context omitted.
The other reason for dd existence is that back in the day if you wrote to a block device with a write(2) size of anything other than a multiple of the devices actual block size you'd get a EIO or a EINVAL. So the program you used to make sure the write(2) size was always correct was dd. In the old days some truly weird block devices would accept a write(2) that used only the exact block size, i.e. you could only read…
> back in the day if you wrote to a block device with a write(2) size of anything other than a multiple of the devices actual block size you'd get a EIO or a EINVAL It's not back in the day, it's still true. In Linux, block devices are kernel-cached by default, unless opened with O_DIRECT flag. In general UNIX case (for example, FreeBSD), they aren't: https://www.freebsd.org/doc/en/books/arch-handbook/driverbas... So…
The raw/cooked device thing crossed my mind but thought it would distract from the point-by-point here..
Earlier quoted context omitted.
On Unix, there's SIGINFO, which doesn't exist on Linux systems. That's why coreutils' dd uses SIGUSR1 instead.
OK, I take I didn't know of BSD-specific signal. But please don't claim it's on Unix , because it's not. Unless you can point me where in SUS (or any other specification) it is defined, as I couldn't find it here: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sign...
Earlier quoted context omitted.
Definitely this. I have found many times that I'm an offender of these "bad practices", and usually that's because a certain pattern I learned way back in the beginnings of my Linux days still hangs around. Embarrassingly, it took me a long time before I started reaching for man pages instead of Google. That has probably has had the biggest effect on tightening up my command line fu. find is another tool that seems t…
I learned Linux this way a decade and a half ago when it was far (and still is imho!) more convenient to quickly search a man page than google something. (with slow internet start times, browser startup times, etc) Now, sometimes when people watch me work in a shared session they comment on my "peculiar" (to them) usage of flipping between -h --help and man $command, because there's a whole lot of switches I have mem…
Earlier quoted context omitted.
Anyone who didn't invest $150 back then also missed the opportunity
True, but it feels worse to have had the opportunity in one's hands and thrown it away than never to have touched it at all. That's just how humans work - go figure.
The Ignorance Of Err Ignorant People dd is a tool. dd can do a lot more then cat. dd can count, seek, skip (seek/drop input), and do basic-ish data conversion. dd is standard, even more standard then cat (the GNU breed). I even used it to flip a byte in a binary, a couple of times. New-ish gnu dd even adds a nice progress display option (standard is sending it sigusr1, since dd is made to be scripted where only the e…
http://www.linuxquestions.org/linux/answers/Applications_GUI...
cat image.iso | pv >/dev/sdb
pv image.iso >/dev/sdbEarlier quoted context omitted.
But if you don't use any process, what process is doing the reading? (This sounds like a zen koan somehow.)
I like the koan. But the point should be an additional process. In a UUOC avoidance case, it's the current process which reads, generally via stdin. Say, the shell, or dd itself with an 'if=' parameter. Which I strongly suspect you know.
"This is a strange program of obscure provenance that somehow, still manages to survive in the 21st century." -> links to wikipedia page with direct discription of lineage back to 5th ed research unix "That weird bs=4M argument in the dd version isn’t actually doing anything special—all it’s doing is instructing the dd command to use a 4 MB buffer size while copying. But who cares? Why not just let the command figure…
> pv (You probably know this as you use OpenBSD, but) something I really like about BSDs is that nost of the core commands respond to ^T with progress info ofsome kin, dd included.
Earlier quoted context omitted.
> pv (You probably know this as you use OpenBSD, but) something I really like about BSDs is that nost of the core commands respond to ^T with progress info ofsome kin, dd included.
cool - by default, ^T generates the non-standard SIGINFO. That seems to be true of other BSDs as well, including OS X.