Does continuous cli feedback use up ram?

It's there as far back as we can scroll, but I just wonder the ram handicap. Typically I'll run a browser that keeps reporting error feedback but still runs.

E.g., Chromium:

root# /usr/bin/chromium-browser: line 133: lsb_release: command not found
/usr/bin/chromium-browser: line 134: lsb_release: command not found
[24176:24301:0514/215530.866525:ERROR:bus.cc(394)] Failed to connect to the bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
ATTENTION: default value of option force_s3tc_enable overridden by environment.

(chromium-browser:24176): LIBDBUSMENU-GLIB-WARNING **: Unable to get session bus: The connection is closed
[24176:24272:0514/215556.303620:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &)
[24176:24272:0514/215557.135423:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &)
[24176:24272:0514/215557.428281:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &)
[24176:24272:0514/215558.406005:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &)
[24176:24272:0514/215558.512466:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &)
[24176:24272:0514/215559.554561:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &)
[24176:24272:0514/215559.836829:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &)
[24176:24272:0514/215601.391427:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &)
[24176:24272:0514/215601.468456:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &)

Feedback like this will just scroll on and on if I don't exit terminal.

Some thoughts:

• If a clearly marked ERROR repeats like that you might want to look at the issue
• I have heard that excessive output to the terminal can be a bottleneck for e.g. shell scripts
• scrollback buffer can be limited in most terminal emulator apps
• it doesn't take up as much memory as you think. Consider each character is 2 bytes, a terminal is usually 80x24 chars, that's 3840 bytes. Even if you have a thousand times that, it's only 3.6MiB.

Originally Posted by JASlinux It's there as far back as we can scroll, but I just wonder the ram handicap. Typically I'll run a browser that keeps reporting error feedback but still runs. E.g., Chromium: root# /usr/bin/chromium-browser: line 133: lsb_release: command not found /usr/bin/chromium-browser: line 134: lsb_release: command not found [24176:24301:0514/215530.866525:ERROR:bus.cc(394)] Failed to connect to the bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. ATTENTION: default value of option force_s3tc_enable overridden by environment. (chromium-browser:24176): LIBDBUSMENU-GLIB-WARNING **: Unable to get session bus: The connection is closed [24176:24272:0514/215556.303620:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &) [24176:24272:0514/215557.135423:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &) [24176:24272:0514/215557.428281:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &) [24176:24272:0514/215558.406005:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &) [24176:24272:0514/215558.512466:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &) [24176:24272:0514/215559.554561:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &) [24176:24272:0514/215559.836829:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &) [24176:24272:0514/215601.391427:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &) [24176:24272:0514/215601.468456:ERROR:upload_data_presenter.cc(73)] Not implemented reached in virtual void extensions::RawDataPresenter::FeedNext(const net::UploadElementReader &) Feedback like this will just scroll on and on if I don't exit terminal.

PS: don't run a web browser as root.

You can also always run the command and use > ... 2> to redirect the STDOUT and STDERR streams respectively ... to a disk file.

