How can I use logical operators when searching for packages in Aptitude? - apt-get

1) How to search for packages matching "word1 or word2" with aptitude?
2) How to search for packages matching "word1 and word2" with aptitude?

This wasn't clear to me from the documentation initially either. In my case, I wanted to search for packages that matched a name and were installed.
Anyway, the key is that each argument is a space separated list of conditions that are AND'd, and each argument is OR'd. So:
$ aptitude search "foo bar"
Will search for all packages that contain the string foo and the string bar
Where as:
$ aptitude search foo bar
Will search for all packages which contain either foo or bar
You can then combine this with other conditions that aptitude accepts to do things like:
$ aptitude search "~i python"
Will list all installed packages that contain the string python in their name
There are also other ways of doing this. For example:
$ aptitude search "?and(foo, bar)"
$ aptitude search "?or(foo, bar)"

Take a look at the aptitude search pattern quick reference.
pattern1 | pattern2: Select packages that match pattern1, pattern2, or both.
pattern1 pattern2: Select any package that matches both pattern1 and pattern2.
Since that's a pipe, make sure it's escaped or in a string if you're running aptitude from a shell; it has a special meaning for shells.

Related

Junit Console Launcher .. support for tag expressions

My junit-console-launcher command vaguely resembles,
java -jar ./junit-platform-console-standalone.jar -cp . -c pkg.Class1 -c pkg1.Class2 -t A --details=verbose
I do this because I need to send in my classes in a certain order. I needed help in using tag expressions which is documented here,
https://junit.org/junit5/docs/current/user-guide/#running-tests-tag-expressions
-t 'A & B' does not seems to be recognized by junit console launcher. I need to select tests which are tagged both A and B. Is this supported? Any ideas?
Copied from https://junit.org/junit5/docs/current/user-guide/#running-tests-console-launcher
-t, --include-tag=TAG
Provide a tag or tag expression to include only tests whose tags match. When this option is repeated, all patterns will be combined using OR semantics.
This indicates, that "tag expression" are supported.
You just need to convince your OS/shell command to pass the A&B string as a single argument without the quotes.
Note: you also need to pass a class name filter pattern that matches your test classes, something like --include-classname .*Class? Or wait until 1.7.0-M2 is released: https://github.com/junit-team/junit5/issues/2259

drop_duplicates() got an unexpected keyword argument 'ignore_index'

In my machine, the code can run normally. But in my friend's machine, there is an error about drop_duplicates(). The error type is the same as the title.
Open your command prompt, type pip show pandas to check the current version of your pandas.
If it's lower than 1.0.0 as #paulperry says, then type pip install --upgrade pandas --user
(substitute user with your windows account name)
Type import pandas as pd; pd.__version__ and see what version of Pandas you are using and make sure it's >= 1.0 .
I was having the same problem as Wzh -- but am running pandas version 1.1.3. So, it was not a version problem.
Ilya Chernov's comment pointed me in the right direction. I needed to extract a list of unique names from a single column in a more complicated DataFrame so that I could use that list in a lookup table. This seems like something others might need to do, so I will expand a bit on Chernov's comment with this example, using the sample csv file "iris.csv" that isavailable on GitHub. The file lists sepal and petal length for a number of iris varieties. Here we extract the variety names.
df = pd.read_csv('iris.csv')
# drop duplicates BEFORE extracting the column
names = df.drop_duplicates('variety', inplace=False, ignore_index=True)
# THEN extract the column you want
names = names['variety']
print(names)
Here is the output:
0 Setosa
1 Versicolor
2 Virginica
Name: variety, dtype: object
The key idea here is to get rid of the duplicate variety names while the object is still a DataFrame (without changing the original file), and then extract the one column that is of interest.

Subsetting from file names

