Environment: AIX 5
Using whereis does not return the file-names of source/binary files I am looking for.
For example:
whereis FILE
returns
whereis:
Also tried the above command with suitable command options (-b , -m, -s) .. still the same result.
Anyone aware of the change required to modify the syntax of this command to suit the AIX Unix flavor.
Suggestions much appreciated.
I wish folks who ask questions about AIX would put the version of AIX they are running.
whereis works on my 6.1 machine and my 5.3 machine. I usually use type. It is in ksh and in bash and it is built-in. Here is a log of some commands I did:
type whereis
whereis is /bin/whereis
whereis whereis
whereis: /usr/bin/whereis
What fileset is where is in?
lslpp -w /usr/bin/whereis
File Fileset Type
----------------------------------------------------------------------------
/usr/bin/whereis bos.rte.commands File
Ok. what level of that fileset do I have?
lslpp -ch bos.rte.commands
#Path:Fileset:Level:PTF Id:Action:Status:Date:Time
/usr/lib/objrepos:bos.rte.commands:6.1.8.16::APPLY:COMPLETE:12/26/13:14;44;04
/etc/objrepos:bos.rte.commands:6.1.8.16::APPLY:COMPLETE:12/26/13:14;44;08
I thought whereis use to be a script but on my hosts they are binary executables. Here is the output of what on my 5.3 host:
what /usr/bin/whereis
/usr/bin/whereis:
61 1.14 src/bos/usr/ccs/lib/libc/__threads_init.c, libcthrd, bos530 7/11/00 12:04:14
93 1.13 src/bos/usr/bin/whereis/whereis.c, cmdscan, bos53H, h2005_32B1 7/6/05 08:53:01
And from my 6.1 host:
what /usr/bin/whereis
/usr/bin/whereis:
61 1.16 src/bos/usr/ccs/lib/libc/__threads_init.c, libcthrd, bos61B, b2007_33A0 8/2/07 13:09:21
93 1.13.1.1 src/bos/usr/bin/whereis/whereis.c, cmdscan, bos610 2/11/07 14:12:18
I would not be surprised if the SHELL environment variable is involved in all this so you might see if it is set to something odd. I keep my SHELL set to /usr/bin/ksh and then I have my .kshrc exec's me over to bash. Some scripts on AIX do not have the #!/usr/bin/ksh at the top which causes some issues. At this date, I have not bumped into that in a while.
I'm curious what you find. I'm curious what level of AIX you are running.
Good luck
Related
I recently upgraded the openssl version on AIXX 6.1 server.
The install went fine.
But now I'm unable to start new ssh sessions from puty to the server and I'm getting the error "Connection Refused".
But I have one putty terminal open which is active.
I tried the command startsrc -s sshd and it returns a new pid but I'm not able to start new sessions.
I tried the following command too and it gives the foll error:
root:stud -> $ /usr/sbin/sshd -de
exec(): 0509-036 Cannot load program /usr/sbin/sshd because of the following errors:
0509-150 Dependent module /opt/freeware/lib/libcrypto.a(libcrypto.so.0) could not be loaded.
0509-152 Member libcrypto.so.0 is not found in archive
And sshd is inoperative.
root:stud -> $ lssrc -s sshd
Subsystem Group PID Status
sshd ssh inoperative
How can I resolve this issue.
I'm not sure how it worked the first time. That is odd. The error says you need the lib crypto library. Is it installed? i.e. what does
ls /opt/freeware/lib/libcrypto.a
return? If it exists, you want to try:
ar t /opt/freeware/lib/libcrypto.a
and you should see libcrypto.so.0 inside. My guess is one of those two will not be true and you need to install it. But it might be that libcrypto.so.0 will not load for its own reasons.
Is this the official ssh package for AIX or is it something you got somewhere else? (I just compile mine from the source from scratch but that's not easy sometimes).
Is it possible find out what files were produced by a particular script by just having it's pid ?
input:
scriptA.ksh pid: 1234
output:
scriptA.log
OS version: AIX
You could use truss (similar to strace on Linux) for this.
truss scriptA.ksh 2>&1 | grep open
You'll have to sift through some unrelated calls to open(), but your log files will be in there.
Also, truss can attach to existing processes by using the -p switch.
Note: I speak from experience with strace, but it looks like this all holds for truss...
I am hoping someone can help me figure out what setting I might need to overwrite. I am working on a Unix terminal server, running a Linux Xterm linux shell. Everytime I use a command like grep "blah" 2> /dev/null at the shell prompt, the command is run as grep "blah" 2 > /dev/null and needless to say the redirection fails.
xterm version is X.Org 6.8.99.903(238)
I can not update or install anything, this is a locked down production server.
Thanks for any help and illumination on the topic, it is making my grep useless at high directory levels with recursion.
That's Bourne shell syntax, and it doesn't work in c-shell.
The best you can do is
( command >stdout_file ) >&stderr_file
Where you get stdout to one file, and stderr to another. Redirecting just stderr is not possible.
In a comment, you say "A minor note, this is csh". That's not a minor note, that's the cause of the problem. xterm is just a terminal emulator, not a shell; all it does is set up a window that provides textual input and output. csh (or bash, or ...) is the shell, the program that interprets the commands you type.
csh has different syntax for redirection, and doesn't let you redirect just stderr. command > file redirects stdout; command >& file redirects both stdout and stderr.
You say the system doesn't have bash, but it does have ksh. I suggest just using ksh; it will be a lot more familiar to you. Both bash and ksh are derived from the old Bourne shell.
All (?) Unix-like systems will have a Bourne-like shell installed as /bin/sh. Even if you're using csh (or tcsh?) as your interactive shell, you can still invoke sh, even in a one-liner. For example:
sh -c 'command 2>/dev/null'
will invoke sh, which in turn will invoke command and redirect just its stderr to /dev/null.
The purpose of an interactive shell is (mostly) to let you use other commands that are available on the system. sh, or any shell, can be used as just another command.
I'm not following how the environment variable $NLSPATH value is being cleared/reset when running gmake. In my bash shell, if I issue echo $NLSPATH, I see the expected /usr/lib/nls/msg/%L/%N: (etc).
I then create a Makefile like this:
all:
echo $$NLSPATH
echo $$PATH
And running gmake all gives me
echo $NLSPATH
echo $PATH
/usr/bin:/etc:(etc as expected)
I also tried -e with the same result;
gmake -e all
echo $NLSPATH
echo $PATH
/usr/bin:/etc:(etc as expected)
I've looked at /etc/environment and /etc/.profile and $NLSPATH is set correctly there.
Also if I run the standard AIX make, the NLSPATH is shown as expected. So this seems to be gmake and/or the way it invokes the current shell.
Could someone suggest where I should be looking ? [EDIT]
As I'm new, I can't hit answer right away...
Finally found it - The following technote describes it (albeit briefly) as a security limitation;
http://www-01.ibm.com/support/docview.wss?uid=swg21516415
Issuing;
cd /opt/freeware/bin
sudo chmod -s make
solves this issue for me although I'm left wondering there is some aspect of gmake that may later expect the setuid flag.
IIRC GNU make on AIX needs the setgid flag in order to enable the -l flag, because on this OS you can't retrieve the load average of the system as a normal user (no idea why that is considered more of a security issue than having any program that needs to check the load average be setgid, but... no one asked me).
As long as you don't use -l when running GNU make, you won't have any problem.
I have two unix machines, both running AIX 5.3
My $HOME is mounted on machine1.
Using NFS, login machine2 will go to the same $HOME
I login machine2 first, then machine1.
Both using telnet.
The 2 sessions will share the same .sh_history file.
I found out that the fc -l behavior very strange.
In machine2, I issue the commands in telnet:
fc -l
ksh fc -l
Both give the same output.
In machine1,
fc -l
ksh fc -l
give DIFFERENT results
The result for ksh fc -l
is the same as /usr/bin/fc -l
Also, when I run a script like this:
#!/usr/bin/ksh
fc -l
The result is same as /usr/bin/fc -l
Could anyone tell me what happened?
Alvin SIU
Ah, wisdom of the ancients... (Since this post is over a year old.)
Anyway, I just encountered this problem in Solaris 10. Issue seems to be this: When you define a function in /etc/profile, or in any file called by /etc/profile, your HISTFILE variable gets ignored by the Korn shell, and the shell instead uses ".sh_history" when accessing its history. Not sure why this is.
Result is that you see other root shell's commands. You can test it with :
lsof -p $$
or
cat /proc/$$/fd/63
It's possible that the login shell is not ksh or that $HISTFILE is being reset. One thing you can do is echo $HISTFILE in the various situations and see if it's different. Another thing to check is to see what shell you're in using ps.
Bash (default $HOME/.bash_history), for example, will have a different $HISTFILE than ksh (default $HOME/.sh_history).
Another possible reason for the difference is that the builtin fc may be able to see in-memory history that hasn't been written to disk yet (which the external /usr/bin/fc wouldn't be able to see). If this is true, it may be version dependent. Bash, for example, doesn't write history to the file until the shell exits. Ksh (at least the version I'm using) writes it immediately.