GitHub - thingsiplay/fpath: Reformat and stylize file path like text output.
github.com
Reformat and stylize file path like text output. Contribute to thingsiplay/fpath development by creating an account on GitHub.

Hi all. Yesterday I posted a program/script which is focused on path based text formatting, such as output from ls or find. Today I want to share new version. I’m proud, even though its limited in its usefulness, but today I solved an issue that was complicated to me (and a few other issues).

Linux command file is used to display file type and mime information, which is super handy. Reason why this was complicated to me is, as I want it to run only once for all paths together for performance reasons. For over thousand files instead taking more than a minute execution time, its down to under 2 seconds when displaying file type information (which includes spawning file process in the background). A few examples:

$ find Desktop/*.* -maxdepth 0 | fpath -F'{type}   \t{name}'
text/plain      append.cfg
text/plain      dynamic.cfg
image/png       nearest.png
image/png       new.png

$ find Desktop/*.* -maxdepth 0 | fpath -a -F'{path}\n\t{file}'
/home/tuncay/Desktop/append.cfg
        ASCII text
/home/tuncay/Desktop/dynamic.cfg
        ASCII text
/home/tuncay/Desktop/nearest.png
        PNG image data, 1920 x 1440, 8-bit/color RGB, non-interlaced
/home/tuncay/Desktop/new.png
        PNG image data, 1920 x 1440, 8-bit/color RGB, non-interlaced

Update v0.3:

Rather than creating a new post, I want to note that I have a huge update. First off, the performance is increased drastically with recent optimizations. Even thousands of paths are now processed very fast (until operations reading from file system is involved).

Just to put into perspective: When I search and output list of paths with time baloosearch6 "a" in my home, I get 8468 files and it takes 0m0,048s. Now when I pipe that into fpath with default processing and without options, it takes 0m0,086s to process. But with a more complex command that involves reading file stats (like size and such) and colored output and a slice:

time baloosearch6 "a" | fpath -F'{.mode}  {.size} \t{-3:-1}: {blue}{name} {}' -sred

it only takes 0m0,200s to execute! But using {file} or {type} or {mime} will still take a long time, even if the subshell process is run only once (it will still read the information for every file):

time baloosearch6 "a" | fpath -F'{file}'

took 3m54,233s to run. But what do you expect with approx. 8 thousand files. Without this script, it would take the same amount of time when running bare metal file command on all of these files.

Secondly, I have implemented a slice command that works very well. It’s like the index {3} thing, but now you can set a {start:end} range to not only get a single part, but all parts within that range. It even works with negative numbers like {-3:} to get the last three parts of a path. An empty index means to get everything until end of path.

I’m quite happy how this program turned to be out. Python (at least for me with Python v3.12) is not that slow after all.