A week ago I started a little script to format the output of file and path listings from other programs. It got a little bit out of hand and I implemented lot of advanced features into the fmt commands; kind of a sub language to define how the output should be formatted and structured. Entire idea is to give it paths, process the stream (not the file content itself, but the path representing a file) and output them again.

fpath accepts two type of input: a) either as arguments like fpath *.txt or b) from stdin like ls -1 | fpath . With additional options and commands the output can be colored and reformatted to something entirely different. In example with -F option the advanced formatting is possible, such as fpath -F '{.size} {name}' as a simple example.

There is lot of functionality (based on Python, yes this is a Python script), such as {reverse}{name}{/reverse} to reverse font color and background of the segment that is enclosed by the command, a slice to get a subset as a range from the entire path {-1:}, or {center:80}text{/center} to add spaces to get centered text, or just {ext} to output the extension, {mime} to output the file mime type, or even execute arbitrary programs {!grep:a}{path}{/!} to reduce output that has an a in the path.

Did I over engineer it again? Or just ignore most stuff and use it with the most simple options, should be enough anyway: fpath -t -s red *.txt

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.

I did it again; exaggerate a simple idea and make it look more complicated at the end with too much text in the readme. I was bothered with the output of file listings and how unreadable they can get, especially with long paths and many of them on screen. At the end, I am not sure how useful this will be in the long run, but that is something you can judge yourself. It was certainly fun to create and in my opinion it's also fun to use.

git clone https://github.com/thingsiplay/fpath
cd fpath
chmod +x fpath

What is this? Convenience script to style and reformat the output with path like formats. Designed to combine listings from other programs output, such as from find and even ls, or any other tool with similar capabilities. The script works mostly on text data rather than the file system, but some special commands are exception to this rule and will access the file system.