Question regarding procs output

Hi all, :wave:

I installed procs as a modern replacement to the ps command as seen on procs: Rust Alternative to ps Command in Linux.

It´s very interesting and I like it a lot. I also use it on my Debian and Archlinux virtual machines.
But I noticed, although the output is the same on all machines, there´s a tiny difference to be seen.

Here´s the output of ./procs on my Linux Lite daily driver:

and here´s how it looks like on my Debian VM:

The difference is in the end of the lines. Why is there a little “arrow right” at the end of each line when I use it on Linux Lite but not when I use it on my Debian system :question:
What does that arrow mean :thinking:

On Arch I also get those arrows.
And even in the itsfoss article (URL see above and here) they are present.

Does anyone know something about it?

Many thanks and advance and cheers from Rosika :slightly_smiling_face:

2 Likes

Just my guess:
some of the lines are longer, than it fits on the screen.
I’s expect a keyboard shortcut to scroll to the right to see the hidden (turncated) things.
(I don’t know, this is just a shot in the dark)

3 Likes

Hi László, :wave:

thanks a lot for your reply.

That makes sense. I presume you´re right.

It´s still funny though that Debian is the only system (which I use) that doesn´t provide the arrows.

Well, it seems to be the expected behaviour on most systems, I guess.

Thanks again and many greetings from Rosika :slightly_smiling_face:

3 Likes

Try to run an electron app, such as Caprine on Debian. That will start couple of processes of which command lines are few kilometers long. I bet that will introduce those arrows on Debian too :slight_smile:
(I don’t have this procs so far, so I can’t try it at the moment)

2 Likes

There are several things different in the Debian output

  • the spacing of columns is different… compare the headings
  • the long kworker lines fit because of the more compressesd spacing
  • the arrows are not needed . as Laszlo noted
    So, what is your tab size in Debian?
    I bet it is smaller than in the other distros, so that empty TTY
    column ends up 4 spaces instead of 8.
3 Likes

I just installed on Pop!_OS using a snap. I don’t see any > symbol on the lines even when I resize the window to be smaller than the output.

Maybe it’s a matter of the font used. My font is ‘fira mono’.

4 Likes

Hi all, :wave:

thank you very much for your replies. :heart:

@kovacslt :

I see. Well, that´s good to know.

