Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[solved]EIX_LIMIT and EIX_LIMIT_COMPACT diferences?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
papu
Guru
Guru


Joined: 25 Jan 2008
Posts: 548
Location: Sota algun pi o alzina...

PostPosted: Tue Sep 12, 2017 9:06 pm    Post subject: [solved]EIX_LIMIT and EIX_LIMIT_COMPACT diferences? Reply with quote

i am using eix_limit=0 but don't know if there are diferences betwenn both , and if is a nonsense to activate both
reading man i don't understand well, my english is poor , and so my brain...

Code:
EIX_LIMIT, EIX_LIMIT_COMPACT (integer)
    As a safety measurement for typos there are never more packages displayed than specified here: There are two different variables, depending on whether --compact is active. There is no limit if the output is not sent to a terminal or if the value of the variable is 0. 

DEFAULT_FORMAT (normal/compact/verbose)
    Defines whether --compact or --verbose is on by default. Since this variable can be changed by the user in /etc/eixrc or ~/.eixrc, this might have undesired side effects for scripts setting FORMAT with the intention to get a fixed FORMATSTRING: Such scripts should better use the --format option (which ignores DEFAULT_FORMAT since eix-0.29.6), use the --normal option (available since eix-0.29.6), and/or export DEFAULT_FORMAT=normal to override such user settings.


https://paste.pound-python.org/show/shOvAJmKrmM5wOdHnyUV/
_________________
--Intel i5 6600 --GA-Z170-HD3P --Ripjaws V 2x8 2400 --Radeon RX 470 G1 4G --Gentoo & Windows


Last edited by papu on Wed Sep 13, 2017 8:05 pm; edited 4 times in total
Back to top
View user's profile Send private message
fcl
n00b
n00b


Joined: 31 Dec 2016
Posts: 67

PostPosted: Tue Sep 12, 2017 9:25 pm    Post subject: Reply with quote

As it says,
the EIX_LIMIT_COMPACT variable is for when using the eix -c (compact) flag. Try `eix -c --installed` for an example. It won't honor the EIX_LIMIT variable, so you must use EIX_LIMIT_COMPACT.
Back to top
View user's profile Send private message
papu
Guru
Guru


Joined: 25 Jan 2008
Posts: 548
Location: Sota algun pi o alzina...

PostPosted: Tue Sep 12, 2017 9:54 pm    Post subject: Reply with quote

fcl wrote:
As it says,
the EIX_LIMIT_COMPACT variable is for when using the eix -c (compact) flag. Try `eix -c --installed` for an example. It won't honor the EIX_LIMIT variable, so you must use EIX_LIMIT_COMPACT.


ah, fuck my cerebelus don't understand english well thanks :)
then i make both activate :)
_________________
--Intel i5 6600 --GA-Z170-HD3P --Ripjaws V 2x8 2400 --Radeon RX 470 G1 4G --Gentoo & Windows
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 5752

PostPosted: Wed Sep 13, 2017 7:46 am    Post subject: Reply with quote

Actually, I wonder why you want to set either of these variables: The truncation happens only if you send the output to a terminal.
So unless you use an unusually large terminal buffer in which you scroll back, I cannot see any value in modifying these variables.
Back to top
View user's profile Send private message
papu
Guru
Guru


Joined: 25 Jan 2008
Posts: 548
Location: Sota algun pi o alzina...

PostPosted: Wed Sep 13, 2017 1:36 pm    Post subject: Reply with quote

for me is useful EIX_LIMIT=0 , for example : i use eix synchronized with overlays to search
eix limit limitation is set to 50 and eix limit compact i think is 200.

then i configure to 0 and i forget about limitations, It is an option like any other...
_________________
--Intel i5 6600 --GA-Z170-HD3P --Ripjaws V 2x8 2400 --Radeon RX 470 G1 4G --Gentoo & Windows
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 16755

PostPosted: Wed Sep 13, 2017 4:24 pm    Post subject: Reply with quote

Excellent find papu. I just added these to 0 myself.

Using 'eix -s dev' as an exmaple with defaults:
Code:
Found 123 matches
Only 50 matches displayed on terminal
Set EIX_LIMIT=0 to show all matches


