I have the bad habit of trying out everything in /usr/bin (linux, OX) and in c:\windows\system32 (and further on, digging Program Files / Applications / etc.).
This is how I discovered myself "fsutil" (Windows) :)
Unix Commands I Wish I’d Discovered Years Earlier
191–200 of 259 posts
Re: Unix Commands I Wish I’d Discovered Years Earlier
#192Earlier quoted context omitted.
it's quite a common pattern in commandline apps to check if the stdout is a tty or not, and do things differently if so. So when you pipe it through `cat', it does the no-fancy-included output, much like the colouring that `ls' will apply interactively, but not when piped/redirected.
It's important for grepping and sedding - the colors are escape codes and would mess with your regular expressions otherwise (you want to find foobar , but bar was blue so you got foo\e[1;34mbar\e[0m instead, and it doesn't match with foobar).
On the other hand, if you want colors displayed you can force grep/ack to display the color 'always' and then pipe the output into 'less -R'. The -R (or --RAW-CONTROL-CHARS) flag has less display output such that color escape sequences work as you might expect, coloring the output displayed by less.
Re: Unix Commands I Wish I’d Discovered Years Earlier
#193Re: Unix Commands I Wish I’d Discovered Years Earlier
#194One of the more useful bits of ssh is not mentioned: remotely running commands. Example: ssh username@host "echo $HOSTNAME && sudo somecommand && cat somecommand.log" There's probably a better way to do this, but in a pinch I can fix a problem on dozens of machines just by altering the host string.
sh.py leverages this in command baking http://amoffat.github.io/sh/#baking
Re: Unix Commands I Wish I’d Discovered Years Earlier
#195Mac OS: pbpaste & pbcopy For instance: pbpaste | fgrep -i "`pbpaste -pboard find`" To search the copy clipboard with the find clipboard.
In 2005 I wrote similar utilities for windows called ccopy, ccut & ppaste. I recently dug them up and put them on GitHub. https://github.com/FigBug/ccopyppaste
Re: Unix Commands I Wish I’d Discovered Years Earlier
#196Less +F with search highlighting mentioned in comments is my new fave command. I was beholden to 'tail -f', not that it sucked.
Re: Unix Commands I Wish I’d Discovered Years Earlier
#197ssh, come on...
Re: Unix Commands I Wish I’d Discovered Years Earlier
#198Command line globbing! For the uninitiated: Let's say my pwd is `/home/projects` and i want to edit `/home/projects/a_huge_sprawling_app/940j_394/lol/flight_controller.rb` `vim **/flight_controller.rb` opens our flight_controller.rb straight away. In terms of effort, this allows you to basically omit a `find -name` when you're in a rush to edit some damn file where the hell is it again damn we need to reevaluate this…
FWIW, the double-star recursive globbing was added in Bash 4.0. My reading of the manual[1] suggests it is disabled by default, and can be enabled by setting the 'globstar' shell option. I believe it's enabled by default in zsh. [1]: https://www.gnu.org/software/bash/manual/bash.html#The-Shopt...
I just tried it on bash 4.2.25, and it worked, even though I just learned about it.
Maybe not every OS enables the same default options for Bash (I'm using Lubuntu 12.10 at the moment)
Re: Unix Commands I Wish I’d Discovered Years Earlier
#199Earlier 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…
I definitely agree with the n+1, however when you're dealing with HyperThreading I don't know that I'd bother. The extra 'cores' provided by HyperThreading are not full cores.
The idea behind HyperThreading is basically the same as your n+1 idea. A HyperThreaded core has duplicated circuitry to handle state (registers, etc) but not the execution resources. When one thread is stalled/not using the execution resources (e.g., waiting on disk IO, waiting on a fetch from RAM, etc), the other thread is already in processor ready to go and will be executed instead.
Obviously this is a bit of a simplification, but your n+1 idea is essentially already implemented in the hardware.
That said, if enough of your cores are still stalled waiting on disk/memory access and are stalled long enough to make the context switch worth it, it may be beneficial. If not, however, you might actually end up seeing some minor slow down as the processor is forced to switch between the competing processes.
I'd benchmark it.
Re: Unix Commands I Wish I’d Discovered Years Earlier
#200Earlier quoted context omitted.
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 :)
> An ascii manual page appeared in Version 7 of AT&T UNIX. I'm sure that was a bit earlier than 1999.
true. it appeared in 1985