181–190 of 259 posts
Earlier quoted context omitted.
Agreed, and my problem with even the usage above is that I often realize too late that "whatever" is not going to finish before I need to unplug. Then I have to kill "whatever" and restart with nohup and logging. tmux/screen always has me covered.
Obviously I think tmux/screen is the better option, but bash's builtin 'disown' may have you covered for that specific usecase.
If anyone is interested there were several great posts on Hacker News a while about about useful UNIX commands [1, 2, 3]. I have also created several screencasts about command commands like the following [4], and one about the Filesystem Hierarchy Standard [5]. ls man pwd cd top ps df du cp mv rm mkdir rmdir less cat vi [1] https://news.ycombinator.com/item?id=6046682 [2] https://news.ycombinator.com/item?id=5022457…
this time, the very first one `man ascii` got me. Genius. Never though about looking for that in man before. But in my defense, this was added in 1999 :)
If anyone is interested there were several great posts on Hacker News a while about about useful UNIX commands [1, 2, 3]. I have also created several screencasts about command commands like the following [4], and one about the Filesystem Hierarchy Standard [5]. ls man pwd cd top ps df du cp mv rm mkdir rmdir less cat vi [1] https://news.ycombinator.com/item?id=6046682 [2] https://news.ycombinator.com/item?id=5022457…
i usually click those links, see the stuff and roll up my eyes. nothing learned, but upvote so more people learn about them anyway. this time, the very first one `man ascii` got me. Genius. Never though about looking for that in man before. But in my defense, this was added in 1999 :)
I'm sure that was a bit earlier than 1999.
My favorite is the parallel jobs feature of xargs. For example, say you want to run a script you wrote called process-video.sh to do some processing on all the video files in a directory (extracting audio to MP3, converting format, etc.). You want to use all 8 of your cores. You could write a Makefile and run it with -j9, or you can do this: find . -name "*.flv" | xargs -n 1 -P 9 ./process-video.sh This immediately f…
May I ask, what do you gain by setting it to +1 cores?
If you have 8 cores running 8 jobs, then whenever one of those jobs needs to do I/O you have a core sitting idle while that job waits for the disk. If you have 8 cores running 9 jobs, then all your cores will still be fully utilized when a single job is doing I/O.
I think you actually want to do plus a small percentage, perhaps 5%, so ceil(1.05*N) jobs on N cores. That is, I have a gut feeling that 64 cores doing 65 jobs would still result in underutilization, 67-68 jobs would be better (provided the workload doesn't become I/O-limited with that much CPU power, and provided the number of videos to be converted is still much larger than the number of cores, so you don't run afoul of Amdahl's law).
These are really just rules of thumb based on my gut feelings and mental models of how the system works; it might be fun to actually benchmark it and see if my ideas correspond to reality. (You probably want to reboot first, or a bunch of unrelated I/O, to flush the disk cache.)
bash(?) thing I wish I'd discovered years earlier: diff file1; command2 > file2; diff file1 file2; rm file1 file2
If anyone is interested there were several great posts on Hacker News a while about about useful UNIX commands [1, 2, 3]. I have also created several screencasts about command commands like the following [4], and one about the Filesystem Hierarchy Standard [5]. ls man pwd cd top ps df du cp mv rm mkdir rmdir less cat vi [1] https://news.ycombinator.com/item?id=6046682 [2] https://news.ycombinator.com/item?id=5022457…
Great links, though I admit when I saw the OP I was expecting content like that and was pleasantly surprised that they really were "Unix commands I wish I'd discovered years earlier", and not the standard array of unix tips+tricks that you can get by without for awhile but as you become more advanced become second-nature. "Man ascii." The number of times that I wound up generating my own ascii table from whatever lan…
I want a command that counts files in a tree like du does sizes but without having to pipe find through wc which is crazy for hundred thousand files. Can't they just directly access inodes for high speed counting?
Compared to the equivalent find, code #1 is much faster in this completely scientific best of several runs:
$ time (find OSS/llvm -type f -or -type l | wc -l)
real 0m4.681s
$ time du -d0 OSS/llvm
real 0m4.863s
$ time ./fts OSS/llvm
real 0m0.559s
edit: screwed up benchmarks
Earlier quoted context omitted.
May I ask, what do you gain by setting it to +1 cores?
Even though CPU is usually the resource that limits throughput for video processing in my experience, each process will presumably do some amount of I/O as well. If you have 8 cores running 8 jobs, then whenever one of those jobs needs to do I/O you have a core sitting idle while that job waits for the disk. If you have 8 cores running 9 jobs, then all your cores will still be fully utilized when a single job is doin…
imap jf
was very nice as I find it much more ergonomic. And to use it in Bash I have
set editing-mode vi set keymap vi
$if mode=vi set keymap vi-insert "jf": vi-movement-mode $endif
set show-all-if-ambiguous on