pFind 6.3

Message

Argolance · #736 Post by **Argolance** » Mon 15 Oct 2018, 19:29

Bonsoir,

musher0 wrote:Which version of XenialPup-32 are you running?

Sorry, I should have given more details: xenialpup-7.5-uefi.iso, downloaded from official repository.
This happens running Puppy Precise too. I will test some other Puppies when I have the opportunity.

Cordialement

musher0 · #737 Post by **musher0** » Mon 15 Oct 2018, 22:02

Rebonjour, Argolance.

To check your find utility, please run in succession:

Code: Select all

cd /usr/bin
ldd find
ldd find | grep not
find --version

You should get this:

Code: Select all

[/usr/bin][/usr/bin]>ldd find
	linux-gate.so.1 =>  (0xb7730000)
	libselinux.so.1 => /lib/libselinux.so.1 (0xb76cb000)
	libm.so.6 => /lib/libm.so.6 (0xb7675000)
	libc.so.6 => /lib/libc.so.6 (0xb74bf000)
	libpcre.so.3 => /lib/libpcre.so.3 (0xb744a000)
	libdl.so.2 => /lib/libdl.so.2 (0xb7445000)
	/lib/ld-linux.so.2 (0x80011000)
	libpthread.so.0 => /lib/libpthread.so.0 (0xb7428000)

[/usr/bin]>ldd find | grep not

[/usr/bin]>find --version
find (GNU findutils) 4.7.0-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
(...)

As you can see, there are no libraries missing when I run

Code: Select all

ldd find | grep not

and that is how it should be.

In any case, I am attaching my find utility, for checking only. (Just in
case, make a back-up of the faulty find utility you have now?)

You could spend hours playing detective to pinpoint how this "lib64"
situation happened.

However, the best and most time-saving solution, IMO, given what you have
reported above, would be for you to recompile and install the GNU find
utilities from source, on and for your XenialPup-7.5-uefi.

I feel that it is the only way by which you will be absolutely sure that your
find utility is truly adapted to your version of XenialPup.

Of course, once recompiled, please re-run pfind to validate.

IHTH. / J'espère que cela t'aide.

Argolance · #738 Post by **Argolance** » Fri 19 Oct 2018, 09:40

Bonjour,
Thank you for replying (sorry I didn't answer sooner!).
So, I replaced the 4.4.2 Puppy Precise find version with yours (4.7.0) but I get the same error message and cannot jump to the place where is any selected found item.
Here are the results of the commands you gave above:

Code: Select all

root@puppypc28983 ~ 
# cd /usr/bin
root@puppypc28983 /usr/bin 
# ldd find
	linux-gate.so.1 =>  (0xb77a7000)
	librt.so.1 => /lib/librt.so.1 (0xb779b000)
	libm.so.6 => /lib/libm.so.6 (0xb7758000)
	libc.so.6 => /lib/libc.so.6 (0xb75a3000)
	libpthread.so.0 => /lib/libpthread.so.0 (0xb7588000)
	/lib/ld-linux.so.2 (0xb77a8000)
root@puppypc28983 /usr/bin 
# ldd find | grep not
root@puppypc28983 /usr/bin 
# find --version
find (GNU findutils) 4.4.2
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Eric B. Decker, James Youngman, and Kevin Dalley.
Built using GNU gnulib version e5573b1bad88bfabcda181b9e0125fb0c52b7d3b
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS() CBO(level=0)

Code: Select all

# cd /usr/bin
root@puppypc28983 /usr/bin 
# ldd find
	linux-gate.so.1 =>  (0xb7732000)
	libselinux.so.1 => /lib/libselinux.so.1 (0xb76d5000)
	libm.so.6 => /lib/libm.so.6 (0xb7692000)
	libc.so.6 => /lib/libc.so.6 (0xb74dd000)
	libdl.so.2 => /lib/libdl.so.2 (0xb74d8000)
	/lib/ld-linux.so.2 (0xb7733000)
root@puppypc28983 /usr/bin 
# ldd find | grep not
root@puppypc28983 /usr/bin 
# find --version
find (GNU findutils) 4.7.0-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Eric B. Decker, James Youngman, and Kevin Dalley.
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS(FTS_CWDFD) CBO(level=2)

[EDIT]: I uninstalled the pFind 6.3 version while keeping your 4.7.0 find version. It seems working fine. No error message. So, maybe the problem is still coming from pFind.

Cordialement.

Argolance · #739 Post by **Argolance** » Mon 03 Dec 2018, 11:43

Hello,
Is there anyone on the flight?
Doesn't my problem deserve to be taken into account?

Cheers.

don570 · #740 Post by **don570** » Sat 14 Dec 2019, 18:45

I was using pfind 6.3 in latest fatdog64 and to search a partition
I made a right click link.

So I right clicked on a mounted partition and launched pfind.
Search field was empty initially. I accidentally clicked on the 'Search' button
rather than the 'Advanced' button.

pfind appeared to work but it is very slow since it must show every file.

So I suggest if the search field is empty and a search of a partition is required,
that a warning be shown.

I wonder if James or Kirk of fatdog team have changed the pfind code
to make the field empty initially??
_____________________________________________________________________________________________________

zigbert · #741 Post by **zigbert** » Sun 15 Dec 2019, 16:43

@don570
fixed in Woof - https://github.com/puppylinux-woof-CE/w ... 3e7f13cf83

Thank you

don570 · #742 Post by **don570** » Sun 15 Dec 2019, 20:55

WOOF change...

Code: Select all

case "$1" in
-search)
	if [ ! "$SEARCHSTRING" ]; then
		FRAME=Info; IMG=dialog-info; TXT1="$(gettext '<b>No searchstring.</b> Please define the textstring you want to search for.')";
		. $PROGPATH/box_ok
		exit
	fi

____________________________________________

I noticed in an old version of pfind 4.2 in fluppy linux
that when I relaunched pfind the previous search text is in the field.
This is useful in some situations.

__________________________________________________

don570 · #743 Post by **don570** » Mon 16 Dec 2019, 20:40

Slightly different wording is possible.

'searchstring' doesn't appear to be an English word???
'search-string' is in dictionary but not used often.

...and 'text string' is apparently spelt as two separate words.
___________________________________________

zigbert · #744 Post by **zigbert** » Wed 18 Dec 2019, 15:53

@don570

English is far from my better skills, so please correct more of my spellings.
It would be preferable if you just pulled the changes to WoofCE

Thank you
Sigmund

MochiMoppel · #745 Post by **MochiMoppel** » Mon 17 Feb 2020, 12:50

I find the explanation for text search confusing. Shouldn't it be the other way round?
"Regular expressions work only when searching for text in file (not when searching for filenames)"

Text in file is found using grep, and grep patterns are regex by default
For filenames I had no success using regex. Bash filename expansion works though. Is that what you mean?

The screenshot finds perl sripts in /usr/bin, using a regular expression.

BTW: What does "Search Apps" do?

zigbert · #746 Post by **zigbert** » Fri 21 Feb 2020, 09:16

Hi MochiMoppel
The explanation could sure be misleading...
- Searching for files accept the operator AND and OR and the regex ? and * according to the help text in the startup window. The last used find-command is shown in the statusline at the bottom.
- Searching for text is just a plain grep -i inside single quotes (' '), and will of course support what grep supports. But this will not work as with the find-command.
- Searching for apps is searching in /usr/share/applications and executes the app by doubleclick.

So, what would be the best explanation?

MochiMoppel · #747 Post by **MochiMoppel** » Sat 22 Feb 2020, 02:59

zigbert wrote:- Searching for files accept the operator AND and OR and the regex ? and * according to the help text in the startup window.

And this is wrong.
? and * are commonly called "wildcards". Neither the operators nor the wildcards are regex. Filename search does not support regex and IMO it would be better not to use "R E G U L A R E X P R E S S I O N S" at all.

- Searching for text is just a plain grep -i inside single quotes (' '), and will of course support what grep supports. But this will not work as with the find-command.

I know. The dilemma is that the search pattern should work for text search and filename search alike. You could easily make find behave exactly like grep, allowing regex for both, or you could make grep behave like find, allowing wildcards for both, but I don't know if you want to go that far.

- Searching for apps is searching in /usr/share/applications and executes the app by doubleclick.

Doubleclick does not work for me. Nothing happens.

So, what would be the best explanation?

Honestly, I don't know. Should be answered by a native speaker, certainly not by me. As a proposal for the help text my first thought was: "You can use following operators and wildcards". Avoids the ambiguous "exact search" (search for *.mp3 is not what I understand as "exact"). But then this would be true only for filename searches. Maybe 2 paragraphs is better:

Code: Select all

A R G U M E N T S
To define an exact search you may use following arguments:
...

W I L D C A R D S
When searching for filenames (not text in files!) you may use following wildcards:
...

Hmm...something like this?

don570 · #748 Post by **don570** » Sun 24 May 2020, 18:41

I discovered a quick way to open up htm files on a drive..

to open htm files quickly

File > Configure > Commands
TextEditor --> seamonkey /tmp/searchresult/*

Now search with '.htm' in search box
and use Action menu

OR alternative way...

Open file /usr/local/pfind/box_input with texteditor
and insert...
DEFAULT=seamonkey after #!/bin/bash

don570 · #749 Post by **don570** » Wed 10 Jun 2020, 19:32

followup from previous post....

This works better....

I put the following at the beginning of pfind's box_input file
and this will allow other commands to work (example copy)

Code: Select all


len=${#DEFAULT}
[ $len -eq 0 ] && DEFAULT=seamonkey

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

pFind 6.3