[SOLVED] find: Include "maxima"; exclude two folders

andrew.comly · 01-06-2016, 11:27 PM

I would like to find all files whose names contain "maxima". I don' want to look in the folder "/proc" nor the folder "/var".

After reading a thread on stack overflow (http://stackoverflow.com/questions/1...wo-directories) I use the command:

Code:

sudo find / -type f -iname "*maxima*" -o -type d ! -path "/proc/*" ! -path "/var/*"

Unfortunately it retrieves files that don't contain the word maxima.

I also tried:

Code:

sudo find / -type f -iname "*maxi*" -o -type d ! -path "/proc" ! -path "/var".

I keep having problems with find/grep, it seems they are quite harder to learn than other commands.

berndbausch · 01-07-2016, 07:16 PM

-type d includes all directories that are not under /proc and /var.
Since you use -o, the -type f and -iname parameters are not affected by the path parameters.
So, try again after removing -o and -type d.

Quote:

I keep having problems with find/grep, it seems they are quite harder to learn than other commands.

To me as well, find sometimes looks like an incoherent hodge-podge of arbitrary commands. grep on the other hand is based on regular expressions, which are not necessarily easy to read but rather well-defined and logical. Many other utilities use regular expressions, so it's worth your while studying this topic.

rknichols · 01-07-2016, 08:05 PM

It's pretty straightforward using "-prune":

Code:

find / \( -path /proc -o -path /var \) -prune -o -type f -iname "*maxi*" -print

andrew.comly · 01-09-2016, 07:24 AM

Quote:

Originally Posted by rknichols

It's pretty straightforward using "-prune":

Code:

find / \( -path /proc -o -path /var \) -prune -o -type f -iname "*maxi*" -print

Interesting equation(syntax) and even though I just learned the prune option for rsync recently, it just didn't occur to me that find would also have this option. Thanks a lot for sharing this.

Trying this equation out, I decided to add a third argument (excluding themes) to the prune section:

TRIAL 01

Code:

~$ find / \( -path /proc -o -path /var -o -path /usr/share/themes \) -prune -o -type f -iname "*maxi*" -print 
...
/media/a/Sea_ext4/recent/AC/Learn/Math/Software/wxMaxima_Calc1.pdf
/media/a/Sea_ext4/recent/AC/Learn/Math/Software/Maxima_Ch08NumericalIntegration.pdf
/media/a/Sea_ext4/recent/AC/Learn/Math/Software/wxMaxima_Calc2.pdf
...

This was quite successful. So impressive that I decided to add a fourth argument to "prune" away my Seagate ntfs HDD partition:

TRIAL 02

Code:

~$ find / \( -path /proc -o -path /var -o -path /usr/share/themes -o -path /media/a/Sea_ntfs \) -prune -o -type f -iname "*maxima" -print
find: `/lost+found': Permission denied
/usr/lib/maxima/5.32.1/binary-gcl/maxima
/usr/bin/wxmaxima
/usr/bin/maxima
/usr/share/menu/wxmaxima
/usr/share/doc-base/maxima
find: `/media/a/Sea_ext4/.Trash-0': Permission denied
find: `/etc/cups/ssl': Permission denied
find: `/etc/polkit-1/localauthority': Permission denied
find: `/etc/ssl/private': Permission denied
find: `/run/udisks2': Permission denied
find: `/run/lightdm': Permission denied
find: `/run/cups/certs': Permission denied
find: `/run/user/107': Permission denied
find: `/sys/fs/fuse/connections/8388625': Permission denied
find: `/sys/kernel/debug': Permission denied
find: `/root': Permission denied

Why on "trial 02" did I get a slew of "Permission denied" error messages, yet on "trial 01" literally for hundreds of results, the only error message I got was the expected:

Code:

`/lost+found': Permission denied

Can "find / $ 1 2 3 $ -prune" only handle 3 arguments at the most?

rknichols · 01-09-2016, 08:56 AM

The only limit is the 128 KiB system limit on the total length of args + environment. Your shell would let you know if you were exceeding that.

None of those "Permission denied" messages appear to be from anything you have excluded with "-prune". Are you sure you weren't getting those messages before and just having them scroll off the screen because of the volume of output? Try running one of the earlier find commands again with ">/dev/null" appended so that all you see is the stderr output.

andrew.comly · 01-19-2016, 03:55 AM

Quote:

Originally Posted by rknichols

Are you sure you weren't getting those messages before and just having them scroll off the screen because of the volume of output? Try running one of the earlier find commands again with ">/dev/null" appended so that all you see is the stderr output.

I must be doing something wrong with the >/dev/null on the back because the command

Code:

find / \( -path /proc -o -path /var -o -path /usr/share/themes \) -prune -o -type f -iname "*maxi*" -print

works great, but then when I append the ">/dev/null" on the end I get:

Code:

a@a-NC210-NC110:~/bin$ find / \( -path /proc -o -path /var -o -path /usr/share/themes \) -prune -o -type f -iname "*maxi*" -print>/dev/null
find: `/lost+found': Permission denied
find: `/media/a/Sea_ext4/.Trash-0': Permission denied
find: `/etc/cups/ssl': Permission denied
find: `/etc/polkit-1/localauthority': Permission denied
find: `/etc/ssl/private': Permission denied
find: `/run/udisks2': Permission denied
find: `/run/lightdm': Permission denied
find: `/run/cups/certs': Permission denied
find: `/run/user/107': Permission denied
find: `/tmp/tmpjcrdun69': Permission denied
find: `/sys/fs/fuse/connections/8388625': Permission denied
find: `/sys/kernel/debug': Permission denied
find: `/root': Permission denied

rknichols · 01-19-2016, 08:53 AM

That second case, with the redirection to /dev/null, is behaving as expected. I don't know why you are not seeing those same error messages otherwise. Are you perhaps running these commands in a script with stdout redirected to a file or perhaps being stored in a variable? Those messages are being sent to stderr and won't show up in the stdout stream.

andrew.comly · 01-20-2016, 01:49 AM

Quote:

Originally Posted by andrew.comly

Can "find / $ 1 2 3 $ -prune" only handle 3 arguments at the most?

Now I can do this with 6 arguments, but this is a bit strange since it seems that I did the same exact thing as before when it failed.

Code:

$ find / \( -path /proc -o -path /var -o -path /usr/share/themes -o -path /media/a/Sea_ext4 -o -path /media/a/Sea_ntfs -o -path /usr/share/doc \) -prune -o -type f -iname "*maxi*" -print
...{success}...

Notice above how I mentioned "/media/a/Sea..." twice (scroll above codebox right). This is because I have two hard drives whose labels start with "Sea_". When I try to abbreviate this with anything in "/media/a/Sea*", it produces the 'help' error message:

Code:

$ find / \( -path /proc -o -path /var -o -path /usr/share/themes -o -path /media/a/Sea_* -o -path /usr/share/doc \) -prune -o -type f -iname "*maxi*" -print
find: paths must precede expression: 		#error msg

I struggled with this for quite awhile. The solution is weak quotes:

Code:

$ find / \( -path /proc -o -path /var -o -path /usr/share/themes -o -path "/media/a/Sea_*" -o -path /usr/share/doc \) -prune -o -type f -iname "*maxi*">/home/a/bin/scrap.sh
...{success}...

Is there any reason why I have to use weak quotes above? Is it because the trailing underscore?

andrew.comly · 01-20-2016, 05:04 AM

Now let's talk about globbing.

Find can use globbing. In the above successful run of find we have already seen that the wildcard works in: -iname "*maxi*".

And complex multiple directory dir/{subdir1,sd2,...,sdN} brackets can work:

Code:

$ find /media/a/Sea_ext4/recent/AC/bckup/Install/3_UbuntuLXDE14.04/home/a/.config/cairo-dock/{current_theme,stack,themes,third-party}
...{success}...

However what happens when we put the wildcard in the path? Let's first try a simple find command of the {find PATH} syntax:

Code:

 
find /media/a/Sea_ext4/recent/AC/bckup/Install/3_UbuntuLXDE14.04/home/a/.config/cairo-dock/th*
...{success}...

And now let's try the syntax "find PATH $ -path PATH1* $ -prune" to prune away my .maxima and .sylpheed config(hidden) folders:

Code:

$ find /home/a \( -path /home/a/.ma* -o -path /home/a/.syl* \) -prune -o -type f
...{success}...

But what if I want to prune away both .maxima and .mozilla folders with "/home/a/.m*"?

Code:

$ find /home/a \( -path /home/a/.m* -o -path /home/a/.syl* \) -prune -o -type f
...{FAIL}...

To new users of find it seems that globbing doesn't work when you only have one letter followed by a wildcard. However if you use weak quotes it can! In this following example I prune away:
1) hidden directories starting with
i) "m"; ii) "c"; iii) "s": and
2) ffmpeg:

