UNIX for Advanced & Expert Users

nope, sniff

expendable ? you mean when i hit TAB TAB ?

the patients are

/usr/lib/libc.a <--- is ok , but commands need it call libcrypt.a too ...
/usr/lib/libcrypt.a <--- RIP , it's called now /usr/lib/libcrypt.a.old ,

aix 5.2 power3 , ksh vanilla and a fresh bash4 from oss4aix ...

i am going to complaint a little bit (just like its not my fault : if every programm that needs libc calls libcrypt.a , why they werent sticked together ? ... i know each one contains two kinda of sets of routines ... but fonctionally, having them together ... i wouldnt have done this !! yes my limit is libc, that one even on a unmounted floppy i wont touch it


Regards





Regards

I guess you mean libc.so and libcrypt.so. The .a files aren't used at run time.

under my AIX 5.2 its the .a ... for this libs, and many others are .a , very few .so

and no there is no libxxx.a and libxxx.so in either /lib nor /usr/lib of any "lib" in there .

its and old fashion unix , far from Linux ...

but its the same , if i remeber .so == shared objets , the file is practically just an archive holding the functions/routines ... so AIX calles it a .aRchive ...

here are my messages :
root@toto:/$ ls
Could not load program ls:
Could not load module /usr/lib/libc.a(shr.o).
Dependent module /usr/lib/libcrypt.a(shr.o) could not be loaded.
File /usr/lib/libcrypt.a is not an
archive or the file could not be read properly.


fyi : thnx god I mean, Bash, the tab tab works still, so i was able confirm where is what file ..
thnx again

Not only Gnu/Linux but almost all other Unix and Unix like implementations use .so for shared objects and .a for statically linked archives. AIX doesn't follow that convention.
What you might do to fix your problem is put that libcrypt.a file on some removable media like a USB key or drive, or a CD/DVD and use the LIBPATH trick. Alternatively, just put a statically linked mv command there and you are done.

One remaining issue would be the mount might fail because of that missing library ...

you'r right ... the mount is dead too ahhh i wish there were some statics on that machine ....
thnx for your time

---------- Post updated at 04:48 PM ---------- Previous update was at 04:42 PM ----------

just a note, I think with the prices of the disks today, all crucial binaries should be static,
yes i know i just didnt have to do that ... but bash knows, it might happend to someoneelse otherhow ...
could be a good idea for distros used by paraniods ... a packages of those bins -static version .
until then, i ll do it on my servers,
because talking about other reasons, if a hard disk sector fails, and that sector is used by a lib ... we will have the same issue .. currupted fs ... etc

I disagree with your conclusion.
Statically linked programs are evil and thus are phased out in modern Unix implementations. Dynamically loaded libraries aren't there (only) to save disk space but also to ease upgrade/patching and allow upward compatibility.
About your disk sector point, the best practice is to avoid it in the first place by using some redundancy in your volume management or file system.

Ideas:

Does the computer respond to external "ftp". I wonder if you can rename the file from a ftp session?

Does the computer respond to external rcp? I wonder if you could copy the library to another computer, rename it and copy it back?

bash (but not ksh) has a character-by-character raw read feature (read -r -n1). Maybe someone better with bash than me could use this feature to create a script to binary copy a file?
With umask it might even be possible to get the permissions correct enough to run real commands to fix the problem.