On Tue, 27 Jun 2023, steve jenkin wrote: The problem is the pipe, of course; no Unix I know will allow a seek on a pipe (?), so it will have to be buffered somehow. I'm a bit tied up right now, so I'll take a look later. In the meantime you seem to have lots of responses... -- Dave

Clem, Thanks very much for the note & comments. Of course, amongst the many fine things you’ve done, you’d written a proper, high-quality solution to this problem. I’d expect no less :) I take your point: ‘dd’ is a beast, very subtle with lots of options. Very good idea to use ‘osync’ to pad the last block written out to same size. [ I’ve never though to do that ] What I remember about the script is that ‘dd’ didn’t have to be told the number of media to be written. It detected ‘End of File’ on the input (pipe) and terminated the loop. It’s this action I’ve never solved. There were a few other things done in the body of the loop: writing to the operator the number of the media, to label it reading a response from /dev/tty, to allow the operator to change media eg: read -p "OK? " resp </dev/tty I’ve constructed two examples below of splitting input into fixed blocks. using the easiest repeatable & limited stream I thought of: ls -1 When I know the number of blocks, a for loop does exactly what I hope & expect. Including the trailing short block. But writing a ‘while’ loop with ‘dd’ as the condition - it’s an infinite loop. Even though STDIN is exhausted and ‘dd’ knows it, read returns zero bytes, and ‘dd' doesn’t return an error (because there’s no ‘read error’, just ’No Data'). This Mac example uses ‘bash’. I think in 1985 it was Bourne shell, maybe Korn shell, definitely not ‘csh’. cheers steve ========== iMac1:~/ steve$ ls -1 | wc -c 1071404 iMac1:~/ steve$ ls -1 | for i in {1..108}; do dd of=/dev/null bs=10000 count=1; done 1+0 records in 1+0 records out 10000 bytes transferred in 0.249052 secs (40152 bytes/sec) … another 105 times 10000 bytes transferred in 0.000011 secs (911805217 bytes/sec) 0+1 records in 0+1 records out 1404 bytes transferred in 0.000007 secs (203062166 bytes/sec) ========== iMac1:~/ steve$ ls -1 | while dd of=/dev/null bs=10000 count=1; do : ; done # ‘:’ is a null command within loop 1+0 records in 1+0 records out 10000 bytes transferred in 0.251171 secs (39813 bytes/sec) … another 105 times 0+1 records in 0+1 records out 1404 bytes transferred in 0.000009 secs (154968495 bytes/sec) 0+0 records in 0+0 records out 0 bytes transferred in 0.000006 secs (0 bytes/sec) 0+0 records in 0+0 records out 0 bytes transferred in 0.000007 secs (0 bytes/sec) … and it's an infinite loop, repeating the last group of lines :( ========== -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

Bakul, Thanks for the note. I’d not heard of “makeit” before, will go hunt it down. 1. this was the 1980’s, space was always an issue :) 2. There are many cases where you’ve only got a stream. This distributions were the first time I hit this problem type. 3. The distributions were a compressed tar or cpio of a directory structure, to be exploded at destination. There wasn’t a need to fit files onto media. cheers steve j -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

And i'd wish the shell had "set -o pipefail" much much earlier. So you (sometimes) do things like #(set -o pipefail) >/dev/null 2>&1 && set -o pipefail es=$(exec 3>&1 1>&2; { the_worker "$cmd"; echo $? >&3; } | mytee | mymail) that are super neat (ie that this is possible syntax-wise!), but terrible and cryptical and surely error-prone to do. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

Hi Adam, I think it's already been said that the input is a stream and the chunks should be written to the output media on the fly. -- Cheers, Ralph.