You are not logged in.
Pages: 1
I'm posting in "Newbie corner" because there is no other category this fits
Here is the situation:
I have a directory with about 12800 files - these files are all 0 byte files and have names corresponding to files in /usr
I made this directory for an exercise to teach wildcard and shell globbing to students for a shell scripting book I wrote in 2018 - I kept the files 0 bytes so that the zip file for that lesson would be minimal sized
Today I had to test some code in JS that implements globbing, so I went to that folder to use the names as test data, and if I list it I get:
rep /home/robin/Lesson1/data1 $ ls
ls: error while loading shared libraries: libcap.so.2: file too shortls works fine in other directories
This almost seems like the behaviour on Windows where the current directory is executable and shared libraries get loaded from there - So I checked PATH and LD_LIBRARY_PATH
rep /home/robin/Lesson1/data1 $ echo $PATH
/home/rep/.yarn/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/rep/.local/bin/:/home/rep/go/bin
rep /home/robin/Lesson1/data1 $ echo $LD_LIBRARY_PATH
/usr/lib/vmware/lib/libglibmm-2.4.so.1/:
rep /home/robin/Lesson1/data1 $Any external command I run in that directory fails with a similar error on some library or other.
What could be happening?
Thanks in advance
Last edited by rep_movsd (2020-09-21 14:32:30)
Offline
Maybe incomplete system upgrade? try first a full system update, restart in case kernel update, and then reinstall core/libcap 2.43-1
Last edited by solskog (2020-09-21 11:29:09)
Offline
From within that directory, post the output of each of the following:
type ls
ldd $(which ls)EDIT: scratch that - look at your LD_LIBRARY_PATH. It includes the current working directory. So anything you run from that zero-byte-file directory will use the libs from within that directory rather than the systemwide libs. Fix your LD_LIBRARY_PATH.
Last edited by Trilby (2020-09-21 13:20:40)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
From within that directory, post the output of each of the following:
type ls ldd $(which ls)EDIT: scratch that - look at your LD_LIBRARY_PATH. It includes the current working directory. So anything you run from that zero-byte-file directory will use the libs from within that directory rather than the systemwide libs. Fix your LD_LIBRARY_PATH.
You're right - it is LD_LIBRARY_PATH
Does the trailing colon cause the last empty entry become equal to "." ?
I need to figure out where that is being set
Thanks!
Offline
LD_LIBRARY_PATH
A list of directories in which to search for ELF libraries at execution time. The items in the list are separated by either colons or semicolons, and there is no support for escaping either separator. A zero-length directory name in‐dicates the current working directory.
I gather something related to vmware took a pretty naive approach to prepending it's path to the variable. As LD_LIBRARY_PATH will often be empty, one must check before prepending to it. If it is empty, the variable should just be set to the new path. If it is not empty, the variable should have the new path and a colon prepended to it. But rather than doing this check, whatever set that variable, just prepended (to an empty variable) with the new path and a colon.
Check any files provided by any vmware packages - particularly anything under /etc/profile which would be the appropriate place for such changes to be made (though expecting the changes to be done in the right place when they are not done in the right way is not a great assumption).
Last edited by Trilby (2020-09-21 14:55:41)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Pages: 1