How do I get the full width result for the *nix command "ps"?
I know we can specify something like --cols 1000 but is there anyway I can
the columns and just print out everything?
Try ps -w -w aux. The -w option sets the output to wide, and doing it twice makes the width unlimited. The "aux" part makes it show more information, and is (afaik) pretty standard mode to use. This is of course platform-dependant, the above works with procps version 3.2.7 on Linux.
Specify the w option twice, if you're using BSD-style ps. e.g., ps auwwx. A different set of options apply when using System V ps.
There are two different option syntaxes for ps; the standard POSIX one based on SysV, and the BSD one. GNU ps, as used on linux, supports both, which it can do because the POSIX options have dashes in front and the BSD ones don't, as well as some of it's own options in the normal GNU --long-option-name style.
Anyway, to get all processes in POSIX style is -e, in BSD it's ax (a includes other user's processes, x includes processes without a controlling terminal i.e. daemons).
There is no single option that will make it include all the columns. There are a huge number of possible columns. The POSIX options -f, -F and -L all cause it to show different sets of extra columns, as does the BSD option u (hence the "ps aux" mentioned in another answer is a very common command).
If you really want more columns than that you have to name explicitly which ones you want, using the -o (or o) option. See the man page for a list. There's about a hundred different names you can use, but some of them are duplicates, and others display the same info in different ways.
Related
I want a way to iterate through a list of PIDs scanning for processes with a particular command. For example the columns of ps ax are
PID TTY STAT TIME COMMAND
I was wondering if there was a way for me to determine the COMMAND column of a PID given its number.
The Go language and the ps command are unrelated.
The ps command is part of POSIX specification, and available on all Unix-like systems (including Linux, Solaris, *BSD, ....). Read ps(1). It is related to your operating system (and you probably don't have it on Windows). Read Operating Systems: Three Easy Pieces to learn more about OSes, and some Linux programming book like ALP to learn more about Linux programming. See also intro(2) & syscalls(2) (and find the Go equivalent of them).
I want a way to iterate through a list of PIDs scanning for processes with a particular command.
I was wondering if there was a way for me to determine the COMMAND column of a PID given its number.
This is unrelated to Go. You could use the /proc/ pseudo file system, see proc(5), which exists on all Linux systems, both with and without Go installed on them. /proc/ is internally used by ps(1), top(1), pmap(1), etc...
To iterate on the list of processes (on Linux), you need to read the /proc/ directory for numerical entries (e.g. /proc/1234/ exists if there is a process of pid 1234). To read a directory, use opendir(3), readdir(3), closedir(3), stat(2) in C and they all have their Go equivalent e.g. in ioutils package.
In particular, for process 1234, you could read /proc/1234/cmdline (which contains NUL byte separated strings). Of course you could read that file from some Go program. Try the od -cx /proc/self/cmdline command (using od(1)) to understand the format of that file ...
Pseudofiles in /proc/ are "pipe-like", have an apparent size (as given by stat(2) or by ls(1)...) of 0, and should be read sequentially, see this.
go-ps may be useful for you if you want to do it in a portable way.
I'm looking forward to extract disk memory usage from top command using grep command an save it into a variable available for the bash interpreter.
... and I assume you failed to grep those part from top's output without understanding why...
This happens to many users, the reason is that the top command has a somewhat unexpected output strategy. It does make sense, once you dig into it, but as said, unexpected:
By default, top does not write it's output to stdout which is the precondition so that you can grep through it's output. However if you take a look into it's man page (man top), then you will spot the -b flag you can use to invoke it such that it does write it's output to stdout. This enables you to process the output as you are used to under unixoid environments, for example by "grepping" parts of the output for further usage.
Together with the -n flag which allows you to limit the commands output to a single iteration (again: see the man page) you can construct a simple extraction command:
top -b -n 1|grep "KiB"
I think from here on you will find the way by yourself :-) Have fun!
top provides no information about your hard disk usage.
Take a look at df.
Hello I was wondering if there is a feature in the linux GNU Make that allows me to print the targets and prerequisites that need to be run without actually running them! I'm tracing a massive make environment and hoping to get an idea of the flow! Any other tips would be much appreciated!
ex
$ make -option mytarget
making prereq to mytarget
making prereq to prereq
making prereq to prereq to prereq
making mytarget
done..... etc.
make -n does a "dry run", printing the commands make would run without actually running them.
make -d prints out a huge amount of debugging information about how make is going about its business and deciding what targets to build and in what order.
You can combine the two too. You might also like to know about make -r, which will quiet down the make -d output by not checking any implicit rules, and make -k which will make things keep going in the case of an error (which sometimes happens when doing make -n, depending on how your makefile is set up):
Relevant parts from the make(1) man page:
-d
Print debugging information in addition to normal processing. The
debugging information says which files are being considered for
remaking, which file-times are being compared and with what
results, which files actually need to be remade, which implicit
rules are considered and which are applied -- everything interesting about how make decides what to do.
-k, --keep-going
Continue as much as possible after an error. While the target that failed, and those that depend on it, cannot be remade, the other dependencies of these targets can be processed all the same.
-n, --just-print, --dry-run, --recon
Print the commands that would be executed, but do not execute
them.
-r, --no-builtin-rules
Eliminate use of the built-in implicit rules. Also clear out the
default list of suffixes for suffix rules.
dc is the Unix standard desktop calculator. AFAIK, there are different implementations (like Solaris or GNU for instance).
What is the exact difference between these implementations and what is the minimal subset of operations you can be sure a dc implementation has?
As far as I could find, at least FreeBSD used to use the GNU-Implementation as well,1 but doesn't do so anymore. Solaris seems to have a different Implementation.2 From my first read, I mentiones these things:
Solaris dc lacks these commands |, a, ~, n,
Solaris lacks the commands !=, !> and !<. This is important, because it changes the way shell commands are evaluated. In GNU dc, the sequence !>... is applying the comparison, but in Solaris this would execute the rest of the line as a shell command.
Solaris lacks support of # comments.
In Solaris, Y prints additional debuging information.
Solaris does not accept any command-line arguments.
GNU dc accepts input radices up to 16, Solaris seems to be unlimited (unshure).
what is the equivalent of coreadm solaris command in linux
coreadm allows you to configure various aspects of core file generation (naming patterns, logging, ...) on Solaris systems. Linux isn't as feature rich here and only allows you to
customize the name of the core files. This can be done by writing a format string into
/proc/sys/kernel/core_pattern.
See man 5 core for the details.
Using the method discussed here (see man -s5 core, under Piping core dumps to a program
), you could do something along these lines (with root permissions of course):
~ cat /proc/sys/kernel/core_pattern
|/path/to/a/script some arguments
... and put together a script that reads the coredump on stdin and writes it out to a file whose path is dictated in some other fashion.
From a security standpoint, this seems like a very scary thing to do though. There's a lot of potential gotchas.
As mentioned on the sigquit blog, it looks like changes to /proc/sys/kernel/core_pattern are impermanent and you'd need to make changes to /etc/sysctl.conf by editing it directly, or using sysctl.