How do you extend the output of ps -fe in Solaris so that it displays more than 80 characters? My process has several arguments and the process name could not be displayed anymore.
You can't display them with the default ps (/usr/bin/ps) which is a SVR4 regular one.
To get the full argument line, use the BSD ps (UCB = University of California at Berkeley):
/usr/ucb/ps -alxwww
We have finally fixed this in Solaris; as of Solaris 11.3 SRU 5, all original argument vectors as well as the environment variables can be retrieved from /proc. ps will now print all of the command line.
Fixed in Solaris 11.3 SRU 5
The simple answer is that there is no way to reliably acquire the full arguments to processes on Solaris for processes owned by other users. If you have root or other privileged access you can use /usr/ucb/ps on older versions, and 'pargs' or similar tools on newer versions (there is no tool which works across all versions).
Essentially Solaris stores the original args at process start time, while most other platforms allow ps to access, via some means, the contents of argv at runtime for the process. This stored-copy is in a special kernel data structure with limited (80 byte) size. This also means that it's not possible for a program to modify the args post-start as displayed by ps for useful or nefarious means.
Thus, if you need to access the command line for portable purposes, such as pid checking, you will need to choose between enforcing a short command line via hacks like launching programs controlled execp paths without absolute paths, or you will need to forgo that portable functionality on Solaris.
you can use pargs PID
it will give you more information than ps
Try ps -efl. If that doesn't work (I don't have a Solaris box handy) you can also try ps -efl | cat (as some programs check whether they're outputting to a terminal to decide on their output width).
There are two sets of options available for ps. Others will chime in with the correct names ( ( maybe BSD and SRVn)?)
With the non-options-preceded-with-a-hyphen-version, you can do
ps auxww(w?) | grep ${PID} to extend the length of the command detail that is printed (again, notice NO leading '-' option indicator).
Note that in some cases you will see a lot of environment variable assignments before the actually command, i.e. myPath=... cfgFile=... /path/to/command ... args ...
I think that 'www' in some systems will print everything, regardless how long the command is.
Finally, in my experience using ps to do a lot of crazy things, I would ocassionally have a PID and the output would display the first 6? columns, but the space reserved for the command was empty or had some sort of place holder value. I eventually found out why that was true, by searching comp.unix.shell, but it's too long ago now to be sure and I don't have access to Solaris systems right now.
I hope this helps.
Related
I want to send commands in the ADB shell itself as if i had done the following in cmd.
>adb shell
shell#:/ <command>
I am using python 3.4 on a windows 7 OS 64bit machine. I can send one-line shell commands simply using subprocess.getoutput such as:
subprocess.getoutput ('adb pull /storage/sdcard0/file.txt')
as long as the adb commands themselves are recognized by ADB specifically, such as pull and push, however there are other commands such as grep that need to be run IN the shell, like above, since they are not recognized by adb. for example, the following line will not work:
subprocess.getoutput ('adb shell ls -l | grep ...')
To enter the commands in the shell I thought I needed some kind of expect library as that is what 'everyone' suggests, however pexpect, wexpect, and winexpect all failed to work. they were written for python 2 and after being ported to python 3 and my going through the .py files by hand, even those tweaked for windows, nothing was working - each of them for different reasons.
how can i send the input i want to the adb shell directly?
If none of the already recommended shortcuts work for you you can still go the 'regular' way using 'subprocess.Popen' for entering commands in the adb shell with Popen:
cmd1 = 'adb shell'
cmd2 = 'ls -l | grep ...'
p = subprocess.Popen(cmd1.split(), stdin=PIPE)
time.sleep(1)
p.stdin.write(cmd2.encode('utf-8'))
p.stdin.write('\n'.encode('utf-8'))
p.stdin.flush()
time.sleep(3)
p.kill()
Some things to remember:
even though you import subprocess you still need to invoke subprocess.Popen
sending cmd1 as a string or as items in a list should work too but '.split()' does the trick and is easier on the eyes
since you only specidfied you want to enter input to the shell you only need stdin=PIPE. stdout would only be necessary if you wanted to receive output from the shell
time.sleep(1) isn't really necessary, however since many complained about input issues being faster or slower in python 2 vs 3 consider maybe using it. 'they' might have been using versions of 'expect' that need the shell's reply first. this code also worked when i tested it with simply swapping out and in the process with time.sleep(0)
stdin.write will return an error if the input is not encoded properly. python's default is unicode. entering by binary did not work for me in my tests like this "b\ls ..." but .encode() worked. dont forget the endline!
if you use .encode() there is a worry that the line might not get sent properly, so to be sure it might be good to include a flush().
time.sleep(3) is completely uneccesary, but if your command takes a long time to execute (eg a regressive search through the entire device piped out to a txt file on the memory card) maybe give it some extra time before killing anyhting.
remember to kill. if you didnt kill it, the pipe may remain open, and even after exiting the test app on the console the next commend still went to the shell even though the prompt appearsed to be my regular cmd prompt.
Amichai, I have to start with pointing out that your own "solution" is pretty awful. And your explanation makes it even worse. Doing all those unnecessary things just because you do not understand how shell (here I mean your PC's OS shell, not adb) command parsing works.
When all you needed was just this one command:
subprocess.check_output(['adb', 'shell', 'ls /storage/sdcard0 | grep ...']).decode('utf-8')
I want to writing a script in shell for solaris paltform regarding some below commands and their output should written in excel file or text file as a output.
How many servers are deployed under global
zone --- zoneadm list -cv
H/w architecture
showrev -a
OS Related Information
uname -a
RAM and its Utilization
echo "::memstat" | mdb -k
Internal Disk
echo | format
Which service is running on which node
hares -state |grep "ONLINE"
Solaris is a not something I am familar with. I think I have logged in once or twice in my life.
However, unix/linux I have some experience with.
You simple need to put your commands in a script file often ends with *sh (myscriptfile.sh). then you simply run the script.
That being said. You need to read up on
output redirect (that is out you write the output to file).
And learn more about your 'shell'. I would further recommend using bash (I believe out-of-the-box solaris uses something different). Bash scripting is far more popular therefore you will find greater support.
So, I need to run a program, not keep track of its PID (in memory, at least), and later kill that program. Any ideas? My immediate thought was to tag the process with something I could find later, but that seems a bust. My next thought was to store on disk the PID, but I've no idea what the convention for that sort of thing is. Any ideas? Thanks!
Your program can create a directory under /var/run/ to store such files. For instance, if your program is myprog it might store its PID on startup in
/var/run/myprog/PID
If your program could have multiple instances running at the same time, you might use the PID itself in the file name, along with its startup time, to ensure a unique file name for each instance.
/var/run/myprog/201410302306.1283.pid
(Note that if you use the PID in the file name, it's up to you if you actually write the PID in the file itself; an empty file would suffice.)
The most straight forward (and common case) is, as you and chepner already mentioned, to store it in a pid file. For this:
If it's a system wide programm:
/var/run/prog.pid
If it's a system installed program that might be run multiple times:
/var/run/prog/prog_instance.pid
If it's a user local program:
$HOME/.prog/prog.pid
Other options might be to use pgrep for finding it as long as you can uniquely define the calling command. For example pass a dummy argument not used and use it for retrieval:
$ prog.sg --instance_1234 &
$ pgrep -f -- '--instance_1234'
3523
you can use start-stop-daemon to start a program and kill it later. It has a lot of options to find the programm, the most usefull is the --pid that stores and retrive the pid from a file in filesystem, usually in /var/run (pay attention to file system privileges to write in it).
See the man pages for more tips.
For a given process ID, what is the best/most direct way to determine the environment variables (e.g. PATH)? Must be able to query for any arbitrary environment variable. PATH is just the first example.
'lsof -a -p $PID -d cwd -F' gets some of it.
But, I don't see a way to get the PATH for the given PID, using lsof.
'ps -Ep $PID' gets some of it.
But, again, 'not comprehensive. It appears to give back only a portion of the 'environment' for the process.
On a number of other Linux/UNIX variants, you can look at '/proc//environ'. But, OS X apparently does not use that mechanism.
You should get this information (and a little extra) with ps -Eww $PID
The reason you were only seeing part of the environment is that ps will trim the output to fit your window (if going to stdout). Adding "ww" to the flags tells ps not to be concerned with window size.
I wrote a script that's retrieving the currently run command using $BASH_COMMAND. The script is basically doing some logic to figure out current command and file being opened for each tmux session. Everything works great, except when user runs a piped command (i.e. cat file | less), in which case $BASH_COMMAND only seems to store the first command before the pipe. As a result, instead of showing the command as less[file] (which is the actual program that has the file open), the script outputs it as cat[file].
One alternative I tried using is relying on history 1 instead of $BASH_COMMAND. There are a couple issues with this alternative as well. First, it does not auto-expand aliases, like $BASH_COMMAND does, which in some cases could cause the script to get confused (for example, if I tell it to ignore ls, but use ll instead (mapped to ls -l), the script will not ignore the command, processing it anyway), and including extra conditionals for each alias doesn't seem like a clean solution. The second problem is that I'm using HISTIGNORE to filter out some common commands, which I still want the script to be aware of, using history will just make the script ignore the last command unless it's tracked by history.
I also tried using ${#PIPESTATUS[#]} to see if the array length is 1 (no pipes) or higher (pipes used, in which case I would retrieve the history instead), but it seems to always only be aware of 1 command as well.
Is anyone aware of other alternatives that could work for me (such as another variable that would store $BASH_COMMAND for the other subcalls that are to be executed after the current subcall is complete, or some way to be aware if the pipe was used in the last command)?
i think that you will need to change a bit your implementation and use "history" command to get it to work. Also, use the command "alias" to check all of the configured alias.. the command "which" to check if the command is actually stored in any PATH dir. good luck