And using fcl's example of 'eix -cs --installed with the defaults:
Code:
Found 270 matches
Only 200 matches displayed on terminal
Set EIX_LIMIT_COMPACT=0 to show all matches


To me, these defaults seem strange.
_________________
Those who dream by day are cognizant of many things that escape those who dream only at night. --Poe
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 5752

PostPosted: Wed Sep 13, 2017 5:55 pm    Post subject: Reply with quote

paqu wrote:
for me is useful EIX_LIMIT=0 , for example : i use eix synchronized with overlays to search

pjp wrote:
To me, these defaults seem strange.

I still do not understand. Is it really useful for you to see hundreds of entries scroll by and be lost? Why? Do you use some special terminal with such a huge buffer of saved lines?
Note again: If you redirect e.g. into less (or more) the limits do not apply, because then the output is not to a terminal.

Or do you mean that it is strange that there are separate numbers for the compact/non-compact display? This is simply explained by the fact that in both cases only a few pages should be scrolled by...
Back to top
View user's profile Send private message
fcl
n00b
n00b


Joined: 31 Dec 2016
Posts: 67

PostPosted: Wed Sep 13, 2017 10:58 pm    Post subject: Reply with quote

Sure, you can redirect to less, or vim, or whatever but it won't have the same nice colors. It will be hard to read.
This is true at least on my system with less/vim.
I rather use `EIX_LIMIT=0 eix -I` for the easily readable, colored output than redirect to a text file and have a mumbojumbo of white.

Of course, if you're in a VT with a tiny buffer, redirection is probably optimal.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 11431

PostPosted: Thu Sep 14, 2017 12:59 am    Post subject: Reply with quote

Terminal multiplexers like GNU screen and tmux make long output easy to manage. For users who prefer routing it to less, eix option -F forces color sequences despite a non-terminal output. You still need to configure your pager to recognize the color escape sequences and handle them nicely. Otherwise you get the same mess that sometimes shows up on the forum when people post build logs with the color commands intermixed in the output. I usually redirect eix output to less when I need to see huge volumes, but I find tmux to be quite adequate when the output is more than one screenful and less than the EIX_LIMIT cap.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 16755

PostPosted: Thu Sep 14, 2017 1:06 am    Post subject: Reply with quote

fcl wrote:
Sure, you can redirect to less, or vim, or whatever but it won't have the same nice colors. It will be hard to read.
This is true at least on my system with less/vim.
I rather use `EIX_LIMIT=0 eix -I` for the easily readable, colored output than redirect to a text file and have a mumbojumbo of white.
eix has the -F option to force color, so it will be visible with less.

mv wrote:
I still do not understand. Is it really useful for you to see hundreds of entries scroll by and be lost? Why? Do you use some special terminal with such a huge buffer of saved lines?
I don't understand why anyone would want truncated results. Truncated results are erroneous results. I don't like apps trying to be "smart," because they almost never succeed. As per my previous comment, I had never noticed the behavior of eix truncating output. So that "smart" behavior had a negative impact.

On the other hand, I MIGHT choose to enable an option such as RESULTS_SUMMARY_ONLY_IF_TOO_MANY_RESULTS, where too many results won't fit on a single screen (of whatever size is currently in use). The summary would be something like "Query found 123 matches" or similar. But then I'd want a -v(erbose) override, which I'd probably just put in an alias.
_________________
Those who dream by day are cognizant of many things that escape those who dream only at night. --Poe
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 5752

PostPosted: Thu Sep 14, 2017 6:40 am    Post subject: Reply with quote

Thanks for the feedback; one never learns how people use things if one doesn't ask ;)

I know that screen and tmux have a larger scrollback buffer by default than e.g. xterm, but even that is rather small unless you configured it manually. Personally, I have configured all 3 buffers very large (about 20000 or 1000 lines, respectively), but I still consider it an annoyance if a typo in some tool's usage erases my whole history.
As usual, one cannot make things right for everybody (the introduction of the defaults was a reaction to bug reports who complained that eix displays all packages after "typical" typos which is an even worse annoyance if it happens when you are logged in over a slow network). I think that I will keep defaults the way they currently are: If you configure your terminal anyway, then you can correspondingly configure other tools like eix as well.
The idea with checking the size of the output before actually doing the output is nice but incompatible with the internal structure of eix (and it would be an enormous slow down for every query); simplicity and speed are also the reason why the limits are not based on the number of actual output lines but on the number of displayed packages: Work and speed loss are too large compared to the "problem" which should be solved with it...