[./mycommand >/tmp/mycommand_stdout 2>/tmp/mycommand_stderr

You will now receive no terminal output while the command runs. Everything will be in those two files.

In that case, the size of any "RAM buffer" becomes irrelevant, since it will no longer be used.

Lets answer that question.

I have xterm set to have 1000 lines scrollback buffer

free -b
               total        used        free      shared  buff/cache   available
Mem:      4009021440   709582848   286109696   287821824  3013328896  2716917760
Swap:              0           0           0

(Little old machine)

for i in {1..2000}; do echo -e ''$_{1..70}'\bX'; done

f

free -b
               total        used        free      shared  buff/cache   available
Mem:      4009021440   712101888   281260032   290152448  3015659520  2712068096
Swap:              0           0

2000 lines did not do much.

One more time:

free -b
               total        used        free      shared  buff/cache   available
Mem:      4009021440   709582848   286109696   287821824  3013328896  2716917760
Swap:              0           0           0

#2 hundred thousand lines.
for i in {1..200000}; do echo -e ''$_{1..70}'\bX'; done

free -b
               total        used        free      shared  buff/cache   available
Mem:      4009021440   758755328   181407744   343261184  3068858368  2612305920
Swap:              0           0           0

Let me get this straight. You're running a Chromium-based browser and you have no concerns about its memory usage, but you do have concerns about the memory usage of the terminal that it prints output to?

ondoho: I would be delighted to run browsers with no cli error feedback, but reality is most of them do.

I am also regularly stopped by Linux technical background assumptions. I am smart enough to code and grasp concepts, but I do not speak the language (am a couple-years-in Linux user as more of a Redmond defector).

I would be interested in scrollback buffer limiting. 3.6MB is a lot from my perspective.

sundialsvcs: I will try that to ramdisk. Thanks.

teckk: If that is valid mock cli feedback & diagnostic reporting, you made an argument. Roughly 50MB from 200k lines is significant.

dugan: No, and it is actual Chromium.

Originally Posted by JASlinux ondoho: I would be delighted to run browsers with no cli error feedback, but reality is most of them do.

Because (for some reason) you are starting a browser in a terminal window, instead of through the GUI/launcher, like most folks do. And you're running it as root, which remains a very bad idea.

I am also regularly stopped by Linux technical background assumptions. I am smart enough to code and grasp concepts, but I do not speak the language (am a couple-years-in Linux user as more of a Redmond defector).

Nothing to do with Linux, and you don't seem to grasp these concepts.

I would be interested in scrollback buffer limiting. 3.6MB is a lot from my perspective.

No, it isn't. How many GIGABYTES do you have on your system now??? I had 4MB of RAM on my 386 system from 35 years ago.

sundialsvcs: I will try that to ramdisk. Thanks.

..and you're complaining about 3.6MB of RAM...so you're going to use MORE RAM to redirect RAM output to it....which will somehow make things better???

teckk: If that is valid mock cli feedback & diagnostic reporting, you made an argument. Roughly 50MB from 200k lines is significant.

...and your scroll buffer will NEVER have that much in it, and if it does, it won't matter a bit to your system. 50MB is still tiny.

dugan: No, and it is actual Chromium.

...which they advise to NOT run as root.

You seem to ignore all the advice you're given, from everything about your system fans, to running things as root, memory usage, etc. Why bother asking anyone here if, no matter what you get told, you ignore it?? Is there a point?

Originally Posted by JASlinux 3.6MB is a lot from my perspective.

Then re-read what dugan wrote just prior, and re-think that statement.

I don't recommend sending a file to a "RAM disk." That just puts it back in memory – which defeats the purpose.

teckk: If that is valid mock cli feedback & diagnostic reporting, you made an argument. Roughly 50MB from 200k lines is significant.

You can copy/paste those into your own shell (which was the idea) and see what you get. Change the max scrollback lines in your terminal and see if RAM usage changes.

Example:
~/.Xdefaults

XTerm*saveLines: 1000

What @dugan said. I have my own web browser that is webengine based, which is from the chromium project.

Let me see, I have other stuff open too.

Clear unused RAM

sysctl vm.drop_caches=3

free -b
               total        used        free      shared  buff/cache   available
Mem:      4009021440   510701568  3148419072   177627136   349900800  3112849408
Swap:              0           0           0

Opened web browser to here...

free -b
               total        used        free      shared  buff/cache   available
Mem:      4009021440   666238976  2731220992   281391104   611561472  2834100224
Swap:              0           0           0

>>> 666238976 - 510701568
155537408

So, the web browser sucked up x times the RAM as the terminal with 200k lines of X's

Just a simple way of putting 2000 lines of X, 70 chars long in the term. Did you try it?

for i in {1..2000}; do echo -e ''$_{1..70}'\bX'; done

Now that you have all of these examples before you. You can test your own machine.

Actually you could watch it in real time

Open one terminal with

while :; do free -b; sleep 5; done

Open another terminal with a million lines

for i in {1..1000000}; do echo -e ''$_{1..70}'\bX'; done

Watch terminal one. Ctrl+C each terminal when you get bored.

There's a technical writeup here, about the data structures the Warp Terminal use to implement scrollback. That should answer all your questions about how scrollback uses memory.

The data structure behind terminals

The scrollback buffer will only use memory up to a certain amount, no matter how many lines have scrolled by. I'm sure you've noticed that most terminals let you specify a number of scrollback lines to make available, so that would be true for those as well.