I LOVE this style of documentation/teaching.
What is it? How does it know that? How did I figure that out?
The second and third question are far more useful but usually not included in documentation or commentary.
Htop explained
81–90 of 105 posts
Re: Htop explained
#82Earlier quoted context omitted.
One of the things that I really dislike about homebrew is its refusal to run via sudo plus the requirement that you own /usr/local. This means: 1) It is a security hole; any application can now modify system-wide applications at any time. 2) You can't have multiple users able to use homebrew. I was expecting homebrew to be something similar to apt/yum/etc, but this makes it pretty fundamentally different. How does Ma…
There's no requirement that Homebrew be in /usr/local. Some individual (poorly-written) packages may assume that, but I've been running Homebrew in $HOME/.brew for multiple years on multiple machines with no issues at all.
That's actually fucking brilliant, and aligns much better with what homebrew is. I'm setting up my new macbook from work tomorrow and this is absolutely the way I'm going to do it, and how I'll suggest any of my colleagues do as well.
Re: Htop explained
#83> It turns out that id gets this information from the /etc/passwd and /etc/group files.
$ strace -e open id 1000
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
open("/etc/group", O_RDONLY|O_CLOEXEC) = 3
A more generic tool is 'getent', which will query all the underlying databases for you. For example: "getent passwd" or "getent group".
Nevertheless, using strace to get a first approximation is an excellent exercise :)
Re: Htop explained
#84I switched to macOS from Linux two weeks ago and I am starting to regret that decision. Most — if not all — the commands that I thought I had mastered after years working on Linux environments stopped working because their BSD counterparts have slightly differences that completely break everything I try to do. It is even more frustrating when I realize that I have to deactivate security features built-in the new Appl…
You normally do not have to disable security features to run programming/debugging tools, contrary to most of the advice you'll see in forums (and sometimes even Stack Exchange). I haven't used dtrace but non-bundled debuggers were a bit of a pain. You can self-sign these using the procedure described by a quick Google.
Re: Htop explained
#85Slightly related utility I discovered to my great delight today: ncdu - "htop for disk space usage" https://dev.yorhel.nl/ncdu
oh yes, i mostly don't bother with 'du -sch' anymore since ive come to know ncdu
Have you tried
du -macx ~ | egrep '^[0-9]{2}' | sort -n
Re: Htop explained
#86I switched to macOS from Linux two weeks ago and I am starting to regret that decision. Most — if not all — the commands that I thought I had mastered after years working on Linux environments stopped working because their BSD counterparts have slightly differences that completely break everything I try to do. It is even more frustrating when I realize that I have to deactivate security features built-in the new Appl…
> Most — if not all — the commands that I thought I had mastered after years working on Linux environments stopped working because their BSD counterparts have slightly differences that completely break everything I try to do.
This is the true 'unix philosophy.'
Re: Htop explained
#87htop is one of the most missed tools when I am on a non-Linux OS. On servers I find atop to actually be a better tool for finding issues that happen incrementally and not an obvious issue. I think that atop and htop both are very complimentary. http://www.atoptool.nl/ "Atop is an ASCII full-screen performance monitor for Linux that is capable of reporting the activity of all processes (even if processes have finished…
unless by non-Linux you meant non-unix, htop recently got updated to better support BSDs and OSX/MacOS.
It can also me installed and run on the new "Ubuntu bash for Windows 10" from Microsoft, which uses the new "Windows subsystem for Linux"
Re: Htop explained
#88I switched to macOS from Linux two weeks ago and I am starting to regret that decision. Most — if not all — the commands that I thought I had mastered after years working on Linux environments stopped working because their BSD counterparts have slightly differences that completely break everything I try to do. It is even more frustrating when I realize that I have to deactivate security features built-in the new Appl…
Very much this. Sometimes the differences are very subtle which makes them more annoying IMO (can you omit the target directory when using `find` if you want to use `pwd`?). For extra points, since you probably aren't deploying on a non-Linux *nix, the PITA will continue in perpetuity.
Re: Htop explained
#89> It turns out that id gets this information from the /etc/passwd and /etc/group files. $ strace -e open id 1000 open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3 open("/etc/group", O_RDONLY|O_CLOEXEC) = 3 Well, by default yes. But if your system is configured to use NIS/YP or LDAP (through NSS/Name Service Switch), then these files won't have all the information (though they'll likely have a few, it's important to have lo…
The problem isn't really that they used strace+id, it's that they abbreviated the output a bit too much. A better clipping would have been:
$ strace -e open id 1000
...
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
...
open("/usr/lib/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
...
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
open("/etc/group", O_RDONLY|O_CLOEXEC) = 3
...
passwd: files
group: files
Re: Htop explained
#90Wow so much unix and shell goodness in this post.
Useful bits/tricks to me:
# see what files a given program opens
strace PROGRAM_HERE 2>&1 | grep open
# get last pid
echo $!
# all sorts of useful commands and information on a given PID
ls -alh /proc/PID_HERE
# get a tree listing of all processes
pstree -a
# echo into a file using sudo
echo "some text here" | sudo tee -a FILE_PATH_HERE