ps -ef | grep whatever

[Diputs]

One of the annoyances that I haven't fixed yet is this:

When you use
ps -ef
the commands are actually capped on line length, by default. I don't know why they are, but actually that suits ...

... because:
say you run this:
ps -ef | grep whatever
(and there are processes with "whatever" in the process description), he is actually listing the FULL command description. For some commands (typically Java things) that can be 5 lines of text ! Just for one command. Now, if you have 10 of those commands, the output doesn't fix my screen (while being set full screen!).
In other words ... process info capping would be nice, so that my ten commands actually use 10 lines, not 10 times 5 or 10 times 7 ..

So the question is, why does it cap in one command, not the other. The GREP has no capping function, it removes offending lines, no more, no less. So, the GREP should not make a difference.
Either " ps -ef " should not be capping, or " ps -ef | grep whataver " should ...

 

[Alexzee]

I read and browsed through the man page for 'ps -ef' and didn't see any capping mentioned in the synopsis.

Can you give an example of what command you're running that shows the capping you're seeing?

 

[vs2-free-users]

Hi,

if fix this with workaround.

ps -ef | grep -v grep | grep whatever

 

[osprey]

One of the annoyances that I haven't fixed yet is this:

When you use
ps -ef
the commands are actually capped on line length, by default. I don't know why they are, but actually that suits ...

... because:
say you run this:
ps -ef | grep whatever
(and there are processes with "whatever" in the process description), he is actually listing the FULL command description. For some commands (typically Java things) that can be 5 lines of text ! Just for one command. Now, if you have 10 of those commands, the output doesn't fix my screen (while being set full screen!).
In other words ... process info capping would be nice, so that my ten commands actually use 10 lines, not 10 times 5 or 10 times 7 ..

So the question is, why does it cap in one command, not the other. The GREP has no capping function, it removes offending lines, no more, no less. So, the GREP should not make a difference.
Either " ps -ef " should not be capping, or " ps -ef | grep whataver " should ...

The ps command truncates its output with certain commands in order to fit the size of the terminal screen.

Despite that truncated output, the ps command will internally (in memory) have an output that encompasses the non-truncated output of the command. That output becomes visible from a command such as:

ps auxww

When grep is used, its input from the ps command is the non-truncated output, since grep, to fulfil its function, needs to see the whole line of output that ps is offering, and not just the truncated screen print. If grep only applied itself to the truncated output on screen, there would likely be errors of missed elements that grep is being asked to search for.

In any case, the output width of the ps command can be controlled by the --cols options, e.g.

ps aux --cols 40

If grep is applied to the this latter command which limits the screen print to 40 columns, it will only search for an expression over those 40 columns, and not over the full width non-truncated output that ps is capable of.

 

[Diputs]

Hi,

if fix this with workaround.

ps -ef | grep -v grep | grep whatever

That just removes the one line with the "grep" process itself ... Which is a nice trick but it isn't going to solve this issue.

 

[Diputs]

I read and browsed through the man page for 'ps -ef' and didn't see any capping mentioned in the synopsis.

Can you give an example of what command you're running that shows the capping you're seeing?

Yeah, it seems PS has no line capping functions ... yet it does perform capping. Weird, isn't it ?

Examples :

Well, yes, something like this:

java -pVar01 blabla-pVar02 blabla-pVar03 blabla-pVar04 blabla-pVar05 blabla-pVar0x blabla-pVar0y blabla-pVar0z blabla-pVar0a blabla-pVar0b blabla-pVar0c blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla some.java.program

That's 1 process. Now image 25 of those, and then do this:

ps -ef | grep 'some.java.program'

 

[osprey]

The length of the lines of output of the "ps -ef" or the "ps aux" commands is a function of the terminal and fonts, not of the ps commands. This is easily shown by running either of those commands in the same terminal with the smaller and larger size of the font. When a smaller size of font is used, (often in xterminals by pressing shft+ -) the lines ps outputs are longer with more information. The full width becomes available as per post #4 with the ww options. In general the user can control the outputs according to one's reasonable needs.

 

[Alexzee]

Yeah, it seems PS has no line capping functions ... yet it does perform capping. Weird, isn't it ?

Examples :

Well, yes, something like this:

java -pVar01 blabla-pVar02 blabla-pVar03 blabla-pVar04 blabla-pVar05 blabla-pVar0x blabla-pVar0y blabla-pVar0z blabla-pVar0a blabla-pVar0b blabla-pVar0c blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla-pVar01 blabla some.java.program

That's 1 process. Now image 25 of those, and then do this:

ps -ef | grep 'some.java.program'

Weird, indeed.
Though it seems that ps has no line capping functionality yet it in fact performs capping, perhaps it's a default initialization of some sort that is generating the action.

I could be way off however, I'm thinking that if there are any cron jobs or daemons running it may be creating what your seeing. Just an idea.

 

[Diputs]

The ps command truncates its output with certain commands in order to fit the size of the terminal screen.

Despite that truncated output, the ps command will internally (in memory) have an output that encompasses the non-truncated output of the command. That output becomes visible from a command such as:

ps auxww

When grep is used, its input from the ps command is the non-truncated output, since grep, to fulfil its function, needs to see the whole line of output that ps is offering, and not just the truncated screen print. If grep only applied itself to the truncated output on screen, there would likely be errors of missed elements that grep is being asked to search for.

