6 ms·
This is one thing I really miss on Linux when compared with the BSDs, especially with dd(1). On BSD you can press ^t to see the status of a command. All you n
by jmclnx 3y ago
This is one thing I really miss on Linux when compared with the BSDs, especially with dd(1). On BSD you can press ^t to see the status of a command. All you need to do is issue this command to activate it:
% stty status '^t'
btw, for Linux dd(1) I know about "status=progress", but for me it is a bit hard to remember and specific to dd(1). But, nice little utility :)
- thedougd 3y agoCtrl-t works for me on DD on Linux.
- deleted 3y ago[deleted]
- yrro 3y agoNot here. I guess you've somehow got ^T to send SIGUSR1 to the foreground process?
- deleted 3y ago[deleted]
- j33zusjuice 3y agoHow often do you use dd that this really matters? Just curious. I’ve run dd maybe 20 times in the 5-6 years I’ve worked with Linux professionally.
- warp 3y agoI occasionally have a new stupid idea for which I want to use a fresh install on a Raspberry Pi, so I flash a new SD card with dd maybe 4-5 times per year. Inevitably it turns out my idea was not as useful as it seemed when it first popped in my head, so after a few weeks/months that Pi is turned off and returned to the pi drawer.... ready for the next brilliant idea. (ps. I typically use the `pv` command to see progress with stuff other than dd)
- MR4D 3y ago> returned to the pi drawer Love that philosophy of keeping an inventory (recycled in this case) of Raspberry Pi’s !
- marcosdumay 3y agoI thought it was the recommended best practice, like with resistor series, 100nF ceramic capacitors, and the more common OP-amps. Do you buy a Pi when first starting a project?
- xp84 3y agoIt sure is best practice, with them still costing like 4x msrp to get your hands on thanks to the neverending shortage.
- jagged-chisel 3y agoRegardless of frequency of use, I always want progress and to verify we haven't stalled. With no output, I'm at the mercy of $RANDOM_BS.
- bennyp101 3y agoAt least 10 times this year so far to copy an image to sd cards. Its reliable and easy
- ordu 3y agoThe infrequency just does the issue worse, because every time I want to see a progress, I'd remember that I needed to add a special option to dd.
- _joel 3y agokill -USR1 {dd pid} ;)
- masklinn 3y agoThe problem with usr1 is it defaults to killing processes, so you may only use it with processes you know handle it that way. Info defaults to dumping generic stuff, it’s completely safe (unless a dev decided to handle it by dying but I would not want to use their software).
- _joel 3y agoThis is with dd though, which will print the progress with a USR1 signal. It's not for other binaries.
- jagged-chisel 3y agodd if=<input> | pv | dd of=<output> to get a count of bytes passing through, or pv <input> | dd of=<output> to get actual completion progress. For tarchives, pv <tarchive> | tar x Compression progress pv <file> | bzip2 > <file>.bz2
- cellularmitosis 3y agoThis is also handy when using socat to pipe across a network. You can use pv on both ends, one looking at compressed and the other looking at uncompressed data, in order to observe the real-time compression ratio. tar c foo | pv | gzip | socat - tcp-listen:9999 socat tcp:bar:9999 - | pv > foo.tar.gz If pv shows that you aren’t saturating your network and are cpu limited, replace gzip with lzop. If vice versa, replace gzip with something more aggressive.
- upon_drumhead 3y agopv has a multi line mode so you can do tar c foo | pv -cN raw | gzip | pv -cN compressed | whatever else It’s handy to see multiple progress bars at once.
- formerly_proven 3y agozstd --adapt, used to have a few rough edges though.
- Self-Perfection 3y agopv also has little known ability to watch already running process in similar fashion to progress tool Try cp $BIGFILE ${BIGFILE}_1 & pv --watchfd $(pidof cp)
- anonymousiam 3y ago'pv' is great, but you need to have the foresight to use it in your command before you run it. 'progress' seems great for those cases where you didn't realize your job was going to take so long, and you don't want to start it all over again.
- tssva 3y agoDon't try to remember adding status=progress. Add a shell alias for dd.
- loeg 3y agoAnd then remember to copy that to every machine you use, I guess. Including one-offs.
- tssva 3y agoOr automate it.
- bartvk 3y agoYou personalize your shell, don’t you? At least I do. My dot files such as .zshrc are in a fit repo, which I check out on a new machine.
- loeg 3y agoI don't personalize shell environments on every machine I ssh to, no.
- midoBB 3y agoI tend to setup my servers, vms and machines with Nix. It takes care of having the same setup everywhere I interact with.
- Ballas 3y agoPerhaps an alias in your .bashrc for dd would solve it? I usually just use ddrescue most of the time (primarily because I prefer it's usage syntax, but it also reports status). Similarly you could alias rsync instead of copy and move: alias pcp='rsync -au --info=progress2' alias pmv='rsync -aP --info=progress2 --remove-source-files'
- animal-hash 3y agoThere's also dd status status=LEVEL The LEVEL of information to print to stderr; 'none' suppresses everything but error messages, 'noxfer' suppresses the final transfer statistics, 'progress' shows periodic transfer statistics and pv pv - monitor the progress of data through a pipe So with pv, you can do something like dd if=/dev/zero count=2 bs=512 | pv | dd of=/dev/null to visualize your dd progress.
- Ballas 3y agoI am aware of both of those, but in my case I prefer ddrescue for the syntax. For backup scripts I use dd and pv (and pigz). I recall I started using ddrescue because one of my distros would not autocomplete with the if= prefix, but I can't seem to replicate it currently - so it's probably been fixed (or my memory is failing me).
- deleted 3y ago[deleted]
- loeg 3y agoCan't speak to the others, but on FreeBSD you don't need to activate ^t (SIGINFO); it just works that way out of the box.
- kazinator 3y agoI'm astonished that the BSD projects are merging un-Unix-like fluff like this. Meanwhile, the Linux kernel has removed Shift-PgUp scrollback from the console.
- mardifoufs 3y agoWhy did they do that? I'm sure there's a good reason but it sounds interesting!
- JdeBP 3y agoThe good reason is apparently that scrollback in vgacon was broken and there was no-one to fix it. No-one has stepped up to volunteer to keep it fixed in the future in the two and a half years since then. * https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=20782abbbdfe922496a28f9cc0c3c0030f7dfb8f https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
- pengaru 3y agoLong-term we'll probably end up with the console in userspace, which should naturally normalize scrollback behavior across all the kms drivers. There's already kmscon but I haven't looked closely into what prevented that transition from moving forward as the default. Presumably there's a bunch of edge cases a kernel based console doesn't suffer from, like having to avoid oom killer or getting paged out/becoming unresponsive on systems falling over etc. The console process will have to be something exceptionally configured, pinned memory, realtime priority, oom-immune, all that jazz.
- JdeBP 3y agoNot really. Most of such a system can just be ordinary processes, and there's no requirement for pinned memory anywhere. Pretty much only the terminal emulator processes are problems if they die, as that effectively becomes a hangup signal, so only they need the oom immunity, if that. * https://jdebp.uk/Proposals/linux-console-daemon.html https://jdebp.uk/Proposals/linux-console-daemon.html What happened to kmscon is that the systemd people, having adopted it with much hullabaloo, dropped it a while later with far less fanfare. That said, there are a range of options for people who want to build Linux without CONFIG_VT. * https://jdebp.uk/Softwares/nosh/user-vt-screenshots.html https://jdebp.uk/Softwares/nosh/user-vt-screenshots.html * https://jdebp.uk/Softwares/nosh/guide/user-virtual-terminals.html https://jdebp.uk/Softwares/nosh/guide/user-virtual-terminals... (-:
- emmelaich 3y agoFWIW, dd will give a status if signalled. SIGUSR1 on Linux, SIGINFO on macos.
- sillystuff 3y agoYou can send a USR1 signal to dd and it will print its progress.
- Nursie 3y agoLinux did also spits out status if you kill -USR1 it, which is useful when you forgot to progress=status it.
- mat_epice 3y agoYou can get status on-the-fly from dd on Linux as well by sending the USR1 signal. [user@machine ~]$ dd if=/dev/zero of=/dev/null & [1] 3254428 [user@machine ~]$ kill -USR1 %1 19061394+0 records in 19061393+0 records out 9759433216 bytes (9.8 GB, 9.1 GiB) copied, 6.06968 s, 1.5 GB/s [user@machine ~]$ kill -USR1 %1 25868762+0 records in 25868762+0 records out 13244806144 bytes (13 GB, 12 GiB) copied, 8.97352 s, 1.5 GB/s [user@machine ~]$ kill %1 [1]+ Terminated dd if=/dev/zero of=/dev/null
- amatecha 3y agoAh, exactly the comment I was hoping to see on here as I forgot how you could query this. Thanks!
- kazinator 3y agoThis only works because you're allowing backgrounded processes to write to the terminal (stty -tostop). Try stty tostop kaz@sun-go:~/txr$ stty -tostop kaz@sun-go:~/txr$ dd if=/dev/zero of=/dev/null & [1] 14604 kaz@sun-go:~/txr$ kill -USR1 %1 kaz@sun-go:~/txr$ 1142200+0 records in 1142200+0 records out 584806400 bytes (585 MB, 558 MiB) copied, 2.62053 s, 223 MB/s kaz@sun-go:~/txr$ kill -USR1 %1 2054884+0 records in 2054883+0 records out 1052100096 bytes (1.1 GB, 1003 MiB) copied, 4.70066 s, 224 MB/s kaz@sun-go:~/txr$ kaz@sun-go:~/txr$ stty tostop kaz@sun-go:~/txr$ kill -USR1 %1 kaz@sun-go:~/txr$ kill -USR1 %1 [1]+ Stopped dd if=/dev/zero of=/dev/null kaz@sun-go:~/txr$ kill -USR1 %1 [1]+ Stopped dd if=/dev/zero of=/dev/null kaz@sun-go:~/txr$