I have some files named:
Mycase_xxx_x_xxx.csv
Mycase_xxx_x_xxx_xx_x.csv
Myanalysis_x_xx_xx_xxx_x_x.csv
Myattempt_xx_x_xxxx.csv
I would like the files named in the following way:
xxx_x_xxx.csv
xxx_x_xxx_xx_x.csv
x_xx_xx_xxx_x_x.csv
xx_x_xxxx.csv
In other words I would like (by Unix) to preserve all characters that are present in filenames after the first word.
Can anyone help me please?
Thank you in advance
This can be achieved using Perl's rename utility, which depending on your system, may be called rename, prename or perl-rename. On Debian and Ubuntu, it can be installed as follows:
sudo apt install rename
Note that on some systems, the command rename may be Perl's rename, while on others it may be util-linux's rename and on others it may be GNU rename. These tools are not compatible with each other.
Perl's rename tool on Debian and Ubuntu can be used as follows:
prename 's/expression/substitution/' filenames...
Or to apply to all files in the current directory:
prename 's/expression/substitution/' *
A useful feature of Perl's rename is the ability to use regular expressions (note how the supported syntax is similar to sed's syntax).
In your case, a regular expression to match the prefix of your filenames up to and including the first underscore is as follows:
^[^_]*_
This can then be substituted with an empty string to remove this part of the filename, resulting in the following command:
prename 's/^[^_]*_//' *
Before running this command, if you are unsure and would like to test that the files will be renamed how you want them, you can add the flags -vn as follows:
prename -vn 's/^[^_]*_//' *
This will not rename any files and will instead print out a list of the files which will be renamed, like so:
$ prename -vn 's/^[^_]*_//' *
Myanalysis_x_xx_xx_xxx_x_x.csv -> x_xx_xx_xxx_x_x.csv
Myattempt_xx_x_xxxx.csv -> xx_x_xxxx.csv
Mycase_xxx_x_xxx.csv -> xxx_x_xxx.csv
Mycase_xxx_x_xxx_xx_x.csv -> xxx_x_xxx_xx_x.csv

.hgignore regex syntax to ignore a specific file (e.g. "core") anywhere

Suppose I have a working directory like this:
t.c
core
multicore
test1/core
I want to ignore all "core" files.
If I use "/core$" (4) will get ignored but not (2).
If I use "^core$" (2) will get ignored but not (4)
If I use "core$" (2) and (4) will get ignored but so will (3) which is not what I want.
How do you do this?
planetmaker's answer, "use glob syntax", is simpler and is what I would usually recommend. There is, however, a regexp answer, and a minor flaw in the glob syntax version.
Mercurial uses Python regular expressions, so we have the (alt1|alt2|...) syntax available. Note that these are grouped.1 We can and should use (?:...) to avoid grouping when required, but for .hgignore, the grouping is irrelevant, so it is simpler (and much more readable) to just use the parentheses, and I do so where possible below.
We could just write:
^core$
/core$
to ignore the file core with nothing coming before it (first pattern) and to ignore a file with a name like test1/core (second pattern). This is a fine, but we can compress it a bit more using the alternation syntax. The leading ^ works even in an alternate within a group, as long as it is still, in effect, leading, so:
(^|/)core$
means the same thing and accomplish the job using regexp syntax.
Annoyingly, all of these patterns ignore all files in any directory named core (whether or not we use regexp vs glob syntax):
$ rm core
$ mkdir core
$ touch core/keepme
$ cat .hgignore
syntax: glob
core
$ hg status -A
? .hgignore
? multicore
? t.c
I core/keepme
I test1/core
The problem is that as soon as we say ignore (some pattern that matches a directory named core), if there are files in that directory that are currently untracked, Mercurial ignores them too. You can forcibly add the file—as with Git, once a file is tracked, any ignore-file pattern that matches it becomes irrelevant—but this does not help with additional files we stick into the directory:
$ hg add core/keepme
$ touch core/keep-me-too
$ hg status -A
A core/keepme
? .hgignore
? multicore
? t.c
I core/keep-me-too
I test1/core
Here, regular expressions can prove to be the answer. Python (and Perl) regexps allow "negative lookbehind", i.e., you can say "as long as some pattern does not appear". Hence we can replace the existing .hgignore contents with:
$ cat .hgignore
(?<!^core/).*/core$
and now we have this status:
$ hg status -A
A core/keepme
? .hgignore
? core/keep-me-too
? multicore
? t.c
I test1/core
This particular regular expression depends on the wanted core directory being named core at the top level (^core). If we wanted to keep core directories named core (top level) and a/subsys/core, we would write:
(?<!(^core|^a/subsys/core)/).*/core$
as our regular expression.
Constructing these regexps is something of an art form, and rarely worth a lot of effort. Glob syntax is almost always simpler, and as long as it suffices, I prefer it. It was once significantly slower than regexp syntax but this was fixed back around Mercurial 3.1.
1Grouped, here, means that in Python code, we may use the .groups() method to obtain the parts of the string matched by these parts of the regular expressions. Non-grouped (?:...) expressions do not affect the way .groups() gathers the parts of the strings. As in the paragraph to which this is a footnote, this is more a concern when writing Python (or Perl, or whatever) code, not when using these patterns in .hgignore or other parts of Mercurial.
Try to give the filename using glob syntax:
syntax: glob
core
It gives:
~/hg-test$ hg st -A
M .hgignore
? multicore
I core
I dir1/core

