lingo.lol is one of the many independent Mastodon servers you can use to participate in the fediverse.
A place for linguists, philologists, and other lovers of languages.

Server stats:

65
active users

#ldif

0 posts0 participants0 posts today

#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!