/
en-eix.1.in
4253 lines (3666 loc) · 188 KB
/
en-eix.1.in
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
.TH "eix" "1" "" "@PACKAGE_STRING@" ""
.\" {{{ NAME
.SH "NAME"
.B eix
- a set of utilities for searching, diffing and updating a binary cache of your local portage-trees
.\" }}}
.\" {{{ SYNOPSIS
.SH "SYNOPSIS"
.B eix
[I<common options>] [I<OPTIONS>] I<EXPRESSION>
.B eix-update
[I<common options>] [I<eix-update options>]
.B eix-diff
[I<common options>] [I<OLD-CACHE>] [I<NEW-CACHE>]
.B eix-sync
.B eix-postsync
.B eix-test-obsolete
.B eix-remote
.B eix-layman
.B eix-installed-after
.B eix-installed
.B eix-etcat
.B eix-functions.sh
.B eix-header
.B eix-drop-permissions
[B<-->] [I<command to execute>]
.B masked-packages
[I<options>] I<category>B</>I<name>B<->I<version>[B<:>I<slot>][B<::>I<repo>] ...
.B versionsort
[B<-n>|B<-p>|B<-f>|B<-v>|B<-r>|B<-V>] [I<(rubbish)>I<package->]I<version> ...
.\" }}}
.\" {{{ DESCRIPTION
.SH "DESCRIPTION"
B<eix-update> generates a binary cache from your local portage-tree and overlays.
B<eix> searches this cache for packages that match the restricting criteria you specify in I<EXPRESSION>;
if you specify no such restriction, all packages are output, of course.
B<eix-diff> compares two binary caches and finds packages that were added, removed or for
which the highest stable versions has changed.
All of these programs and scripts read the configuration files described later.
B<eix-sync> has optionally an additional separate configuration file.
B<eix-sync> can sync the portage/overlay trees and compare them with the old cache
using B<eix-diff>.
To get more help on B<eix-sync> call B<eix-sync -h> and see the documentation
of I<@SYSCONFDIR@/eix-sync.conf> below.
Note that the content of the latter can also be stored in the variable
B<EIX_SYNC_CONF>.
B<eix-postsync> is a simple alternative to B<eix-sync>.
It is similar to B<eix-update>, but backups the cache before so that
B<eix-diff> can be used to show the differences to the previous syncing.
To execute B<eix-postsync> automatically after B<emerge --sync>
with >=portage-2.3.7, you can create the directory /etc/portage/postsync.d/
and symlink B<eix-postsync> there.
The main disadvantage of using B<emerge --sync> with that symlink (compared
to B<eix-sync>) is that in the exceptional situation when a new upgrade
of eix should no longer support the current database format then
B<eix-diff> will not work for the first syncing after the upgrade
(unless you manually called B<eix-update> before syncing).
B<eix-test-obsolete> is a script which calls B<eix> several times to display
the output of B<eix -tTc> in a more organized manner.
B<eix-remote> can sync an eix database from an external server and
add/remove it to the current database. This can be used to create a
local database of packages in all registered repositories/overlays,
not just those in overlays installed locally.
By default it uses a separate cachefile.
With this default you should regularly call B<eix-remote add1> and/or B<eix-remote add2> after B<eix-update>
so that the separate cachefile is synchronized with your main database.
(If you use B<eix-sync> this is done by default.)
If you use the same cachefile you can save remote-data over B<eix-update> calls
by setting B<KEEP_VIRTUALS=true> in I<@SYSCONFDIR@/eixrc>.
By default, this script drops its permissions using B<eix-drop-permissions>.
To get more help on B<eix-remote> call B<eix-remote -h>.
B<eix-installed-after> is a simple script (with many comments) demonstrating some
possibilities how a custom eix output format can be used.
It outputs packages installed after (or before) the last (or first) emerge of a specific package/version.
To get more help on this script call B<eix-installed-after -h>.
B<eix-layman> can add or remove local layman overlays to the eix database.
You might want to use this if you want to avoid adding layman overlays to
the regular portage repositories.
To get more help on B<eix-layman> call B<eix-layman -h>.
B<eix-layman> is also meant as an example script how to use B<eix-functions.sh>:
B<eix-functions.sh> outputs helper functions used by B<eix-sync>, B<eix-remote>, and B<eix-layman>.
You might want to use them for your own similar scripts.
You can either "eval" the output of this program.
Note that after this, you should usually call B<ReadFunctions> for
initialisation.
B<eix-header> is a helper program for B<eix-remote> (and possibly your own scripts).
It can check database file headers and can find/output overlay paths or labels stored in these files.
For details how to use it, call B<eix-header -h>.
B<eix-drop-permissions> is a helper program for B<eix-remote> (and possibly your own scripts).
It executes the command given as argument with permissions dropped according to
B<EIX_USER>, B<EIX_GROUP>, B<EIX_UID>, B<EIX_GID> (see later).
Note that also the binaries B<eix>, B<eix-diff>, and B<eix-update> drop their
permissions according to these variables as soon as possible, i.e., you might
have to adjust these variables if you use B<eix> (in particular B<eix-update>)
in a nonstandard setting.
B<eix-installed> is a simple script which outputs all installed packages
(in their exact version) and can check for packages installed with/without
repository or buildtime information
(cf. the description of B<CHECK_INSTALLED_OVERLAYS> and B<USE_BUILD_TIME>).
To get more help on B<eix-installed> call B<eix-installed -h>.
B<eix-etcat> is a wrapper script which calls eix with a configuration such
that it resembles the behaviour of B<etcat -v> from old app-portage/gentoolkit
versions or its updated version from https://github.com/proteusx/etcat/ (e.g.
app-portage/etcat from the mv overlay).
The output is analogousand the default input accepts a sequence of
(exact) package names (the specification of the category is optional).
It might be instructive to look at the simple wrapper script if you want to
write your own input/output format: The output format can be seen by calling
B<eix --print FORMAT_ETCAT> and B<eix --print FORMAT_VERSION_ETCAT>.
B<masked-packages> is a helper tool which matches the arguments against a list of masks.
Details can be found near the end of the manpage.
B<versionsort> is a helper tool for scripts which cuts the version strings from its arguments
and outputs them sorted according to the portage rules of version sorting.
Details can be found near the end of the manpage.
.\" }}}
.\" {{{ OPTIMIZATION, MEMORY, SECURITY
.SH "OPTIMIZATION, MEMORY, SECURITY"
If you installed eix from the gentoo repository, then very likely
the eix ebuild B<will not> have installed eix with the B<CXXFLAGS>
and B<LDFLAGS> which are recommended for optimization and security of eix by
the eix maintainer.
Also, eix can be configured to use less memory if required.
See the section B<INSTALLATION> for how to install eix in the way the
maintainer recommends.
.\" }}}
.\" {{{ EXAMPLES
.SH "EXAMPLES"
The following examples are some useful but perhaps unusual applications of eix.
They are listed here to give you an idea what unexpected things you can do with eix.
Since the examples are meant to be copied from this manpage they are listed early.
To understand how they work, you should read the full manpage, of course.
For more examples see e.g. the script B<eix-installed-after> which contains many comments.
.TP
.IB cmd " | eix '-|*' --format '<markedversions:NAMESLOT>'"
Assuming I<cmd> creates a list of the form B<category/name-version> or B<=category/name-version>,
the above prints the corresponding list B<category/name> or B<category/name:SLOT>
(depending on whether B<SLOT>s need to be distinguished).
.TP
.IB cmd " | eix '-|*' --format '<markedversions:NAMEASLOT>'"
Similar to the above, but print always B<category/name:SLOT> even if B<SLOT>
may be redundant. (Mnemonic: B<A>lways).
.TP
.B eix '-I*' --format '<installedversions:NAMEVERSION>'
Print out installed packages, using the format B<category/name-version>.
Of course, you could replace B<NAMEVERSION> also by B<NAMESLOT> or B<NAMEASLOT> to get another format.
The only purpose of the B<I> option in this context is to speed up the output slightly.
.TP
.B eix '-I*' --format '<installedversions:EQNAMEVERSION>'
Similarly to the above but in the format B<=category/name-version> which you
can pipe directly to portage.
.TP
.B eix '-I*' --format '<installedversions:DATESORT>' | sort -n | cut -f2-3
Print out installed packages (with slots if necessary), sorted by installation date.
If you want the output in another format, you have to modify B<DATESORT> correspondingly
(you can see the original definition in the output of B<eix --dump>).
This sorting trick works as follows: The B<DATESORT> variable outputs as
the first column the seconds since epoch (B<eix --print DATESORT> will show you
that this happens by the variable B<DATESORT_DATE> whose first entry is B<%s>),
and B<sort> thus gets the correct order by sorting alphabetically.
Finally the B<cut> command gets rid of this first column which was only needed for sorting.
.LP
In the above examples, things like B<NAMEVERSION> and B<DATESORT> are actually
just names of variables which are predefined in eix (with B<eix --dump> you see them).
You can as well define your own variables and use them.
To understand how this works, please read the manpage, especially the description of the B<FORMAT> string.
.\" }}}
.\" {{{ OPTIONS
.SH "OPTIONS"
.\" {{{ -------- Common options
.SS Common options
These options are common to B<eix>, B<eix-diff>, and B<eix-update>.
.TP
.BR -h ", " --help
Print a help screen and exit.
.TP
.BR -Q ", " --quick " (toggle) (not for B<eix-update>)"
Do (not) read the slots of installed versions which cannot be guessed
(i.e. installed versions of packages with at least two different slots
for which the installed version is not in the database anymore).
Note that with this option, eix and eix-diff might report false positives
for up-/downgrade recommendations for these packages.
.TP
.BR --care " (not for B<eix-update>)"
This deactivates B<--quick>, and moreover, slots of installed version are
always read instead of relying on the guess of the slot.
This will in particular make sure that you get an up-/downgrade
recommendation if a slot name of an installed version changes.
Note that this will dramatically decrease the speed at the first call.
(If your filesystem has a reasonable cache, later calls are almost not
slower than without this option.)
.TP
.BR --deps-installed " (not for B<eix-update>)"
This is the same as B<DEPS_INSTALLED=true>.
Dependencies of installed version are always read, even if they are known
from an available version.
Note that this will dramatically decrease the speed at the first call.
(If your filesystem has a reasonable cache, later calls are almost not
slower than without this option.)
.TP
.BR -q ", " --quiet " (toggle)"
Produce no output on stdout.
For eix you can decrease execution time by combining this
(depending on your needs) with either B<--brief> or B<--brief2>
and by setting B<COUNT_ONLY_PRINTED=false>.
See also B<NOFOUND_STATUS> and B<MOREFOUND_STATUS>
.TP
.B --dump
Show the current eixrc-variables, and their defaults as comments; then exit.
.TP
.B --dump-defaults
Show the defaults of the eixrc-variables, and their current values as comments; then exit.
.TP
.BI "--print " VAR
Print the specified variable I<VAR> of eixrc or of portage settings,
completely expanded as it would be used internally by eix; then exit.
The exit status is nonzero if I<VAR> is not known to eix (see B<--known-vars>)
This is mainly intended for usage in scripts or for debugging purposes.
If you use it in scripts you might want to specify B<PRINT_APPEND> to
get trailing spaces (see description of B<PRINT_APPEND>).
Two special I<VAR> values which can be accessed only in this way are
B<USE.profile> and B<USE.make_conf> which contain the USE string of the profile
or make.conf before the concatenation, respectively.
.TP
.B --known-vars
Print an alphabetical list of variables known to eix with B<--print>.
After each variable name a newline is output.
.TP
.BR -V ", " --version
Print version and exit.
.TP
.BR -n ", " --nocolor
Disables the use of ANSI color codes. This is useful for terminals that do not support ANSI colors.
(This is automatically turned on if stdout is no tty, but can be overridden by using --force-color)
.TP
.BR -F ", " --force-color
The opposite of --nocolor.
.\" }}}
.\" {{{ -------- eix exclusive
.SS Special information options
The following special information options are only provided by the B<eix> binary.
They are one-shot exclusive options, i.e. eix outputs only the required data and then exits.
.TP
.BR --color " " (always / never / auto)
Override all other color options and variables: Colorize always, never, or only if the output goes to some terminal
.TP
.BR --ansi " (also for eix-diff)"
Define the 256 color palette suggested by Todd Larason (the author of the 256 color support for xterm).
Use this if something some tool has redefined the default palette.
.TP
.BR "--256" ", " "--256d" ", " "--256d0" ", " "--256d1" ", " "--256l" ", " "--256l0" ", " "--256l1" ", " "256b"
Print the 256 color palettes (assuming it follows ansi color scheme) and exit.
With B<--256d>/B<--256l> (B<--256d0>/B<--256l0>, B<--256d1>/B<--256l1>) only the foreground palettes with dark/light background
(or only the normal or bright dark/light foreground palette, respectively) is printed.
With B<--256b> only the background palette is printed.
.TP
.B --print-all-eapis
print all EAPIs used in some version.
.TP
.B --print-all-useflags
print all IUSE or REQUIRED_USE words used in some version.
.TP
.B --print-all-keywords
print all KEYWORDS used in some version.
.TP
.B --print-all-slots
print all SLOT strings used in some version.
.TP
.B --print-all-licenses
print all LICENSE strings used in some package.
.TP
.B --print-all-depends
print all words occurring in some B<{,R,P,B}DEPEND>.
This only works if B<DEP=true> is active (and was so when the cachefile was created).
.TP
.B --print-world-sets
print the world sets.
.TP
.B --print-profile-paths
Outputs all paths of the current profile.
To each Path B<PRINT_APPEND> is appended.
If B<PRINT_APPEND> is empty, the null character is appended.
.\" }}}
.\" {{{ -------- Output options
.SS Output options
.TP
.BR --nowarn " (toggle)"
Suppress some warnings concerning the portage configuration.
.TP
.BR -x ", " --versionsort " (toggle)"
Prints available versions sorted by versions (slots).
If sorted by slots, each new slot starts in a new line.
This mode can be combined with B<--versionlines> (B<-l>)
to start a new line even for every version.
.TP
.BR -l ", " --versionlines " (toggle)"
Prints available versions in a (vertical) list.
Only in this mode some additional information for each version is output.
More precisely, depending on whether you have chosen B<--verbose> and
depending on the state of the configuration variables
B<VERSION_{IUSE,KEYWORDS,DEPS}_{NORMAL,VERBOSE}>,
this can be the B<KEYWORDS>, B<IUSE>, B<DEPEND>, B<RDEPEND>, B<PDEPEND>, B<BDEPEND>, B<IDEPEND> data.
Note that if B<IUSE> is not printed per version then it is only collected
for the whole package which can give the wrong impression, since often
B<IUSE> changes dramatically with versions.
.TP
.BR -c ", " --compact
Causes eix to use a compact layout for search results. Useful for obtaining a better
overview in the case of a long list of results, and also to help speed up searching over
slow connections such as a serial console.
.TP
.BR -v ", " --verbose
Use a verbose layout with additional information about search results such as the license
of a package.
.TP
.BR -N ", " --normal
Use the normal layout which is the default if B<DEFAULT_FORMAT> was not explicitly changed.
.TP
.BR --xml ", " --proto, " (toggle)"
Output in XML or protobuf format.
For usage from an external program you will probably want to combine this
with B<--care>.
For B<--xml>, you probably additionally want to export B<LOCAL_PORTAGE_CONFIG>
to make sure that the preferred user output setting do not influence your output.
The B<--proto> format is independent of this variables: local and system settings are separate.
If some of these options is active, B<OVERLAYS_LIST=none> and B<--pure-packages> are
automatically active so that your output is not clobbered with normal eix output.
The XML output format can be slightly influenced by the B<XML_*> variables.
The XML format used is documented in human-readable form in the files eix-xml.html or eix-xml.txt
and in less human-readable form (namely as an xml-schema) in the file eix-xml.xsd.
The protobuf format is in the file eix.proto.
.TP
.BR -* ", " --pure-packages " (toggle)"
(do not forget quoting if you use the short form from within a shell.)
Omit printing of additional information (overlay names, number of found packages) after the packages.
This might be useful for some shell scripts parsing the output
.TP
.BR -# ", " --only-names " (toggle)"
As B<--pure-packages>, but additionally print only the category and name of the packages found.
.TP
.BR -0 ", " --brief " (toggle)"
Print at most one package then stop.
This option is typically faster when used with B<COUNT_ONLY_PRINTED=false>.
In the latter case, when you use fuzzy search, not necessarily the best match is output.
.TP
.BR --brief2 " (toggle)"
As B<--brief>, but print up to two packages.
.\" }}}
.\" {{{ -------- Options for eix
.SS Special options for B<eix>
.TP
.BR -t ", " --test-non-matching
Before other output, print entries of /etc/portage/package.* which do not
match any existing version in the package database or which apparently have
no meaning because they are empty (see B<TEST_FOR_EMPTY>).
This option also lists all installed packages whose name is not in the database.
Note that this is essentially different from B<-T> (see below).
The latter only tests for packages B<in the database> whether redundant
entries in /etc/portage/package.* exist or whether the installed versions
are available, respectively.
This option is best combined with B<-T> to clean up /etc/portage/package.*
Or you can combine it with B<-e> to have no other output.
If you have a reason to exclude certain entries/packages from this test,
you can write those entries into a file /etc/portage/package.*.nonexistent
where B<*> is one of B<accept_keywords> (or the obsolete B<keywords>),
B<mask>, B<unmask>, B<use>, B<env>, B<license>, B<accept_restrict>, B<cflags>,
and B<installed>.
These files (and how to modify their filenames) are described later.
.TP
.BR -R ", " --remote
Uses the value of B<EIX_REMOTE1> as cache file name.
Use this option if you want to see packages in the cache created
and synchronized by B<eix-remote>.
You can make this option the default by setting B<REMOTE_DEFAULT=1>.
.TP
.BR -Z ", " --remote2
Uses the value of B<EIX_REMOTE2> as cache file name.
Use this option if you want to see packages in the cache created
and synchronized by B<eix-remote>.
You can make this option the default by setting B<REMOTE_DEFAULT=2>.
.TP
.BI "--cache-file " FILE
Use I<FILE> instead of B<@EIX_CACHEFILE@>.
.\" {{{ -------- Options for EXPRESSION
.SS Options for EXPRESSION
EXPRESSION is used to narrow which packages eix prints.
An EXPRESSION can contain Boolean operators and tests according to the following grammar:
EXPRESSION ::= [ B<--not> | B<-!> ] BRACE_OR_TEST |
EXPRESSION [ B<--and>| B<-a> ] EXPRESSION |
EXPRESSION [ B<--or> | B<-o> ] EXPRESSION
BRACE_OR_TEST ::= B<--open>|B<-(> EXPRESSION B<--close>|B<-)> |
TEST_WITH_OPTIONS
TEST_WITH_OPTIONS ::= [TEST_OPTIONS] [PATTERN]
Do not forget that B<!>, B<(>, B<)> have to be quoted in shells so that
eix actually receives these as parts of arguments!
If you want that an EXPRESSION starts with B<->, precede it with two further B<--> symbols:
This way, the EXPRESSION is not read as an option, and two additional B<--> symbols are ignored.
For example, B<eix ---tool --or ---util> will output the packages containing B<-tool> or B<-util>.
The meaning of the logical operators should be obvious with perhaps some exceptions:
1. If neither B<--and>|B<-a> nor B<--or>|B<-o> is between two EXPRESSIONs, then one of
them is implicitly assumed; whether this is B<-a> or B<-o> depends on the setting
of the configuration variable B<DEFAULT_IS_OR>.
2. The operators B<-a> and B<-o> have equal precedence and are left-associative.
In particular, B<X -o Y -a Z> fails if B<Z> fails.
3. B<--not>|B<-!> negates only the result of the subsequent BRACE_OR_TEST.
4. If PATTERN is omitted, it defaults to the empty PATTERN.
For instance, with the default settings, B<eix> without arguments will match
all packages, since the empty string is contained in every name.
On the other hand, B<eix -e> should (usually) output nothing,
because no package name should I<exactly be> the empty string.
5. Note that the syntax implies that PATTERN always ends an expression.
TEST_OPTIONS after PATTERN always start a new expression
(i.e. an implicit B<--and> or B<--or> is inserted, depending on B<DEFAULT_IS_OR>).
In particular B<eix -e foo> has a different meaning than B<eix foo -e>.
The latter means the same as B<eix foo --and -e> or B<eix foo --or -e>,
depending on B<DEFAULT_IS_OR>.
6. Observe that TEST_OPTIONS can consist of several options.
All of these options are applied simultaneously, i.e. in a sense these options
are logically braced and combined with B<and> (independently of B<DEFAULT_IS_OR>).
This is somehow ambiguous, since PATTERN can be omitted.
This ambiguity is resolved by interpreting successive TEST_OPTIONS always as a
part of one TEST_WITH_OPTIONS.
For instance, in B<eix -I -O -e foo> all options are considered as part of a common I<EXPRESSION>
(not as four I<EXPRESSION>s as would be the case for B<eix -I '' -O '' -e '' foo>).
On the other hand, in B<eix -I --not -e> the B<--not> will cause the subsequent TEST_OPTION B<-e> to be considered as part of a new I<EXPRESSION>.
Options other than TEST_OPTIONS or a logical option (like B<-!>, B<-(>, B<-)>, B<-a>, B<-o>) are ignored in this respect.
For instance, B<eix -I -c -e> generates only one I<EXPRESSION>, since B<-c> is neither a TEST_OPTION nor a logical option
and therefore plays no role for the interpretation of I<EXPRESSION>.
7. The TEST_OPTIONS can specify things like the B<match algorithm> and also B<operation selection>.
All these specifications refer B<only> to the current TEST_WITH_OPTIONS, in particular, they are only active for the next B<PATTERN>.
Note that besides using this expression syntax a different way of implicit
(though slow) package selection on various other criteria is possible by
defining B<FORMATSTRING> (see below) using conditionals such that it outputs
an empty string for the undesired packages.
Here are the admissible TEST_OPTIONS:
.TP
.BR -I ", " --installed
Only match installed packages.
Please do not use this as a replacement for B<eix-installed -a>
(or B<qlist -ICv> or B<equery>), it is not the same:
Packages that are installed, but no longer in the portage tree (or an overlay) are not listed here.
However, you should better not have such packages at all
(better put these packages in overlays in case you need to reinstall them).
To find such packages, you can use B<eix -te> (or B<eix -tI> to get listed both)
but be aware that eix -t does not obey the usual B<FORMAT> rules for these packages.
So you better do not use this in scripts unless you know what you are doing.
If you really want to use this option as a substitute for equery in scripts,
you might want to combine it with some of
.B --format --only-names
.B --format '<installedversions:NAMEVERSION>' --pure-packages
.B --format '<installedversions:EQNAMEVERSION>' --pure-packages
.B --format '<installedversions:NAMESLOT>' --pure-packages
.B --format '<installedversions:NAMEASLOT>' --pure-packages
.B --format '<installedversions:DATESORT>' --pure-packages
.TP
.BR -i ", " --multi-installed
Only match packages which are installed in at least two different versions.
Usually, this means that these versions are slotted (at installation time).
.TP
.BR -d ", " --dup-packages
Only match duplicated packages,
for example, if sys-foo/bar exists both in the official portage tree and a local overlay.
If B<DUP_PACKAGES_ONLY_OVERLAYS> is set (see below), the instances must be in two different local overlays.
.TP
.BR -D ", " --dup-versions
Only match packages with duplicated versions,
for example, if sys-foo/bar-0.2.1 exists both in the official portage tree and a local overlay.
If B<DUP_VERSIONS_ONLY_OVERLAYS> is set (see below), both instances must be in overlays.
.TP
.BR -1 ", " --slotted
Only match packages with a nontrivial slot, i.e. where SLOT is nonempty and different from "0".
.TP
.BR -2 ", " --slots
Only match packages with at least two different slots.
In contrast to -1, a package is not shown here, if only one slot is available with e.g. slot-name "4.3".
.TP
.BR -u ", " --upgrade ", " --upgrade+ ", " --upgrade-
Only match packages which have at least one slotted version installed which
is not the best version within that slot.
This means usually that you should either upgrade or downgrade that package.
However, the test takes also B<UPGRADE_TO_HIGHEST_SLOT> (see below) into account.
If you use B<--upgrade+> or B<--upgrade->, then the test acts as if B<LOCAL_PORTAGE_CONFIG> is B<true> or B<false>.
Otherwise, this decision is based upon B<UPGRADE_LOCAL_MODE>.
If you want to see only packages with downgrade recommendations, you might make
use of the B<FORMATSTRING> features described below.
.TP
.BR --stable ", " --testing ", " --non-masked ", " --system ", " --profile
Only match packages which have at least one version which is stable (and non-masked),
testing or stable (and non-masked), non-masked, or in system or profile, respectively.
If several of these options are combined in one test, it is the same version
which must satisfy all.
.TP
.BR --stable+ ", " --testing+ ", " --non-masked+ ", " --system+ ", " --profile+
This is as the above ones just that the test acts as if B<LOCAL_PORTAGE_CONFIG=true>.
.TP
.BR --stable- ", " --testing- ", " --non-masked- ", " --system- ", " --profile-
This is as the above ones just that the test acts as if B<LOCAL_PORTAGE_CONFIG=false>.
.TP
.BR --installed-unstable ", " --installed-testing ", " --installed-masked
Only match packages which have
at least one non-stable, testing, or masked version installed
(the test acts as if B<LOCAL_PORTAGE_CONFIG=false>).
If several of these options are combined in one test, it is the same version
which must satisfy all.
.TP
.BR --world
Only match @world packages.
This is analogous to "emerge @world", i.e. it includes not only packages in
the world file but also in world sets and the @system set.
If you do not want to have all included, choose the appropriate alternative
option.
.TP
.BR --world-file
This only matches packages from the world file or from the @system set.
.TP
.BR --world-set
This only matches packages from world_set or from the @system set.
.TP
.BR --selected
Only match @selected packages.
This is analogous to "emerge @selected", i.e. it includes not only packages in
the world file but also in world_sets (if you have @system contained in the
world_sets file, then the behaviour is of course identical to B<--world>).
If you do not want to have both included, choose the appropriate alternative option.
.TP
.BR --selected-file
This only matches packages from the world file.
.TP
.BR --selected-set
This only matches packages from world_set.
.TP
.BR --binary
Only match packages with a binary file (*.tbz2, *.gpkg.tar, or *.xpak) in PKGDIR.
The version of the binary file must either match the version of an available version or of an installed version.
(However, note that if no version is available, the package cannot be found either).
Just the existence of the corresponding *.tbz2, *.gpkg.tar, or *.xpak file is checked:
Whether portage can actually use the file depends also on metadata within that file (like USE settings) which is not considered by eix.
.TP
.BI --multi-binary NR
Only match packages with a version with at least I<NR> files matching B<--binary>.
.TP
.B --nonvirtual
Only match packages with at least one version from the main tree or a non-virtual overlay.
.TP
.B --virtual
Only match packages with at least one version in a virtual overlay.
.TP
.BR -O ", " --overlay
Only match packages with at least one version in an overlay.
.TP
.BI "--in-overlay " overlay
Only match packages with at least one version in an overlay matching I<overlay>.
If this option is repeated, the additional I<overlay> arguments are joined
to the list of admissible overlays.
I<overlay> may be either a wildcard pattern or a number.
Note that if you use the default B<OVERLAYS_LIST=all-used-renumbered>
you do not see the correct overlay numbers; to get a list of the correct
overlay numbers you can e.g. call
B<OVERLAYS_LIST=all eix --not>
or in scripts better
B<OVERLAYS_LIST=all PRINT_COUNT_ALWAYS=never eix -!>
The special values B<0> or B<$PORTDIR> match the "main" tree (which in
this connection is considered as the 0'th overlay).
If I<overlay> is empty (or omitted if B<--in-overlay> is the last option)
it matches all overlays except for the "main" tree
(i.e. B<--in-overlay ''> is the same as B<-O>).
.TP
.BI "--only-in-overlay " overlay
Only match packages which have only versions in an overlay matching I<overlay>.
If this option is repeated, the additional I<overlay> arguments are joined
to the list of admissible overlays.
I<overlay> may be either a wildcard pattern or a number, as in B<--in-overlay>.
In particular, B<--only-in-overlay ''> matches all packages which are not in
the official portage tree but only in some overlay.
.TP
.BR -J ", " --installed-overlay
Only match packages which have been installed from some overlay.
To get a completely reliable result you should set
B<CHECK_INSTALLED_OVERLAYS> to true (which is not the default because
it dramatically slows down the test).
See B<CHECK_INSTALLED_OVERLAYS> for details.
.TP
.BI "--installed-from-overlay " overlay
This is analogous to B<--in-overlay> with the difference that only
packages are matched which have at least one version installed
from I<overlay>.
For instance, B<--installed-from-overlay 0> will only match those packages
which have at least one version which was installed from the regular
portage tree.
As for -J, you should set B<CHECK_INSTALLED_OVERLAYS> to true to get a
completely reliable result.
.TP
.B --installed-in-some-overlay
Only match packages with at least one installed version number which is
also in some overlay.
.TP
.BI "--installed-in-overlay " overlay
This is analogous to B<--in-overlay> with the difference that only
packages are matched which have at least one installed version in I<overlay>.
For instance, B<--installed-in-overlay 0> will only match those packages
which have at least one version which is also in the regular portage tree.
.TP
.B --restrict-fetch
Only match packages which have at least one version with RESTRICT=fetch.
If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
.TP
.B --restrict-mirror
Only match packages which have at least one version with RESTRICT=mirror.
If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
.TP
.B --restrict-primaryuri
Only match packages which have at least one version with RESTRICT=primaryuri.
If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
.TP
.B --restrict-binchecks
Only match packages which have at least one version with RESTRICT=binchecks.
If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
.TP
.B --restrict-strip
Only match packages which have at least one version with RESTRICT=strip.
If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
.TP
.B --restrict-test
Only match packages which have at least one version with RESTRICT=test.
If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
.TP
.B --restrict-userpriv
Only match packages which have at least one version with RESTRICT=userpriv.
If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
.TP
.B --restrict-installsources
Only match packages which have at least one version with RESTRICT=installsources.
If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
.TP
.B --restrict-bindist
Only match packages which have at least one version with RESTRICT=bindist.
If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
.TP
.B --restrict-parallel
Only match packages which have at least one version with RESTRICT=parallel.
If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
.TP
.B --properties-interactive
Only match packages which have at least one version with PROPERTIES=interactive.
If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
.TP
.B --properties-live
Only match packages which have at least one version with PROPERTIES=live.
If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
.TP
.B --properties-virtual
Only match packages which have at least one version with PROPERTIES=virtual.
If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
.TP
.B --properties-set
Only match packages which have at least one version with PROPERTIES=set.
If used with other PROPERTIES/RESTRICT tests, the version must satisfy all simultaneously.
.TP
.BR -T ", " --test-obsolete
Only match obsolete packages.
Packages are obsolete if they have redundant entries in /etc/portage/package.*
(if B<TEST_FOR_REDUNDANCY> is true) or if not all installed versions exist
(if B<TEST_FOR_NONEXISTENT> is true).
What is considered as redundant is defined by the B<REDUNDANT_IF>-variables below,
and what is considered as non-existent is defined by the B<NONEXISTENT_IF>-variables.
Note that the test for versions from obsolete overlays works only reliable if
you set B<CHECK_INSTALLED_OVERLAYS> to true (which is not the default because
it dramatically slows down the test).
See B<CHECK_INSTALLED_OVERLAYS> for details.
Note that this options only tests packages in the database - in particular, you
will not find entries for e.g. renamed or removed (from the portage tree) packages with this option.
Use B<-t> to find the latter.
Therefore, this option is best combined with -t to find also other types of obsolete entries.
If you have a reason to exclude certain packages from this test,
you can write those entries into a file (or directory) /etc/portage/package.nowarn
This file (and how to specify alternative/additional files) is described later.
.TP
.BR -| ", " --pipe
(Recall that a shell will not pass an unquoted B<|> sign, so quote properly).
Only match packages/masks from standard input; usually you will want to use this in a pipe,
redirected e.g. from emerge -pv (similar to genlop -p).
Actually, any (space or newline separated) words are considered which contain a / symbol.
Each such word is considered as a mask (in the form of the first entry in /etc/portage/package.* files),
and due to a heuristics package versions can also specified without an explicit leading B<=> symbol.
(This can lead to ambiguities; use B<--pipe-mask> if you need a reliable result.)
All available packages/versions which match a mask from the input will in the output be considered as marked.
For details on the latter, see the B<marked> and B<markedversions:*> formatstrings.
Even if B<--pipe> occurs more than once, the standard input is of course only read once,
but interpreted repeatedly for each occurrence (i.e. if the first --pipe matches, all others will also match).
If you want to use the standard input only for marking but not for selection, you can
choose an expression like
B<eix something -a "-(" --pipe -o "-)">
If the option B<--pipe-name> or B<--pipe-version> occurs after this option in the argument list,
B<--pipe> acts as if it were B<--pipe-name> or B<--pipe-version>, respectively.
.TP
.B --pipe-mask
This is analogous to B<--pipe> with the difference that only masks are allowed in the input,
i.e. if package versions are specified the leading B<=> is non-optional.
This avoids ambiguities in the input if a part of the name looks like a version number.
You should use this option instead of B<--pipe> if you want a reliable result!
.\" }}}
.\" {{{ -------- Match field selection
.SS Match field selection
The subsequent options define the fields that the pattern should be tested on.
Multiple fields may be specified in one expression (the expression matches
if the pattern matches at least one of the specified fields).
If you do not specify some of these options, the default is chosen according
to some heuristic depending on the form of your pattern.
In most cases, the default match field will be B<--name>, but if your pattern
looks "special" like e.g. "cat/n" or "@set", the default match field will change to
B<--category-name>, B<--set>, B<--description>, B<--homepage>, or B<--license>.
Details of the heuristic are specified by the B<DEFAULT_MATCH_FIELD>
configuration variable explained later.
Depending on the configuration of that variable, it might even be non-optional
to specify some of the following options for every query.
.TP
.BR -y ", " --any
Any match field is searched. This is the same as specifying simultaneously
all of B<--name>, B<--description>, B<--category>, ...
Thus, you may want to use this if you want to be sure to not miss any matches.
However, be warned that the output list will often be much longer than you might expect.
(If you are curious, you can find with options B<-vl> and piping to grep
the often unexpected reason why a match occurs with B<-y>.)
To exclude at least the dependency strings from matches, you might want to
combine this option with setting B<DEP=false>, e.g.
B<DEP=false eix --any SIP>
.TP
.BR -s ", " --name
e.g. "eix"
.TP
.BR -S ", " --description
e.g. "Small utility for searching .."
.TP
.BR -C ", " --category
e.g. "app-portage"
.TP
.BR -A ", " --category-name
e.g. "app-portage/eix"
.TP
.BR -H ", " --homepage
e.g. "@PACKAGE_URL@"
.TP
.BR -L ", " --license
e.g. "GPL-2"
.TP
.BR --available-deps ", " --available-depend ", " --available-rdepend ", " --available-pdepend ", " --available-bdepend ", " --available-idepend
This test can only be successful if B<DEP=true> is used
(and if B<DEP=true> was used when the cachefile was created).
It matches against B<DEPEND>, B<RDEPEND>, B<PDEPEND>, B<BDEPEND>, or B<IDEPEND>
(or with B<--available-deps> any of those) of any available version of the package.
B<--available-deps> is the same as specifying all of
B<--available-depend> B<--available-rdepend> B<--available-pdepend> B<--available-bdepend> B<--available-idepend>.
Note that it is matched against the string without any interpretation or
modification of the latter; only word separators become single spaces.
In particular, the string to match against can look like
app-admin/fam nls? ( sys-devel/gettext ) =dev-libs/apr-1* !!dev-db/libpq
Therefore, the match is not only against dependent packages but also against
blockers and/or conditionals and various ways of specifying versions.
.TP
.BR --installed-deps ", " --installed-depend ", " --installed-rdepend ", " --installed-pdepend ", " --installed-bdepend ", " --installed-idepend
This is similar to the corresponding option --available-* but with the difference
that the corresponding dependency string of any installed versions of the package is matched.
In contrast to --available-* this check does not involve the setting of B<DEP>.
You might probably want to combine these options with B<--deps-installed> to make sure that indeed
the content of the installed version is read.
Note that dependencies of installed versions are usually much simpler, e.g. not containing conditionals.
.TP
.BR --deps ", " --depend ", " --rdepend ", " --pdepend ", " --bdepend ", " --idepend
These are shortcuts for specifying the corresponding --available-* and --installed-* options simultaneously.
.TP
.BR --set
Name of a local package set of a version in the database
(i.e. corresponding to a file in B</etc/portage/sets>, B</etc/portage/sets.eix>,
or from another directory specified in B<EIX_LOCAL_SETS_ADD>;
see the comments to B<EIX_LOCAL_SETS>).
The "profile", "system" and "world" sets are intentionally excluded here, since these
should be tested with B<--profile[+-]>, B<--system[+-]>, B<--world>, B<--world-all>, or B<--world-sets>.
.TP
.B --src-uri
SRC_URI of a version in the database
.TP
.B --eapi
EAPI of a version in the database, e.g. "6"
.TP
.B --installed-eapi
EAPI of an installed version
.TP
.B --slot
Slotname of a version in the database, e.g. "kde-4"
.TP
.B --fullslot
Slotname of a version in the database, possibly with its subslot, e.g. "3/1.4"
.TP
.B --installed-slot
Slotname of an installed version.
Recall that without option B<--care> (or B<CAREMODE=true>) the slotname might be guessed.
.TP
.B --installed-fullslot
Slotname of an installed version, possibly with its subslot.
Recall that without option B<--care> (or B<CAREMODE=true>) the slotname might be guessed.
.TP
.BR -U ", " --use
A useflag defined by IUSE in some version by some of the ebuilds of the package.
You will usually want to combine this option with -e
.TP
.B --installed-with-use
A useflag enabled during installation of the package.
Of course, this flag can only match if the package is installed.
Note that the same restrictions hold as for B<-I>, i.e. only packages will be matched
which are still in the database.
.TP
.B --installed-without-use
A useflag disabled during installation of the package.
Of course, this flag can only match if the package is installed.
Note that the same restrictions hold as for B<-I>, i.e. only packages will be matched
which are still in the database.
.\" }}}
.\" {{{ -------- Match algorithm
.SS "Match algorithm"
The subsequent options define the algorithm by which the match field should be tested
against the expression.
Only one algorithm can be chosen for an expression.
If you do not specify some of these options, the default is chosen according
to some heuristic depending on the form of your search pattern and according
to the selected match field.
In most cases, the default will be B<--regex> (or B<--regex-case> if your
expression contains capital letters) unless your expression "looks" like a glob
pattern or a substring (in which case the corresponding algorithm will be the
default), or if the selected match field refers only to USE-flags, sets, EAPI,
or SLOT which perhaps most people would expect to match the whole string.
Details of the heuristic are specified by the B<DEFAULT_MATCH_ALGORITHM>
configuration variable explained later.
Depending on the configuration of that variable, it might even be non-optional
to specify some of the following options for every query.
.TP
.BR -e ", " --exact
Pattern is an exact (full) string. For example, "eix -e gcc" will only show packages
with the name "gcc".
.TP
.BR -b ", " --begin
Pattern is the beginning of the string. For example, "eix -b gcc" will show the package
with the name "gcc" but also e.g. "gcc-config".
.TP
.BR --end
Pattern is the end of the string.
.TP
.BR -z ", " --substring
Pattern occurs somewhere within the string.
.TP
.BR -f " [" I<N> "], " --fuzzy " [" I<N> "]"
Do a fuzzy search with a maximal levenshtein-distance of I<N> (default @LEVENSHTEIN_DISTANCE_DEFAULT@)
for the full string.
Note that this command slows down search speed.
.TP
.BR -p ", " --pattern
pattern is a wildcard-pattern (for the full string). See
.BR fnmatch (3)
and/or
.BR glob (7)
for further information. Be sure to use single quotes around patterns (to prevent the
shell from intercepting any wildcards).
.TP
.BR -r ", " --regex
pattern is a regexp, ignoring case.
Only a substring must be matched (unless ^ or $ are used);
the empty pattern matches everything.
For further information, please read
.BR regex (7).
Again, be sure to use single quotes around patterns.
.TP
.BR --regex-case
As B<--regex>, but does not ignore case.
.\" }}}
.\" {{{ -------- Defining layouts
.SS Defining layouts \fP(see B<FORMATSTRING> below)
.TP
.BR --format " " I<FORMATSTRING>
Defines the I<FORMATSTRING>.
Since eix-0.29.6, all other possibilities to modify the format string like
the setting of B<DEFAULT_FORMAT> or B<FORMAT> are overridden by this option.
In contrast, if this option is not used, whether the B<FORMAT>,