In any case, the output width of the ps command can be controlled by the --cols options, e.g.

ps aux --cols 40

If grep is applied to the this latter command which limits the screen print to 40 columns, it will only search for an expression over those 40 columns, and not over the full width non-truncated output that ps is capable of.

I'll have a try with the "cols" parameter.
But, what I would like to is have GREP look for the info of the FULL line, and then only show a capped line. The fact I use GREP is mostly not look for specific text, but just to remove lines not having that text. In that context, it's werid that ANY command really, has MORE data returned with a GREP command, than the same without. As GREP is just a line filter. Agreed, the number of lines is OK, but not the text.

So, in the end this is still wrong : WHY does "ps -ef" cap the text ? It's not because it has no more info, because as you say, it has that in memory, it just doesn't show.
What if you want "ps -ef" to show all info of all processes ? Well, I know the answer to that, and one solution is " ps -ef | grep . "
But that should not be necessary.

 

[Diputs]

The length of the lines of output of the "ps -ef" or the "ps aux" commands is a function of the terminal and fonts, not of the ps commands. This is easily shown by running either of those commands in the same terminal with the smaller and larger size of the font. When a smaller size of font is used, (often in xterminals by pressing shft+ -) the lines ps outputs are longer with more information. The full width becomes available as per post #4 with the ww options. In general the user can control the outputs according to one's reasonable needs.

That's even weirder ... so the "terminal" decides that if I use PS, I may not see the full output. But when you combine it with a GREP, you can.

That doesn't sound like a terminal behaviour, as it is parsing the content of a statement here, I don't think that is the terminal's job.

 

[Diputs]

Weird, indeed.
Though it seems that ps has no line capping functionality yet it in fact performs capping, perhaps it's a default initialization of some sort that is generating the action.

I could be way off however, I'm thinking that if there are any cron jobs or daemons running it may be creating what your seeing. Just an idea.

No crontab, no daemon, just a command prompt and the "ps -ef" command

 

[osprey]

That's even weirder ... so the "terminal" decides that if I use PS, I may not see the full output. But when you combine it with a GREP, you can.

That doesn't sound like a terminal behaviour, as it is parsing the content of a statement here, I don't think that is the terminal's job.

Alas, it is the user who can decide the degree of output from the ps command in the xterminal, or the framebuffer terminal . It's a matter of options and configuration used.

Rather than the terminal parsing, it's more likely it's receiving and passing along bytes sequentially to fit what it can to screen, given the options available to it. Evidently the ps command outputs lines, not paragraphs or punctuated sentences, so the terminal responds to that. The man command, for example, outputs a different format which the terminal represents accordingly, byte after byte.

I expect it's the same for the console terminal but I don't have one to check at the moment.

 

[KGIII]

The man command, for example, outputs a different format which the terminal represents accordingly, byte after byte.

If one is curious...

When you copy text from the man page (via the terminal), it's a set number of characters with line breaks.

I know this because I need to remove superfluous spaces and fix the formatting when I copy said text for an article.

 

[Diputs]

Alas, it is the user who can decide the degree of output from the ps command in the xterminal, or the framebuffer terminal . It's a matter of options and configuration used.

Rather than the terminal parsing, it's more likely it's receiving and passing along bytes sequentially to fit what it can to screen, given the options available to it. Evidently the ps command outputs lines, not paragraphs or punctuated sentences, so the terminal responds to that. The man command, for example, outputs a different format which the terminal represents accordingly, byte after byte.

I expect it's the same for the console terminal but I don't have one to check at the moment.

Maybe that part get missed, but the first thing you say is already incorrect, as in this case it is not the user that decides the behaviour. It's something else. In fact, this is the core issue of this thread.

So, how do I get a non-capped line by using:

ps -ef

 

[Alexzee]

This Google search is exactly what you are asking for. The search is "how to get a non-capped line when using ps -ef in linux terminal". It's been my experience over the years running Linux that you have to really dig sometimes to get the answer.

how to get a non-capped line when using ps -ef in linux terminal - Google Search

 

[osprey]

Maybe that part get missed, but the first thing you say is already incorrect, as in this case it is not the user that decides the behaviour. It's something else. In fact, this is the core issue of this thread.

So, how do I get a non-capped line by using:

ps -ef

Since in post #1 that the term "capped on line length" is used, I understand it to mean that the line is truncated on the screen. In that case, one can run:

ps -efww

and the output of ps will show the full non-truncated line with all the options of the various processes that are running. The same output effect applies to the command: ps auxww, mentioned in post #4, which I expected the reader would understood to apply to any similar ps command, such as: ps -ef. The ps command has the luxury of responding to both linux syntax commands and BSD syntax commands which have some equivalence. The man page has examples.

If you are simply asking how to get a non-truncated line with the command: ps -ef, the simple answer is that you can't. It needs those further options. You can however, create an alias like:

alias psef="ps -efww"

which would produce the non-truncated ps output using: psef, or some other name that could be given.

To clear up any misunderstanding that may have occurred, in that usage of options to the ps command above, it is the user who decides the degree of output of the ps command by controlling those options that are selected when calling that command. That is the meaning of the text in post #12:

the user who ... decide(s) the degree of output from the ps command

I hope that makes it clear.

As for the form and style in which the ps produces its output, that is wholly dependent on the source code which can be seen from here: https://gitlab.com/procps-ng/procps/-/tree/master/src/ps.