This method reads image files directly from the current directory $PWD and then uses an array to keep track of all the images. The use of Bash built-in commands like for loop and if condition ensure a faster execution because there is no need to create a subprocess for each image file. The sxiv command is run only once when the selected image is found.
Furthermore, this method takes advantage of array slicing in Bash ("${images[@]:i}" "${images[@]:0:i}"). This feature allows the program to pass the images that come after the selected image (including the selected image) and before the selected image, to sxiv in correct order. This maintains the file order of the directory. The use of sort -V (version sort) also contributes to maintaining the file order as it sorts version numbers within text.
In terms of efficiency, using Bash built-in operations with arrays should consume less system resources compared to lots of pipelines with multiple processes.
The old method uses the rotdir script which, when combined with awk, ls, grep, setsid, and sxiv, creates multiple subprocesses. This increases the overhead for context switching between these processes, leading to more system resource usage and a slower operation than the first method.
Moreover, the use of setsid -f sxiv -aio 2>/dev/null might launch sxiv multiple times, increasing the number of processes and resource usage.
In terms of file ordering, the rotdir script doesn't have explicit sorting. This might not necessarily match the desired order in some cases.
Lastly, the second method uses lf -remote to interact with the lf file manager. The command is run each time a new image is selected, adding an additional level of complexity and overhead to the process.
The first method is more readable and maintainable due to its use of simple Bash constructs. The logic is straightforward and doesn't involve external scripts.
On the other hand, the second method requires understanding the rotdir script, making it more complex to read and understand. The maintenance of this script would also need to be considered alongside the lfrc file, adding an extra layer of complexity.
We can even get rid of ls and sort by using bash globbing alone but then the files are ordered lexicographically, not numerically. Meaning they would go to 10th after 1st rather than 2nd. There could be a workaround though with naming the files with leading zeroes such as 01, 02 and so on.
# Detailed Explanation
shopt -s nullglob
This line tells bash to treat patterns which don't match any files (globs) as expanding to a null string, rather than themselves. This avoids problems in case there are no image files in the directory.
dir="$0"
selected_file="$1"
Here, dir and selected_file are being set to the two arguments that are passed to the bash script at the end ("$PWD" and "$fx"). They are the working directory and the selected file, respectively.
images=($(ls "$dir"/*.{jpg,jpeg,png,webp,bmp,tiff,tif,raw,ico,exif,heic,heif,gif,avif,jxl} | sort -V))
The ls command lists all the files in the directory that have certain image extensions. This list of files is piped (|) to sort -V, which sorts the list in version number order (which is similar to natural order for filenames). This sorted list of images is stored in the images array.
[[ "${images[i]}" = "$selected_file" ]] && {
sxiv -abiof "${images[@]:i}" "${images[@]:0:i}"
break
}
done
This is a for loop that iterates over each image in the images array. For each image, it checks if the image equals the selected file. If it does, the sxiv command is executed with all images from the selected one to the end of the list, followed by all images from the start of the list to the selected one. This makes it possible to navigate through the images both forward and backward, preserving the order from lf. After this, the break command is used to exit the for loop because we've found our selected image.
The "$PWD" and "$fx" at the end are the arguments that are passed to the bash script. "$PWD" is the current working directory in lf, and "$fx" is the currently selected file in lf.
application/octet-stream mime-type is used for arbitrary binary files, so the best guess at opening those kind of should be based on the extension. before this all of this kind of files were tried to be opened with zathura, now it is the last resort in case the file extension is unknown.
Very arcane.
C ANSI standard requires a newline at the end. GCC will complain.
Email signatures should have a space after the -- according to the
standard. Neomutt does this automatically for you if you have a
signature.
Co-authored-by: Spenser Truex <truex@equwal.com>
In the current update, the libreoffice package doesn't have any binary for libreoffice writer, calc, impress, draw, etc. So it's better to open all of the document using the 'libreoffice' binary as it can work in the old version of libreoffice as well as the new one.
