When issuing an 'lls' command in ncftp-3.0beta21-4, I received the following message: <--- sh: /bin/less: No such file or directory Segmentation fault (core dumped) ---> It did not seem to matter what the current working directory was, nor whether or not I was connected to a remote host. Apparently, ncftp is expecting the 'less' program to be in /bin instead of / usr/bin. Making a symbolic link to /usr/bin/less in /bin avoids this behavior. I am not qualified to evaluate the potential security implications (if any) of this behavior. I am running RedHat 6.2 on an old AMDx86-133 which I recently upgraded from RedHat 5.2.
This is fixed in 3.0.1. Symlinking /usr/bin/less to /bin doesn't hurt, though the better fix was to fix the hardcode in ncftp.
There was acutally another bug here in the lls command which was not related to ncftp not finding /bin/less resp. /usr/bin/less: There was a reproducible effect of one pclose being done twice, which usually really messes up memory and stack. I've done a fix for that and put it in up for the next releases/upgrades as it's not extremely bad. Read ya, Phil
Fixed for 3.0.2, so it won't crash if the pager program does not exist. When NcFTP chooses a pager for the first time (i.e. one to write to ~/.ncftp/prefs) it uses the $PAGER environment variable if available, otherwise it just uses "more". I'm guessing the reason /bin/less was used was because PAGER=/bin/less.