When issuing an 'lls' command in ncftp-3.0beta21-4, I received the following
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
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
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