Opened 15 years ago

Closed 15 years ago

#21877 closed defect (fixed)

bash-completion needs gnu readlink, not bsd

Reported by: adfernandes (Andrew Fernandes) Owned by: raimue (Rainer Müller)
Priority: Normal Milestone:
Component: ports Version: 1.8.1
Keywords: coreutils readlink Cc:
Port: bash-completion

Description

When playing with bash-completion (great job, BTW!) I noticed an error when using "vncviewer":

vncviewer readlink: illegal option -- f
usage: readlink [-n] [file ...]

It turns out that, big surprise, bash-completion requires the GNU version of the readlink command, not the BSD. Rather than mess around with command line options (it is possible to simply remove the unsupported "-f" option and hope for the best!) I decided to patch in a dependency to "greadlink" from coreutils.

Works like a charm, now.

Attachments (2)

Portfile.patch (649 bytes) - added by adfernandes (Andrew Fernandes) 15 years ago.
bash_completion-readlink.patch (428 bytes) - added by adfernandes (Andrew Fernandes) 15 years ago.
use 'greadlink' rather than 'readlink'

Download all attachments as: .zip

Change History (8)

Changed 15 years ago by adfernandes (Andrew Fernandes)

Attachment: Portfile.patch added

Changed 15 years ago by adfernandes (Andrew Fernandes)

use 'greadlink' rather than 'readlink'

comment:1 Changed 15 years ago by mf2k (Frank Schima)

Owner: changed from macports-tickets@… to raimue@…

comment:2 Changed 15 years ago by raimue (Rainer Müller)

Status: newassigned

comment:3 Changed 15 years ago by raimue (Rainer Müller)

Actually this should not happen at all. type -p is a bash builtin returns the real path for the given command. As that is supposed to return the correct path before it even tries to use readlink, I don't understand how to reproduce the issue...

Could you please share the output of ls -la /opt/local/bin/vncviewer?

comment:4 in reply to:  3 Changed 15 years ago by adfernandes (Andrew Fernandes)

Replying to raimue@…:

Actually this should not happen at all. type -p is a bash builtin returns the real path for the given command. As that is supposed to return the correct path before it even tries to use readlink, I don't understand how to reproduce the issue...

Could you please share the output of ls -la /opt/local/bin/vncviewer?

Of course! You know, this is very weird, because there are no links involved in vncviewer as far as I can tell; then again, I'm not sure how bash-completion does its magic... I double-checked, reverting and re-installing, and for me, at least, the behaviour is reproducible.

(I'm the original reporter, BTW... my macports handle changed in the past couple days.)

Last login: Sat Oct 10 16:17:08 on ttys002
Assam:~ andrew$ ls -la /opt/local/bin/vncviewer
104 -r-xr-xr-x  2 root  admin  104088  7 Apr  2009 /opt/local/bin/vncviewer*
Assam:~ andrew$ type vncviewer
vncviewer is /opt/local/bin/vncviewer
Assam:~ andrew$ port provides /opt/local/bin/vncviewer
/opt/local/bin/vncviewer is provided by: tightvnc
Assam:~ andrew$ port contents tightvnc
Port tightvnc contains:
  /opt/local/bin/vncviewer
  /opt/local/share/man/man1/vncviewer.1.gz
  /opt/local/share/vnc/classes/AuthPanel.class
  /opt/local/share/vnc/classes/ButtonPanel.class
  /opt/local/share/vnc/classes/CapabilityInfo.class
  /opt/local/share/vnc/classes/CapsContainer.class
  /opt/local/share/vnc/classes/ClipboardFrame.class
  /opt/local/share/vnc/classes/DesCipher.class
  /opt/local/share/vnc/classes/index.vnc
  /opt/local/share/vnc/classes/InStream.class
  /opt/local/share/vnc/classes/MemInStream.class
  /opt/local/share/vnc/classes/OptionsFrame.class
  /opt/local/share/vnc/classes/RecordingFrame.class
  /opt/local/share/vnc/classes/ReloginPanel.class
  /opt/local/share/vnc/classes/RfbProto.class
  /opt/local/share/vnc/classes/SessionRecorder.class
  /opt/local/share/vnc/classes/SocketFactory.class
  /opt/local/share/vnc/classes/VncCanvas.class
  /opt/local/share/vnc/classes/VncCanvas2.class
  /opt/local/share/vnc/classes/VncViewer.class
  /opt/local/share/vnc/classes/VncViewer.jar
  /opt/local/share/vnc/classes/ZlibInStream.class
Assam:~ andrew$ 

comment:5 Changed 15 years ago by adfernandes (Andrew Fernandes)

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... :-)

comment:6 Changed 15 years ago by raimue (Rainer Müller)

Resolution: fixed
Status: assignedclosed

I decided not to add a dependency on coreutils and instead just removed the -f option which should be enough. In the currently distributed completion set, vncviewer is the only one using _realcommand and therefore it is quite safe this way.

Fixed in r63209.

Note: See TracTickets for help on using tickets.