shfm ________________________________________________________________________________ file manager written in posix shell screenshot: https://user-images.githubusercontent.com/6799467/89270554-2b40ab00-d644-11ea-9f2b-bdabcba61a09.png features ________________________________________________________________________________ * no dependencies other than a POSIX shell + POSIX [, printf, dd and stty *** * tiny * single file * no compilation needed * correctly handles files with funky names (newlines, etc) * works with very small terminal sizes. * cd on exit * works when run in subshell $(shfm) *** see portability notes towards bottom of README. keybinds ________________________________________________________________________________ j - down k - up l - open file or directory h - go up level g - go to top G - go to bottom q - quit : - cd to <input> / - search current directory <input>* - - go to last directory ~ - go home ! - spawn shell . - toggle hidden files ? - show help Also supported: down arrow - down up arrow - up left arrow - go up level right arrow - open file or directory backspace - up enter - open file or directory todo ________________________________________________________________________________ - [x] sanitize filenames for display. - [ ] print directories first (hard). - [x] fix buggy focus after exit from inline editor. - [ ] maybe file operations. - [x] add / to directories. - [x] going up directories should center entry. - [x] abstract over sequences. - [x] look into whether tput is feasible. cd on exit ________________________________________________________________________________ On exit, the utility will print the path to working directory to <stdout>. To disable this behavior, run with 'shfm >/dev/null'. Usage of this output is rather flexible. # cd to directory on exit cd "$(shfm)" # store pwd in var on exit var=$(shfm) # store pwd in a file on exit shfm > file For ease of use, a wrapper function can be added to your .shellrc (.bashrc, etc). shfm() { cd "$(command shfm "$@")" } opener ________________________________________________________________________________ Opening files in different applications (based on mime-type or file extension) can be achieved via an environment variable (SHFM_OPENER) set to the location of a small external script. If unset, the default for all files is '$EDITOR' (and if that is unset, 'vi'). The script receives a single argument, the full path to the selected file. The opener script is also useful on the command-line. The environment variable is set as follows. export SHFM_OPENER=/path/to/script Example scripts: #!/bin/sh -e # # open file in application based on file extension case $1 in *.mp3|*.flac|*.wav) mpv --no-video "$1" ;; *.mp4|*.mkv|*.webm) mpv "$1" ;; *.png|*.gif|*.jpg|*.jpe|*.jpeg) gimp "$1" ;; *.html|*.pdf) firefox "$1" ;; # all other files *) "${EDITOR:=vi}" "$1" ;; esac #!/bin/sh -e # # open file in application based on mime-type mime_type=$(file -bi) case $mime_type in audio/*) mpv --no-video "$1" ;; video/*) mpv "$1" ;; image/*) gimp "$1" ;; text/html*|application/pdf*) firefox "$1" ;; text/*|) "${EDITOR:=vi}" "$1" ;; *) printf 'unknown mime-type %s\n' "$mime_type" ;; esac portability notes ________________________________________________________________________________ * SIGWINCH and the size parameter to stty are not /yet/ POSIX (but will be). - https://austingroupbugs.net/view.php?id=1053 - https://austingroupbugs.net/view.php?id=1151 * VT100/ANSI escape sequences (widely available) are used in place of tput. A few non-VT100 sequences /are/ needed however. - IL vt102 \033[L: upwards scroll. (required) - xterm \033[?1049[lh]: alternate screen. (optional) - DECTCEM vt520 \033[?25[lh]: cursor visibility. (optional) Why avoid tput? POSIX only specifies three operands for tput; clear, init and reset [0]. We cannot rely on anything additional working across operating systems and tput implementations. Further, a tput implementation may use terminfo names (example: setaf) or termcap names (example: AF). We cannot blindly use tput and expect it to work everywhere. [1] We could simply follow terminfo and yell at anyone who doesn't though I'm also not too keen on requiring tput as a dependency as not all systems have it. I've found that raw VT100/VT102 sequences work widely. Neofetch uses them and supports a wide array of operating systems (Linux, IRIX, AIX, HP-UX, various BSDs, Haiku, MINIX, OpenIndiana, FreeMiNT, etc. YMMV [0] https://pubs.opengroup.org/onlinepubs/009695399/utilities/tput.html [1] https://invisible-island.net/ncurses/man/tput.1.html#h2-PORTABILITY implementation details ________________________________________________________________________________ * Draws are partial! The file manager will only redraw what is necessary. Every line scrolled corresponds to three lines being redrawn. The current line (clear highlight), the destination line (set highlight) and the status line (update location). * POSIX shell has no arrays. It does however have an argument list (used for passing command-line arguments to the script and when calling functions). Restrictions: - Can only have one list at a time (in the same scope). - Can restrict a list's scope but cannot extend it. - Cannot grab element by index. Things I'm thankful for: - Elements can be "popped" off the front of the list (using shift). - List size is given to us (via $#). - No need to use a string delimited by some character. - Can loop over elements. * Cursor position is tracked manually. Grabbing the current cursor position cannot be done reliably from POSIX shell. Instead, the cursor starts at 0,0 and each movement modifies the value of a variable (relative Y position in screen). This variable is how the file manager knows which line of the screen the cursor is on. * Multi-byte input is handled by using a 2D case statement. (I don't really know what to call this, suggestions appreciated) Rather than using read timeouts (we can't sleep < 1s in POSIX shell anyway) to handle multi-byte input, shfm tracks location within sequences and handles this in a really nice way. The case statement matches "$char$esc" with "$esc" being an integer holding position in sequences. To give an example, down arrow emits '\033[B'. - When '\033?' is found, the value of 'esc' is set to '1'. - When '[1' is found, the value of 'esc' is set to '2'. - When 'B2' is found, we know it's '\033[B' and handle down arrow. - If input doesn't follow this sequence, 'esc' is reset to '0'. * Filename escaping works via looping over a string char by char. I didn't think this was possible in POSIX shell until I needed to do this in KISS Linux's package manager and found a way to do so. I'll let the code speak for itself (comments added for clarity): file_escape() { # store the argument (file name) in a temporary variable. # ensure that 'safe' is empty (we have no access to the local keyword # and can't use local variables without also using a sub-shell). This # variable will contain its prior value (if it has one) otherwise. tmp=$1 safe= # loop over string char by char. # this takes the approach of infinite loop + inner break condition as # we have no access to [ (personal restriction). while :; do # Remove everything after the first character. c=${tmp%"${tmp#?}"*} # Construct a new string, replacing anything unprintable with '?'. case $c in [[:print:]]) safe=$safe$c ;; '') return ;; # we have nothing more to do, return. *) safe=$safe\? ;; esac # Remove the first character. # This shifts our position forward. tmp=${tmp#?} done } # Afterwards, the variable 'safe' contains the escaped filename. Using # globals here is a must. Printing to the screen and capturing that # output is too slow. * SIGWINCH handler isn't executed until key press is made. SIGWINCH doesn't seem to execute asynchronously when the script is also waiting for input. This causes resize to require a key press. I'm not too bothered by this. It does save me implementing resize logic which is utter torture. :)