Going n folders up with a terminal command?

cd .. goes one folder up.
Is there a (one-line) command to go n folders up?
You sure can define a function to do that:
$ go_up() { for i in $(seq $1); do cd ..; done }
$ go_up 3 # go 3 directories up
I am not aware of any command that does that, but it is easy to create one yourself. For example, just add
cdn() {
for ((i=0;i<${1-0};i++))
do
cd ..
done
}
in your ~/.bashrc file, and after you create a new shell you can just run
cdn N
and you will move up by N directories
All right, another really funny answer, that is really a one-liner, to go up 42 parent directories:
cd $(yes ../|head -42|tr -d \\n)
Same as gniourf_gniourf's other answer, it's cd - friendly (and it's just a couple characters longer than the shortest answer).
Replace 42 with your favorite number.
Now that you understood the amazing power of the wonderful command yes, you can join the dark side and use the evil command eval, and while we're at it we can use the terrible backticks:
eval `yes 'cd ..;'|head -42`
This is so far the shortest one-liner, but it's really bad: it uses eval, backticks and it's not cd - friendly. But hey, it works really well and it's funny!
you can use a singleline for loop:..
for i in {1..3}; do cd ../; done
replace the 3 with your n
for example:
m#mariachi:~/test/5/4/3/2/1$ pwd
/home/m/test/5/4/3/2/1
m#mariachi:~/test/5/4/3/2/1$ for i in {1..3}; do cd ../; done
m#mariachi:~/test/5/4$ pwd
/home/m/test/5/4
...however I don't think it will be much faster than typing cd and .. then hitting tab for each level you want to go up!! :)
How often do you go up more than five levels? If the answer is Not too often I suggest you place these cd - friendly aliases in your profile:
alias up2='cd ../..'
alias up3='cd ../../..'
alias up4='cd ../../../..'
alias up5='cd ../../../../..'
Advantages
No bashims, no zshisms, no kshisms.
Works with any shell supporting aliases
As readable and understandable as it gets.
A funny way:
cdupn() {
local a
[[ $1 =~ ^[[:digit:]]+$ ]] && printf -v a "%$1s" && cd "${a// /../}"
}
How does it work?
We first check that the argument is indeed a number (a chain of digits).
We populate the variable a with $1 spaces.
We perform the cd where each space in a has been replaced with ../.
Use as:
cdupn 42
to go up to forty-second parent directory.
The pro of this method is that you'll still be able to cd - to come back to previous directory, unlike the methods that use a loop.
Absolutely worth putting in your .bashrc. Or not.