#Shellprogramming skills are pretty portable between #Linux, #BSD, and #macOS, but some of the underpinnings of macOS are non-standard. It helps to remind yourself that macOS is not a standard #BSD #Unix variant; Apple's #Darwin based systems do a lot of embrace-and-extend under the hood. Here's a practical example that comes up often in the enterprise.

Most #Linux systems export the current user's login name to the LOGNAME environment variable (often via sourcing /etc/profile) and may also export the user's default shell from the user's #GECOS record in /etc/passwd to the preferred shell (set by an application or the user) as the SHELL environment variable. The canonical way to get access to the user's default shell on most Unix-like systems is by parsing /etc/password or another NSS database with the getent utility, e.g. getent passwd "$LOGNAME" | cut -d: -f7.

There are other means to do this on Linux too, but macOS doesn't provide this common #POSIX compatible userspace utility. Instead, Darwin relies on opendirectory(8) for storing and accessing GECOS records, requiring other tools to retrieve the information. You can query a user's GECOS record on Darwin like so:

# directly from the Open Directory service, local or remote
dscl . -read "/Users/$(id -un)" shell | awk '/^shell:/ {print $2}'

# from the directory service's cache on the local system
dscacheutil -q user -a uid "$(id -u)" | awk '/^shell:/ {print $2}'

Be aware that there are other ways to do this, too, but old school utilities like whoami have been deprecated in favor of id -un, and finger as implemented on most systems (e.g. via [x]inetd, or reading various #dotfiles from users' directories locally or over the network) is considered a security risk.

In containers, especially with non-standard shells, or with centralized #IAM using #LDAP or #ActiveDirectory, you may have to match the local #userID to a remote #LDIF record to before grepping for the data you need. In addition, nsswitch.conf, PAM modules, NIS+, or other less-common data sources may need to be consulted and each will generally have specific utilities for looking up the stored or cached information that is equivalent to what's normally provided in the 7th GECOS field for each user on standard Linux and Unix systems.

As always, your mileage may vary based on use case or implementation details. On the plus side, problems are rarely insoluble when you know where to dig for a solution!

@todd_a_jacobs This is insightful. #Cybersecurity isn't just about buying cool new enterprise software or (re-)designing new processes or #technicalcontrols. Sometimes it's just about understanding the tools you already have, and understanding how to access the data you need for #loganalysis, to correlate multi-system logs, or perform other core security functions.
@todd_a_jacobs and yet MacOS has official Unix certification by the open group and the “Unix like” oses such as Linux and FreeBSD are not. So, it really depends on what you mean by “standard” and whose standard you are referring to. That being said I agree that MacOS does things a bit different than the others #mac #linux #freebsd

@Danathar @todd_a_jacobs True! You can be #POSIX compliant and still frustrate any sane *nix user's expectations about how systems work, or do things in non-portable ways. Heck, I use the #fish_shell which doesn't even *try* to be POSIX compliant, but I love working with it anyway and the docs are solid.

I think the real issue is that so much of #Darwin #userland is poorly documented, if at all. That just makes deviations from the norm more painful than necessary IMHO.