If you ever feel like trying procs yourself it´s very easy to do so. No need for installing it the regular way.
I didn´t “install” it either.
Just download the zip file file from the github page (https://github.com/dalance/procs/releases/download/v0.14.5/procs-v0.14.5-x86_64-linux.zip).
After unpacking it you get the procs executable. In my case it looks like this:

ll procs
-rwxr-xr-x 1 rosika rosika 8,5M Mär  7 01:37 procs

You can run it from the respective directory.

Thanks again for your comments.

@nevj :

O.K., I wouldn´t have noticed it, I have to admit.

I don´t know. I even don´t know how to find that out, Neville.
Thanks for your info.

@pdecker :

Thanks for the suggestion. I might try altering the font.

Many greetings to all.
Rosika :slightly_smiling_face:

3 Likes

Hi Rosika,
See man tabs
a tab character (as generated by the TAB key) moves the
terminal line to the position of the next ‘tab stop’
Did you ever use a typewriter or a teletype? The terminal line
behaves just like a teletype line.
The proc output is in a terminal, so it follows the rules of behaviour for terminal lines.
It seems that proc is using the tab (\t) character to space output in columns.
I think you will find Debian has its tab stops set at every 4th column, whereas the other distros have the default of 8.
That is why the Debian output is different.

I do believe fonts can affect tab spacing. … because some fonts are fixed spacing, others are variable .
But your output looks like all fixed spaced fonts, so I dont think this is relevant

Regards
Neville

2 Likes

Hi again, Neville, :wave:

I didn´t even know there were man pages for tabs. :blush:
Thanks for letting me know.

Yes, I did.

Ah, that would be the explanation then. I´ll look into it.

Thank you very much, Neville.

Many greetings from Rosika :slightly_smiling_face:

2 Likes

Hi Rosika,
You can check by typing the TAB key… watch how it spaces
Do you remember the physical tab stops on your typewriter?
That is what the terminal line is emulating.
Sorry, it is an arcane subject.
Regards
Neville

2 Likes

You mean in the terminal, right:

Using bash typing the TAB key does nothing. It never even moves the cursor. :thinking:

Cheers from Rosika :slightly_smiling_face:

So bash does not consult the tab stops when echoing input
Hmm… we need a better test… maybe do it in an editor
Maybe set a variable with tabs in it, and echo it to the terminal.
Let me test a few things. I know I can do it in C but there must be an easier way.

2 Likes

Thanks so much, Neville.
No need to hurry at all. As procs works as it should, it´s only a matter of pure interest.

Cheers from Rosika :slightly_smiling_face:

1 Like

Hi @Rosika ,
make a file with vi

ab      cd      ef
gh      ij      kl

where the spaces are tabs

Check with od -a

$ od -a junk
0000000   a   b  ht   c   d  ht   e   f  nl   g   h  ht   i   j  ht   k
0000020   l  nl
0000022

It is OK, those ‘ht’ characters are ‘horizontal tab’

Cat it to a terminal

nevj@devuan5:~$ cat junk
ab      cd	    ef
gh      ij      kl
nevj@devuan5:~$ tabs -8
nevj@devuan5:~$ cat junk                                                       
ab      cd      ef
gh      ij      kl
nevj@devuan5:~$ tabs -4
nevj@devuan5:~$ cat junk                                                       
ab	cd	ef
gh	ij	kl

OK there are 3 cat’s there

  • first uses default devuan tabs setting, which seems to be 8
  • second sets it to 8 explicitely, and gets same result
  • third sets it to 4 and gets a more compact set of columns
    So there you have a technique.
    You could try various tabs settings, and run proc under each. That should explain it.

Note: I had trouble copy/pasting exactly what was on my screen… had to edit it
so it is ‘faked’ but correct. Copy/paste has its own idea about tabs and so does discourse. Should have used an image.

Regards
Neville

1 Like

https://www.linusakesson.net/programming/tty/index.php

A fabulous account of TTY issues.
After reading this you may even decide that it is a good idea
to let your distro set it up for you.

2 Likes

Hi Neville,
I did a very basic test and it may not be the most correct way to count how many characters a tab has:

echo 0$'\t'1$'\t'2$'\t'3$'\n'0...4...8...12..16..20..24

Result (I’ve edited the result to be correct in the post):

0	    1	    2	    3
0...4...8...12..16..20..24

The first line prints the numbers 0 to 3 with a tab between each number and the second line I use as a ruler to count the number of characters in each tab.

In my case, the tab size is 8.

I did the following test successfully, so that the tab value would be permanent, for example with 4 characters:

  • I added tabs -4 to the .bashrc file.

Note: how to reload .bashrc without logging out:

source ~/.bashrc

More info about the tabs command

Jorge

2 Likes

Notice the first character of a field aligns with the tab stop
That is the way a typewriter works, when you hit the tab key
it moves to the tab stop, so the next character keyed will land there. When a character is keyed it advances one column, so to overwrite you have to use backspace.

It is strange how this typewriter emulation has survived in
computer systems. There must be something basically efficient about it.

2 Likes

Hi Rosika,
I was testing the procs in the Linux Mint (gnome terminal) and I also have the arrows on the right side:
image

I have the same opinion as other users and, based on the tests I carried out, in the Command column, I have several commands where the length of the text exceeds the length of the window.

In your Linux Lite procs, try to scroll vertically to find a command that has more characters than the length of the window, for example, the command with PID 8 is not fully displayed. Now, press the right arrow to scroll horizontally. If it is not that command that is causing the arrows to appear, scroll vertically again until you find another long command and do the same test again.
When you find the largest command you have displayed in the procs and scroll horizontally to see it in full, the arrows on the right disappear

you can use -S option to fold long lines. The arrows on the right side disappear, but if you have commands that are longer than the length of the window, the spaces between the lines will be the same on all lines and will be necessary for the longest command to be able to appear completely in the window, for example, If the command, with the option, now occupies 8 vertical lines, you will have a vertical spacing of 8 lines between each process.

In my example:

  • I wrote the -S option
    image

  • When I pressed S key, the following information appeared:
    image

  • And after pressing Enter, procs stopped showing the arrows on the right side, but increased the vertical spacing between processes:
    image

In my example, the largest command I have has PID 2771 and with the -S option it occupies 9 vertical lines, making there a separation of 9 vertical lines between all processes.

Try looking for the process that is causing the arrows to appear on the right side of the window :wink:

To return to normal viewing, type the -S option again.

Your Linux Lite and Debian have different themes/windows.
Could this be why the arrows appear on one and not the other?
Sincerely, I do not know.

I found a small error in the procs, which I also see in your terminals, which is the following: the vertical scroll bar is at its maximum height, but the page is not fully displayed, that is, the bar should decrease depending on the content , but this function is not yet implemented.

BTW you can also create/change procs configuration

Jorge

2 Likes

Hi all, :wave:

sorry that I couldn´t reply earlier. I wasn´t online yestreday as it was mmy day out. :blush:

@nevj :

Thanks so much. Following the instructions provided by you I did the experiment and arrived at the same results.
I have to admit I had to read up on vi first as I hadn´t used it before. I´m more of a nano person. But it was good to learn something new. :wink:

I did that. The difference was pretty minimal in my output:

  • with tabs -8:

  • with tabs -4:

So the spacing between TTY and CPU varied to a small extent. Interesting.

Thanks also for the link. I haven´t had the time yet to read it through but I´ll do so as soon as I can.

@Tech_JA :

Thanks for doing the experiments, Jorge. :heart:
That´s very interesting.

And thanks for the link as well.

Thank you for verifying it.

Yes, you´re right. I get it now. That´s the explanation for the “>” character at the end of the lines.

Great. Yes, I could verify it. :+1:

Thanks for the info, Jorge.
Typing “-S” and “Enter” did the trick. I must admit I didn´t know that.

You may be right, Jorge.
Although I run both distros as virtual machines using the i3-tiling-window manager. So there shouldn´t be any differences when running procs, because there are not themes involved.
Never mind.

Well, I guess we´ll have to live with it. The main thing is procs works as desired.

Thanks for the configuration link.

I did the following:

  • mkdir ~/.config/procs
  • touch ~/.config/procs/config.toml

and then put the recommended contents from here in it.
Now the output is much more informative, as can be seen in the two screenshots (see above).

Thanks a lot for your help.

Many greetings from Rosika to all of you. :slightly_smiling_face:

2 Likes

Assuming you are using a terminal emulator, simply close the terminal emulator’s window, then open a new one. The terminal emulator reads ~/.bashrc every time you start an instance.

Ernie

2 Likes