#21877: bash-completion needs gnu readlink, not bsd ----------------------------------+----------------------------------------- Reporter: andrew@… | Owner: raimue@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 1.8.1 Keywords: coreutils readlink | Port: bash-completion ----------------------------------+----------------------------------------- Comment(by adfernandes@…): BTW - I updated to the latest bash-completion, and get the same behaviour: {{{ Assam:libicns andrew$ port installed bash-completion The following ports are currently installed: bash-completion @1.1_2 (active) Assam:libicns andrew$ vncviewer readlink: illegal option -- f usage: readlink [-n] [file ...] readlink: illegal option -- f usage: readlink [-n] [file ...] }}} The change from `readlink` to `greadlink` fixes it, again. With a command that bash-completion knows about, it works: {{{ Assam:libicns andrew$ launchctl bootstrap bslist getenv help list log setenv singleuser stop umask unsetenv bsexec export getrusage limit load remove shutdown start submit unload Assam:libicns andrew$ launchctl }}} There's something weird about `tightvnc`'s `vncviewer` command. Looking at ` /opt/local/etc/bash_completion.d/vncviewer`, I think I see the problem. `bash-completion` makes a distinction between `vncviewer` and `tightvncviewer`. MacPorts' installs the latter as the former. So `bash- completion` looks for commands and files that don't exist. This triggers the "hunt for it" phase, which invokes the `readlink -f` command. If I'm right, this will affect every executable whose name aliases a "known" executable, yet is not identical. I think it is easier to use `greadlink` rather than try to change the package's arcane rules... :-) -- Ticket URL: <http://trac.macports.org/ticket/21877#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS