== People still use _newgrp_ (to my surprise) One of the things that came out of me [[writing about why _newgrp_ exists NewgrpCommandWhy]] and casually mentioning that it was a relic (and that OpenBSD had gotten rid of it) is that a number of people left comments discussing how they actively use _newgrp_ even today. This surprised me more than a bit, although in retrospect it probably shouldn't have. There's long been an aphorism in software development that if you have a large and complicated program (such as a word processor), 80% of the people only use 20% of its features but they all use a slightly different 20% (and so if you make a simple version with 20% of the features, many more people will be uninterested in it than you expect). Unix is not a single program, but it is large and complicated and so it's subject to much the same dynamics. I may use only 20% of the programs on my Unix and you may use only 20% of the ones on yours, but our collections probably don't entirely overlap. (Sometimes this surfaces in those 'share your top N most frequently used shell commands' threads, where you'll find a surprising diversity in all the answers.) The corollary to this is that you can find some people (still) using almost any somewhat obscure Unix command with useful features, and of course that includes _newgrp_. This is true even if you solve the problems they use the command for in entirely different ways (and even if your way is probably objectively better; [[sometimes it's not worth the bother of learning new things VimNotUsingFeatures]]). Among other things, people's use of Unix commands is influenced by their history with Unix, and everyone has taken a somewhat different path there. (I can and do say various things about OpenBSD, but one of their positive sides is their anti-fossilization stance. OpenBSD will remove things, like _newgrp_, even if people are still using them. So will FreeBSD, as it turns out, since in a default FreeBSD installation _newgrp_ is not setuid and as a result doesn't do anything unless you're root.) === Sidebar: What I use instead of _newgrp_ The two big uses for _newgrp_ that came up in comments on [[the original entry NewgrpCommandWhy]] were taking on newly added group permissions (when you've just been added to a group in _/etc/group_) without logging out and then back in again, and insuring that new files get created in the right group. The latter is the easy case. Any time that we actually care what group new files and subdirectories wind up in on our Linux systems, we make the directory setgid so that everything under it inherits whatever group it has. As I discovered before, [[on FreeBSD you don't have a choice ChmodInterestingFailure]], and [[this traditional BSD behavior actually makes plenty of sense BSDDirectoryGroupChoice]]. (I haven't checked OpenBSD but I suspect it behaves the same way as FreeBSD.) My less satisfying answer is for the the 'just added to a new group' case. This doesn't come up for me very often, and when it does I do wind up logging out and then back in again. I may defer having to do a session restart for a while by various mechanisms like sshing to my machine again or using '_su --login_', but eventually there are enough irritations that I want to do a session restart. For instance, things started from my window manager (including new terminal windows) won't be in the new group, so I'll have to keep doing whatever it is to access the group. (It helps that I have gotten session restarts to be relatively low annoyance things, partly in self defense.)