Code:

$ find /home/a \( -path "/home/a/.m*" -o -path "/home/a/.c*" -o -path "/home/a/.s*" -o -path /home/a/ff* \) -prune -o -type f

And it even works if you want to prune away all hidden files:

Code:

$ find /home/a \( -path "/home/a/.*" -o -path /home/a/ff* \) -prune -o -type f

Of course, since I am no expert, I still can not prune away both hidden directories and the files/subdirectories located within hidden directories:

Code:

$ find /home/a \( -path "/home/a/.*" -o -path /home/a/ff* \) -prune
/home/a/.thumbnails
/home/a/.local
...
/home/a/.maxima
/home/a/.dbus
/home/a/.xsession-errors.old

andrew.comly · 01-20-2016, 06:11 AM

Now I will focus on using multiple complex directories dir/{subdir1,sd2,...,sdN}:

Code:

$ find /media/a/Sea_ext4/recent/AC/bckup/Install/3_UbuntuLXDE14.04/home/a/.config/cairo-dock/{current_theme,stack,themes,third-party}
...{success}...

Next, I will limit the search to only files ending in "*.desktop".

Code:

$ find /media/a/Sea_ext4/recent/AC/bckup/Install/3_UbuntuLXDE14.04/home/a/.config/cairo-dock/{current_theme,stack,themes,third-party} -type f -iname "*.desktop"
...{success}...