Concerning the -F problem: I have FORCE_COLORS=true in /etc/eixrc/40-defaults and never did regret it: It reminds me to use my own format or specify -n in scripts. Of course, this can never become the default in eix, because it would break many historical user's scripts.
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 16755

PostPosted: Thu Sep 14, 2017 6:08 pm    Post subject: Reply with quote

mv wrote:
I know that screen and tmux have a larger scrollback buffer by default than e.g. xterm, but even that is rather small unless you configured it manually. Personally, I have configured all 3 buffers very large (about 20000 or 1000 lines, respectively), but I still consider it an annoyance if a typo in some tool's usage erases my whole history.
I never think of changing buffer size until I wish I had changed the buffer size :D. Also, if I know in advance I want output for something, I'll just enable session logging. I'll typically do that for documentation. In general, historical output isn't as valuable to me as historical commands used to get the output, which is why I don't often worry about the buffer size. Now that you mention it though, I think I'll set them to 5k.

mv wrote:
As usual, one cannot make things right for everybody (the introduction of the defaults was a reaction to bug reports who complained that eix displays all packages after "typical" typos which is an even worse annoyance if it happens when you are logged in over a slow network).
Absolutely. I just prefer a more "graceful failure." In this specific case of typos, I'm reminded of shells which "guess" what you might have meant to type. That would seem to have been a better solution, though I'm guessing more effort to implement.

mv wrote:
The idea with checking the size of the output before actually doing the output is nice but incompatible with the internal structure of eix (and it would be an enormous slow down for every query); simplicity and speed are also the reason why the limits are not based on the number of actual output lines but on the number of displayed packages: Work and speed loss are too large compared to the "problem" which should be solved with it...
That was just an example which came to me while typing. I was just demonstrating that I'm not ardently opposed to alternative solutions.

mv wrote:
Concerning the -F problem: I have FORCE_COLORS=true in /etc/eixrc/40-defaults and never did regret it: It reminds me to use my own format or specify -n in scripts. Of course, this can never become the default in eix, because it would break many historical user's scripts.
I generally find the defined colors to be a poor choice (dark blue in particular, though neon green is bad too). Maybe someone with color sense could make the selections? As a result, I usually turn color off. But I know a lot of tools work with color, so I checked to see if that could help fcl.
_________________
Those who dream by day are cognizant of many things that escape those who dream only at night. --Poe
Back to top
View user's profile Send private message
fcl
n00b
n00b


Joined: 31 Dec 2016
Posts: 67

PostPosted: Thu Sep 14, 2017 10:03 pm    Post subject: Reply with quote

@Hu @pjp
Thank you for the -F tip. eix has so many options that I had totally missed it (thinking back, it's an obvious feature). I set FORCE_COLORS=true for now. I don't have any custom eix scripts so it should be fine. :-)
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 5752

PostPosted: Fri Sep 15, 2017 12:59 pm    Post subject: Reply with quote

pjp wrote:
I generally find the defined colors to be a poor choice (dark blue in particular, though neon green is bad too).

The problem is that among the ~215 available colors, cf.
Code:
eix --256d0
it was already very hard to find about 80 which are simultaneously (optically) clearly distinguishable and readable on various terminals. (E.g. 59-63 cannot be distinguished, 16-21 and 52-57 are barely readable on black terminals etc). So it was in fact quite cumbersome to make 4 color schemes (one for white and black background, one for light and one for dark "solarized" scheme) which are
(a) optically immediately distinguishable
(b) readable
(c) logically consistent and compatbile with the 2 poor 16 color schemes (e.g. green tones for available versions, blue tones for installed versions etc)
(d) are sometimes logical extensions of each other (e.g. bold vs. non-bold) to avoid too many auxiliary variables.
If you want to add a 6th or 7th color scheme (which can easily replace some of the other color schemes by just modifying the corresponding COLORSCHEME[0-4] variable), feel free to submit patches (or preferrably a pull request) ;) (If you need assistance for how to do this technically, ask e.g. by pm).
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum