Tiny Core Base > TCB Tips & Tricks

How to find which extension provides a file

<< < (2/14) > >>

Rich:
Hi polikuo

--- Quote from: polikuo on November 14, 2024, 02:56:08 AM --- ... While searching, you can add "\n" to the end of the query. ...
--- End quote ---
I was so focused figuring out how to include $ as an anchor that I
forgot to try \n. Thank you for pointing out the obvious and getting
me back on track.


--- Quote --- ... I believe it was meant to make sure the file is modifiable by any user to sync with the repo.
--- End quote ---
Makes sense. It just seemed like an odd place to put that line.

Looks like I spoke too soon. It seems using \n does not work if the item
you are searching for is in the last field of the record.

This is the record for squashfs-tools.tcz:

--- Code: ---squashfs-tools.tcz
/usr/local/bin/mksquashfs
/usr/local/bin/unsquashfs
--- End code ---

Searching for mksquashfs works:

--- Code: ---tc@E310:~/Scripting/Provides$ provides.sh "bin\/mksquashfs\n"
squashfs-tools.tcz
tc@E310:~/Scripting/Provides$
--- End code ---

Searching for unsquashfs (last field) fails:

--- Code: ---tc@E310:~/Scripting/Provides$ provides.sh "bin\/unsquashfs\n"
tc@E310:~/Scripting/Provides$
--- End code ---

polikuo:

--- Quote from: Rich on November 14, 2024, 11:28:21 AM ---It seems using \n does not work if the item
you are searching for is in the last field of the record.

--- End quote ---

Hi, Rich.
Interesting...
This is what I get on piCore64 15.0 (squashfs.tcz has extra files, so I'm using tar.tcz to demonstrate)


--- Code: ---tc@pi4:/etc/sysconfig/tcedir$ grep -A3 squashfs provides.db
squashfs-tools.tcz
usr/local/bin/mksquashfs
usr/local/bin/unsquashfs
usr/local/bin/sqfscat
usr/local/bin/sqfstar

tc@pi4:/etc/sysconfig/tcedir$ grep -A3 'tar.tcz' provides.db
tar.tcz
usr/local/lib/tar/rmt
usr/local/bin/tar

tc@pi4:/etc/sysconfig/tcedir$ prov 'bin\/tar\n'
tc@pi4:/etc/sysconfig/tcedir$ prov 'bin\/tar$'
tar.tcz
tc@pi4:/etc/sysconfig/tcedir$ prov 'bin\/tar\n/||/bin\/tar$'
tar.tcz
tc@pi4:/etc/sysconfig/tcedir$ provides.sh 'bin\/tar\n'
tc@pi4:/etc/sysconfig/tcedir$ provides.sh 'bin\/tar$'
tar.tcz
tc@pi4:/etc/sysconfig/tcedir$ provides.sh 'bin\/tar\n/||/bin\/tar$'
tar.tcz

--- End code ---

This is getting ridiculous...


--- Code: ---tc@pi4:~$ p(){ awk 'BEGIN {FS="\n";RS=""} /'"$1"'\/'"$2"'\n/||/'"$1"'\/'"$2"'$/{print $1}' /etc/sysconfig/tcedir/provides.db; }
tc@pi4:~$ p bin tar
tar.tcz

--- End code ---

Shrink the line

--- Code: ---tc@pi4:~$ p(){ awk -v FS="\n" -v RS="" "/$1\/$2\n/||/$1\/$2$/{print \$1}" /etc/sysconfig/tcedir/provides.db; }
tc@pi4:~$ p bin tar
tar.tcz

--- End code ---

Other cases


--- Code: ---tc@pi4:/etc/sysconfig/tcedir$ grep -A3 submitqc.tcz provides.db
submitqc.tcz
/usr/local/bin/submitqc
/usr/local/share/doc/submitqc/COPYING

tc@pi4:/etc/sysconfig/tcedir$ p bin submitqc
submitqc.tcz
tc@pi4:/etc/sysconfig/tcedir$ p submitqc COPYING
submitqc.tcz
tc@pi4:/etc/sysconfig/tcedir$ grep -A3 wget.tcz provides.db
wget.tcz
/usr/local/etc/wgetrc
/usr/local/bin/wget

tc@pi4:/etc/sysconfig/tcedir$ p bin wget
wget.tcz
tc@pi4:/etc/sysconfig/tcedir$ p etc wgetrc
wget.tcz

--- End code ---

Rich:
Hi polikuo
That looks like it works, but I don't think a user should be
forced to use an exact match. A user may not be sure what
they are searching for. For example, they might want to
find all extensions with files that have crypt in their name.
I've done those types of searches myself on occasion.

If a person needs to get more specific with the path, they
still need to do this:

--- Code: ---p "local\/bin" ps
--- End code ---

These are not criticisms, just observations. Your awk solution
appears to be more efficient and shorter than mine. Though
mine doesn't need quotes for some reason:

--- Code: ---tc@E310:~$ Provides.sh local\/bin\/ps
procps-ng.tcz
procps.tcz
tc@E310:~$
--- End code ---

Leee:
As so often happens, I learned a lot while messing around with provides.sh.
First, the format of provides.db is easy to produce and doesn't contain a lot of redundant data (does not have the TCZ name at the start of each line ), and remains human readable (unlike, for instance, an SQL datebase table), it really doesn't lend itself to simple searches.
Second, mucking around with FS and RS so that each record -does- begin with the TCZ name. Now -that- is neat.
Third, as usual, I learned a little more about awk,  Alas, I haven't yet learned enough about awk (I find the syntax to be... wait for it... awkward!) so...
I tried coding the exact search, using other tools, to search for lines ending in /${TARGET} and it worked perfectly... but took four minutes to run.
I'm going to continue following this thread (big thanks to all in the thread) and continue playing with my own script... but that will have to be -after- I finish dealing with some "old, failing hardware" issues.

Leee:

--- Quote from: Rich on November 14, 2024, 01:48:55 PM ---Hi polikuo
That looks like it works, but I don't think a user should be
forced to use an exact match. A user may not be sure what
they are searching for. For example, they might want to
find all extensions with files that have crypt in their name.
I've done those types of searches myself on occasion.
--- End quote ---
I think any search tool should default to an exact search, possibly with an option for a fuzzy search.  Less ideal (IMO) would be defaulting to a fuzzy search with an option for an exact search.  Having only a fuzzy search is just frustrating.

In the mean time, looking at provides.sh and realizing that it uses awk, provides the clue that  a regular slash character ( / ) needs to be escaped, makes the stock provides.sh usable with, for instance, provides.sh "ps \/ps\n" for an exact search.  I would never have otherwise have thought to escape the slash character.

Navigation

[0] Message Index

[#] Next page

[*] Previous page