Prune away the current_theme folder

Code:

$ find /media/a/Sea_ext4/recent/AC/bckup/Install/3_UbuntuLXDE14.04/home/a/.config/cairo-dock/{current_theme,stack,themes,third-party} \( -path /media/a/Sea_ext4/recent/AC/bckup/Install/3_UbuntuLXDE14.04/home/a/.config/cairo-dock/current_theme \) -prune -o -type f
...{SUCCESS}...

Finally I can also search for just the *.desktop files in all the subdirectories of /media/a/Sea_ext4/recent/AC/bckup/Install/3_UbuntuLXDE14.04/home/a/.config/cairo-dock/ that start with the two letters "th":

Code:

$ find /media/a/Sea_ext4/recent/AC/bckup/Install/3_UbuntuLXDE14.04/home/a/.config/cairo-dock/{current_theme,stack,themes,third-party} \( -path "/media/a/Sea_ext4/recent/AC/bckup/Install/3_UbuntuLXDE14.04/home/a/.config/cairo-dock/th*" \) -prune -o -type f -iname "*.desktop">~/bin/scrap.sh

I have learned the above new methods of using the find command. But there are so many others I can't do.

andrew.comly · 01-20-2016, 06:53 AM

Quote:

Originally Posted by andrew.comly

TRIAL 02

Code:

~$ find / \( -path /proc -o -path /var -o -path /usr/share/themes -o -path /media/a/Sea_ntfs \) -prune -o -type f -iname "*maxima" -print
{FAIL}

Why on "trial 02" did I get a slew of "Permission denied" error messages,

Because -iname "*maxima" should be written -iname "*maxima*.

andrew.comly · 01-20-2016, 06:59 AM

Quote:

Originally Posted by rknichols

Are you sure you weren't getting those messages before and just having them scroll off the screen because of the volume of output?

Pardon me. Your right, on a second check they were scrolled off the screen due to Volume of the output.

rknichols · 01-20-2016, 10:24 AM

When you are having problems with globbing, it's always helpful to set the shell's "-x" option so that you can see what arguments are actually being passed to the command. When you run

Code:

find / \( -path /var -o -path /media/a/Sea_* \) -prune

it's your shell that expands the /media/a/Sea_* into two arguments, so the command being executed is

Code:

find / '(' -path /var -o -path /media/a/Sea_ext4 /media/a/Sea_ntfs ')' -prune

That "/media/a/Sea_ntfs" isn't associated with any "-path" operator, so the find command takes it as a search path that should have come first, before the expression.

When you put quotes around that argument

Code:

find / \( -path /var -o -path "/media/a/Sea_*" \) -prune

the shell leaves that untouched, and the find command correctly sees a single argument containing a wildcard that it knows how to handle.

Code:

find / '(' -path /var -o -path '/media/a/Sea_*' ')' -prune

andrew.comly · 01-21-2016, 10:26 PM

Quote:

Originally Posted by rknichols

When you are having problems with globbing, it's always helpful to set the shell's "-x" option so that you can see what arguments are actually being passed to the command. When you run

Code:

find / \( -path /var -o -path /media/a/Sea_* \) -prune

it's your shell that expands the /media/a/Sea_* into two arguments

Thanks for your reminder about setting bash to "-x" to activate the debugging feature, I shouldn't have forgotten about this.

But this "bash shell that expands arguments" still raises another question. Why can the syntax of DIR/{subdir1,subdir2,...N} work in the below:

Code:

$ bash -x
$ mkdir -p 1 2/{A,B,C,D,E,F}
+ mkdir -p 1 2/A 2/B 2/C 2/D 2/E 2/F
{SUCCESS}

But when I use a variable to represent "A,B,C,D,E,F", e.g.

Code:

$ rm -rf 1 2
$ ALPHA=A,B,C,D,E,F
$ mkdir -p 1 2/{${ALPHA}}
+ mkdir -p 1 '2/{A,B,C,D,E,F}'
{FAIL}

At this point bash inserts strong quotes around the string containing the variable. This causes the command to fail.

Is there anyway to have bash understand 2/{${ALPHA}} not as

Code:

+ mkdir -p 1 '2/{A,B,C,D,E,F}'

but as

Code:

+ mkdir -p 1 2/A 2/B 2/C 2/D 2/E

??

ATTEMPT01

Code:

$ mkdir -p $(echo "1 2/{${ALPHA}}")
++ echo '1 2/{A,B,C,D,E,F}'
+ mkdir -p 1 '2/{A,B,C,D,E,F}'
{FAIL}

ATTEMPT02

Code:

$ `mkdir -p $(echo "1 2/{${ALPHA}}")`
+++ echo '1 2/{A,B,C,D,E,F}'
++ mkdir -p 1 '2/{A,B,C,D,E,F}'
{FAIL}

ATTEMPT03

Code:

$ mkdir -p "$(echo "1 2/{${ALPHA}}")"
{FAIL}

(Since this is another question, If you would prefer me to post under a separate question I will.)

rknichols · 01-22-2016, 08:23 AM

The relevant paragraph from the bash manpage is under EXPANSION:

The order of expansions is: brace expansion, tilde expansion, parameter, variable and arithmetic expansion and command substitution (done in a left-to-right fashion), word splitting, and pathname expansion.

Brace expansion is performed before variable expansion, so "{${ALPHA}}" isn't seen as a legitimate brace expansion (there's no comma inside those braces) and is left as-is. (The output from "-x" puts quotes around it since it contains characters that are special to the shell.)

You can force the expression to be re-parsed after variable expansion by using eval, but that is extremely dangerous unless you have absolute confidence that the string being passed to eval can't contain anything dangerous like content from an outside source, since that could include things like command substitution running arbitrary commands. If you are sure that the content of ALPHA is always safe, then

Code:

eval mkdir -p 1 {${ALPHA}}