MacPorts-2.6.3-10.15-Catalina.pkg installer error

[pierswalter (Piers Uso Walter)]

I'm trying to install MacPorts-2.6.3-10.15-Catalina.pkg on macOS 10.15.7 with Xcode 12.0.1. The installation seems to go well, but the post install script fails (I'll attach the installer log).

Afterwards, MacPorts seems to work fine (*), so I'm not sure if the script failure is indicative of an actual problem or not.

(*) I cannot install apr-util though, for which I'll open a separate ticket.

[pierswalter (Piers Uso Walter)]

Installer log file

[jmroot (Joshua Root)]

That's a bit confusing, as it says ./postinstall: Successful! but then says there was an error running postinstall. There indeed was an error while running postinstall:

./postinstall: <dscl_cmd> DS Error: -14136 (eDSRecordNotFound)
./postinstall: An attempt to determine your shell name failed! Please set your MacPorts compatible environment manually.

but the script still should have exited with a return code of 0.

The failed command would have been dscl . -read /Users/piers shell, does that work if you run it manually? If not you might want to look into it, since AFAIK all login accounts should have a shell set.

[pierswalter (Piers Uso Walter)]

Thanks, Joshua for pointing me into this direction.
I had not been aware of the existence of dscl.

And indeed, this fails:

> dscl . -read /Users/piers shell
<dscl_cmd> DS Error: -14136 (eDSRecordNotFound)
> echo $?                       
56

But of course I do have a shell:

> echo $SHELL
/bin/zsh

This is a network account on a new (replacement) computer on which I've never used MacPorts before. My main computer is currently being repaired..

I assumed that the setup of this new computer would be identical to the one on my main computer, but maybe it isn't...
I'll have to look into where dscl gets its information from.

[jmroot (Joshua Root)]

The dscl command tries to get your login shell from Directory Services. That's not necessarily the same as the shell that Terminal runs, depending on its settings.

[pierswalter (Piers Uso Walter)]

Ok, I've researched this a bit now.

On this host, my account is not a local account:
> dscl . -read /Users/piers
<dscl_cmd> DS Error: -14136 (eDSRecordNotFound)

These are the search paths that are set up in Directory Services:
> dscl /Search -read / CSPSearchPath
CSPSearchPath:
/Local/Default
/Active Directory/ILINK/All Domains

I can read my user data from the Active Directory datasource:
> dscl "/Active Directory/ILINK/All Domains" -read /Users/piers | wc -l

224

Or by using /Search as the datasource (this searches through all configured datasources in order):
> dscl /Search -read /Users/piers | wc -l

224

I think that it might be advisable to modify the postinstall script by replacing the datasource specification . by /Search, as in:
dscl /Search -read /Users/piers shell

This would make the command work in more cases than it does now.

However, in my case there seems to be an additional problem.
It turns out that the account information from Active Directory uses the key UserShell instead of shell:
> dscl /Search -read /Users/piers shell

No such key: shell
> dscl /Search -read /Users/piers UserShell
UserShell: /bin/zsh

I do not know if use of the key UserShell is a standard feature of Active Directory or if this is some sort of local peculiarity in our server. Upon a cursory glance I did not find an obvious way how to change the key with which the user shell is being reported.

Anyhow, should use of the key UserShell be a standard feature of Active Directory, then I think that it might be advisable to modify the postinstall script even further by searching for UserShell in a second call whenever the search for shell did not result in a result.

If one or both of my suggestions are being welcomed and if this would help, I'd gladly offer to give it a try and offer a pull request. This may take a while though, as I haven't had the chance to look at the MacPorts sources before...