You are not logged in.

#1 2012-02-14 16:49:39

hut
Member
From: Hanover, Germany
Registered: 2010-03-12
Posts: 569
Website

File Opener

There are many file openers out there, but each one lacks some features that I really need. Here's what my ideal file opener should be like:

1. Store configuration in plain text in a simple parseable format. Ideally, 1 line per type or program or method of opening, so a script can simply extend the configuration by adding another line
2. Allow the user to open the same file in different ways. (e.g. open a video windowed, fullscreen, audio-only, etc. configurable by the user)
3. Allow running the same file file with different programs (videos with mplayer, mlpayer2, VLC, totem,...)

$ open --with mplayer foo.avi # runs mplayer
$ open --with vlc foo.avi # runs VLC
$ open foo.avi # runs the default program

4. Ship with a configuration that recognizes the type of most files and opens them out of the box.

$ open asdfjkl # AND IT JUST WORKS

5. Support determining file types based on multiple factors: mime type, extension, full file name and path

$ open foo.c # runs "gcc foo.c && ./a.out"
$ cd myproject; open bar.c # runs "make && ./bar"

6. Run different programs, depending on whether X runs or not, whether STDIN is a keyboard,...

$ open foo.html # runs "firefox foo.html"
$ DISPLAY= open foo.html # runs "elinks foo.html"
$ : | open foo.html # runs "elinks -dump foo.html"

7. Enumerate all possible methods to open a file, and choose the method based on an entered number

$ open --list foo.png
0: feh (windowed)
1: feh (fullscreen)
2: gimp
$ open --method=2 foo.png # runs gimp

8. Have an unnoticable startup time
9. Have GUIs for curses and for X that allow you to quickly pick a program and add new file types/programs.

Ranger has a file opener that can do most of those, but fails at #1, #6 (fails if STDIN is no keyboard), #7 (no listing), #8 and #9.
AFO (Automatic File Opener) is a prototype that improves in #1, #7 and #8 over ranger, but I'm still not quite satisfied.
Some day I want to code a file opener that can do it all, but first I want to ask you:

What do you value in a file opener? Are there important features that I missed? What's the best file opener that you came across?


"hut_" or "h00th00t" in irc.freenode.net #archlinux
Ranger Mailing List: https://lists.nongnu.org/mailman/listinfo/ranger-users

Offline

#2 2012-02-14 18:10:40

Earnestly
Member
Registered: 2011-08-18
Posts: 805

Re: File Opener

mimi

Is what I personally prefer.

Last edited by Earnestly (2012-02-14 18:10:57)

Offline

#3 2012-02-14 20:45:55

clvv
Member
Registered: 2011-02-07
Posts: 9

Re: File Opener

I've been thinking about implementing a file opener for a while. I haven't come across anything that fits exactly what I have in mind.

In response to your list of features, I have several comments:

2 and 3: I second this, unless there's a easy way to list, select and launch with different method.

5: I think this adds unessasary complication, and "open" should only limit opening the file.

9: I think the tool itself should only expose the interface. Curses or GUI can be some external tool or addon.

In addition to you list, here is what I think a file opener should also have:

1. Portability. Perferably written in POSIX shell script.

2. Take advantage of "file" to determine mime type (or file type).

Offline

#4 2012-02-14 23:57:17

taylorchu
Member
Registered: 2010-08-09
Posts: 405

Re: File Opener

i think mimi will have #2, 3, 7 today.
#4 looks impossible to me, unless you have a list of programs. but for archlinux users, this is not possible because we always try new things out!
#9 i would let users to choose what editor they want to use. i dont think making a new editor is necessary.

BTW, we should always think about xdg-utils because this is the standard. we should not break it.


"After you do enough distro research, you will choose Arch."

Offline

#5 2012-02-15 00:57:04

hut
Member
From: Hanover, Germany
Registered: 2010-03-12
Posts: 569
Website

Re: File Opener

taylorchu wrote:

#4 looks impossible to me, unless you have a list of programs. but for archlinux users, this is not possible because we always try new things out!

IMO this is required for integration into file managers, because when you open an image file in a file manager, you just expect some image viewing software to open. Anyway, the important thing is not a 100% complete list of programs, but a feature that determines which program is installed and which is not.

taylorchu wrote:

BTW, we should always think about xdg-utils because this is the standard. we should not break it.

I wonder if xdg-utils is relevant to those who don't use a desktop environment?

clvv wrote:

5: I think this adds unessasary complication, and "open" should only limit opening the file.

Why is #5 not about opening files? Maybe there's a misunderstanding?
Look at this case: mpd, my favorite music player, can only play music located in /var/music/. Every other media file should be opened with mplayer. The file opener needs to know the full path of the file for determining whether to run mpc or mplayer.


"hut_" or "h00th00t" in irc.freenode.net #archlinux
Ranger Mailing List: https://lists.nongnu.org/mailman/listinfo/ranger-users

Offline

#6 2012-02-15 02:58:29

clvv
Member
Registered: 2011-02-07
Posts: 9

Re: File Opener

hut wrote:

Why is #5 not about opening files? Maybe there's a misunderstanding?
Look at this case: mpd, my favorite music player, can only play music located in /var/music/. Every other media file should be opened with mplayer. The file opener needs to know the full path of the file for determining whether to run mpc or mplayer.

True, I was more commenting on the example you used:

$ open foo.c # runs "gcc foo.c && ./a.out"
$ cd myproject; open bar.c # runs "make && ./bar"

I think usage like this defeat the purpose of calling it "open." But I agree that path awareness could be helpful. I also agree that the tool should not rely on xdg. Of course optional support for it could be falling back on to using "xdg-open" instead. And once the infrastracture is there, it should be really flexible for the users to customize.

Mimi is pretty cool. But since it's not really relying on any bash features, why not make it more portable?

Offline

#7 2012-02-15 11:28:54

Earnestly
Member
Registered: 2011-08-18
Posts: 805

Re: File Opener

In my honest opinion; number 4 on your list should be implemented with the option to completely disable it, or to not implement it at all.

The reason I listed mimi was that it is:
1) very easy and logical to configure. KISS
2) has a default option for any file you have not explicity allowed.
3) doesn't try to second guess what I want.

The combination of those three has simply eliminated all my major problems with xdg-open.

PS: I don't really see the point in number 2; let the media player and it's configuration deal with it. Same with 6 and 7, however, I do like the idea of 'open --with' in your example. I personally doesn't see the point in number 9 either.

Edit: I may fix this messy post at some point.

Last edited by Earnestly (2012-02-15 11:29:59)

Offline

#8 2012-02-15 13:29:17

mutantpineapple
Member
From: UK
Registered: 2009-12-16
Posts: 29

Re: File Opener

My two cents:

I agree that #4 would be impractical, especially for a distro like Arch where there aren't any defaults and people use a wide variety of different programs. Should readme.txt be opened with Gedit, Kate, Gvim? Should picture.jpg be opened with feh, qiv, Gimp? None of those are installed by default. As long as #1 is KISS, there shouldn't be any need for out-of-the-box functionality. Same with #9 -- if the configuration is handled in a KISS way then there's no real need for any sort of gui, because you're only going to be typing the same things into the gui as you'd put in the config file.

#2 could be handled by #3. #3 would be cool, but fairly low priority for me because the purpose of a file opener for me would be to open a file in the "usual" way. If I wanted to open a file in a different way to the usual, I'd prefer to just specifically issue the desired command. If I have to spend time interacting with the file opener then it's no faster than using the desired command.

#5 sounds very interesting, particularly the path idea. I wonder if this would complicate configuration though.

#6 would be great.


I don't currently use a file opener, but if I did then it would mostly be used by my browser to handle downloaded files. All I really require is something that looks at the file extension and opens the correct program, and which is simple to configure. I don't need any mimetype stuff, and xdgutils is definitely overkill.

Offline

#9 2012-02-15 14:14:57

hut
Member
From: Hanover, Germany
Registered: 2010-03-12
Posts: 569
Website

Re: File Opener

mutantpineapple wrote:

I agree that #4 would be impractical, especially for a distro like Arch where there aren't any defaults and people use a wide variety of different programs. Should readme.txt be opened with Gedit, Kate, Gvim? Should picture.jpg be opened with feh, qiv, Gimp? None of those are installed by default. As long as #1 is KISS, there shouldn't be any need for out-of-the-box functionality.

Yes, none of those are installed by default, and that's how the magic works: You *probably* installed the programs that you use, so the opener can just take a look at what's installed.

And of course #4 would be disableable. Think of it as a default configuration that you can extend or replace however you want.

mutantpineapple wrote:

I don't currently use a file opener, but if I did then it would mostly be used by my browser to handle downloaded files. All I really require is something that looks at the file extension and opens the correct program, and which is simple to configure. I don't need any mimetype stuff, and xdgutils is definitely overkill.

Same here. I don't need a program that makes me type "open foo.txt" instead of "vim foo.txt" to save me from thinking. I want to use it in combination with a "just run it!!1"-button to eliminate user interaction completely. The cases I'm thinking of are: web browser, emailer, file manager and editor.

Kaustic wrote:

The reason I listed mimi was that it is:
1) very easy and logical to configure. KISS
2) has a default option for any file you have not explicity allowed.
3) doesn't try to second guess what I want.

I was impressed by the simplicity of mimi too, but it's not complex enough for my use cases.

Last edited by hut (2012-02-15 14:24:21)


"hut_" or "h00th00t" in irc.freenode.net #archlinux
Ranger Mailing List: https://lists.nongnu.org/mailman/listinfo/ranger-users

Offline

#10 2012-02-16 05:47:31

mutantpineapple
Member
From: UK
Registered: 2009-12-16
Posts: 29

Re: File Opener

Here's something I put together today in case anyone's interested. It requires dmenu and/or slmenu for manual selection of programs, depending on whether you're in a tty or on your personal preference. It also uses libnotify to warn of errors when not being run through a terminal. Forgive the terrible coding, this is only my second shell script.
It does a few of the things mentioned in this thread, specifically #1, #2, #3, #6, #7, #8, and half of #9.

#!/bin/sh
# Simple file opener based on file extension

# Depends: libnotify, dmenu, slmenu, cut, sed, grep

# --CONFIG--
extlist="$XDG_CONFIG_HOME/open/extlist" # Location of list of extensions
delim=":"           # Which character to use for delimiter in extlist file
default_mode="auto" # auto/manual (set to auto for automatic program selection)
dmenu_default=1     # Controls whether dmenu is used by default in X
# ---END----

auto_option=1

i=0
if [ -t "$i" ]
then
  interactive=1
else
  interactive=0
fi

if [ -z $DISPLAY ]
then
    dmenu_default=0
    X=0
else
    X=1
fi

if [ $interactive = 1 -a $dmenu_default = 0 ]
then
    if [ -e $HOME/.slmenurc ]
    then
        . $HOME/.slmenurc
    else
        SLMENU="slmenu -i"
    fi
    menu="$SLMENU"
else
    if [ -e $HOME/.dmenurc ]
    then
        . $HOME/.dmenurc
    else
        DMENU="dmenu -i"
    fi
    menu="$DMENU"
fi

fn=${@: -1}

if [ ! -e "$fn" ]
then
    if [ $interactive = 1 ]
    then
        echo "Invalid filename"
    else
        notify-send "Invalid filename"
    fi
    exit 1
fi

if [ $# -gt 1 ]
then
    if [ $# -gt 2 ]
    then
        if [ $interactive = 1 ]
        then
            echo "Too many arguments"
        else
            notify-send "Too many arguments"
        fi
    elif [ $1 = "manual" -o $1 = "auto" -o $1 = "list" ]
    then
        mode=$1
    elif [ $(echo $1 | sed -e "/^[1-9]\+[0-9]*$/! {d}") ]
    then
        mode="auto"
        auto_option=$1
    else
        if [ $interactive = 1 ]
        then
            echo "Invalid mode option: '$1'"
        else
            notify-send "Invalid mode option: '$1'"
        fi
        exit 1
    fi
else
    mode="$default_mode"
fi

hasext=$(echo "$fn" | sed -e '/\(\.\)\?\(.\)\+\.[a-zA-Z0-9]\+$/! {d}')
if [ -z $hasext ]
then
    if [ $interactive = 1 ]
    then
        echo "'$(basename $fn)' has no extension"
    else
        notify-send "'$(basename $fn)' has no extension"
    fi
    exit 1
fi


ext=${fn##*.}

all=$(sed '/^\#/d' "$extlist")
suitable=$(echo "$all" | sed -e "/$delim\([ \t]*\([a-zA-Z0-9,]*\),$ext\)\|\($ext\(,[a-zA-Z0-9]*\)*$\)/I! {d}")
if [ $X = 0 ]
then
    suitable=$(echo "$suitable" | sed -e "/^[%@]/! {d}")
else
    suitable=$(echo "$suitable" | sed -e "/^[^@]/! {d}")
fi

if [ -z "$suitable" ]
then
    if [ $interactive = 1 ]
    then
        echo "No program found for extension '.$ext'"
    else
        notify-send "No program found for extension '.$ext'"
    fi
    exit 1
elif [ $(echo "$suitable" | wc -l) -lt $auto_option ]
then
    if [ $interactive = 1 ]
    then
        echo "Invalid number: '$1' (Not enough options)"
    else
        notify-send "Invalid number: '$1' (Not enough options)"
    fi
    exit 1
fi


if [ $(echo "$suitable" | grep "$delim$delim") ]
then
    if [ $# = 1 ]
    then
        mode="manual"
    fi
fi

namelist=$(echo "$suitable" | cut -d "$delim" -f 1 | tr -s ' ')
if [ "$mode" = "auto" ]
then 
    command=$(echo "$suitable" | sed -n "$auto_option"p | cut -d "$delim" -f 2 | tr -s ' ')
elif [ "$mode" = "list" ]
then
    echo "$namelist" | cat -n
    exit 0
elif [ "$mode" = "manual" ]
then
    if [ $(echo "$namelist" | wc -l) -gt 1 ]
    then
        selection=$(echo "$namelist" | eval $menu -p "Program:")
        if [ -z "$selection" ]
        then
            exit 1
        fi
    else
        selection="$namelist"
    fi
    selectionln=$(echo "$namelist" | grep -xn "$selection" | cut -d "$delim" -f 1)
    if [ "$selectionln" ]
    then
        command=$(echo "$suitable" | sed -n "$selectionln"p | cut -d "$delim" -f 2)
    else
        command="$selection"
    fi
fi

case "$command" in
    *\"\$fn\"*) eval $command;;
    *\$fn*) command=$(echo "$command" | sed 's/\$fn/"\$fn"/g')
        eval "$command";;
    *) eval "$command \"$fn\"";;
esac

The config file looks something like this:

# Format = Name:Command:Extensions
#
# Use commas to separate extensions
# Begin a name with % to make it available outside of X
# Begin a name with @ to make it available ONLY outside of X

# Movies
%Mplayer             :   mplayer            :   avi,wmv,asf,mp4
%Mplayer (Fullscreen):   mplayer -fs        :   avi,wmv,asf,mp4
VLC                  :   vlc $fn            :   avi,wmv,asf,mp4

# Music
%Mplayer             :   mplayer            :   mp3,ogg,flac,wav
%Mp3blaster          :   mp3blaster         :   mp3,ogg
%Aplay               :   aplay              :   wav

# Images
Viewnior             :   viewnior           :   jpg,png
Gimp                 :   gimp               :   jpg,png,xcf
@Fbv                 :   fbv                :   jpg,png

# Text
Gvim                 :   gvim               :   txt,conf,c,py
@Vim                 :   vim                :   txt,conf,c,py
%GCC                 :   gcc "$fn" -o a.out :   c

# User input will always be asked for extensions prefixed with double colons
::avi,c

It's pretty tolerant in terms of the layout. The command can use the filename argument $fn (with or without double quotes) if you want, but it isn't actually needed unless you need to use the filename in the middle of the command (see the gcc example).
The higher the item in the list, the higher its priority. I eventually decided to organise the list by program rather than by extension, because most programs support a huge amount of filetypes whereas most people will only have a handful of programs installed for each filetype, so this way is neater imo.

If you want to use it, save it as something like "open" and run it like "open foo.bar". If more than one program is listed in the config file for the .bar extension, it'll run the first one by default. If you want to choose, run "open manual foo.bar" which will give you a selection using dmenu/slmenu. You can also enter your own command at that point. To list all known programs that can view a particular file, run "open list foo.bar" for a numbered list. You can then run "open 2 foo.bar" to open the file with the second program in that list.

Preferences are at the top of the shell script. I only use bash, but I've tested it on zsh and everything seems to be working fine.

I'm sure there are bugs. Let me know if you find any -- if you decide to try it, that is. If people actually want to use it then it would be fairly trivial to make a gui for editing the config.

Last edited by mutantpineapple (2012-02-16 11:42:49)

Offline

#11 2012-02-16 22:11:08

mutantpineapple
Member
From: UK
Registered: 2009-12-16
Posts: 29

Re: File Opener

I fixed a few bugs and improved the ability to accept input. The syntax is now a bit different.
open foo.bar                               # opens foo.bar in first match of "bar" in config
open -m auto|manual|list foo.bar  # changes selection mode (the -m option also takes a|m|l)
open -n 2 foo.bar                        # opens foo.bar in second match of "bar" in config

Here's the code:

#!/bin/sh
# Simple file opener based on file extension

# Depends: libnotify, dmenu, slmenu, cut, sed, grep, tr

# --CONFIG--
extlist="$XDG_CONFIG_HOME/open/extlist" # Location of list of extensions
delim=":"           # Which character to use for delimiter in extlist file
default_mode="auto" # auto/manual (set to auto for automatic program selection)
dmenu_default=1     # Controls whether dmenu is used by default in X
# ---END----

number=""
mode="$default_mode"
explicitmode=0
stdredirected=0

if [ -t 0 ]
then
    interactive=1
else
    interactive=0
fi

if [ -z "$DISPLAY" ]
then
    dmenu_default=0
    X=0
else
    X=1
fi

eval set -- `getopt -n open -o m:n: -- "$@"`
while true
do
    case "$1" in
        -m) mode="$2"; shift 2; explicitmode=1;;
        -n) number="$2"; shift 2;;
        --) shift; break;;
        *) echo "Invalid option"; exit 1;;
    esac
done

case "$mode" in
    a) mode="auto";;
    m) mode="manual";;
    l) mode="list";;
esac

if [ -n "$number" -a ! "$mode" = "list" ]
then
    mode="auto"
fi

if [ $interactive = 1 -a $dmenu_default = 0 ]
then
    if [ -e $HOME/.slmenurc ]
    then
        . $HOME/.slmenurc
    else
        SLMENU="slmenu -i"
    fi
    menu="$SLMENU"
else
    if [ -e $HOME/.dmenurc ]
    then
        . $HOME/.dmenurc
    else
        DMENU="/usr/bin/dmenu -i"
    fi
    menu="$DMENU"
fi

fn=${@: -1}

if [ -z "$fn" ]
then
    while read input
    do
        fn="$input"
    done < /dev/stdin
    stdinredirected=1
fi

if [ -z "$fn" ]
then
    if [ $interactive = 1 ]
    then
        echo "No filename given"
    else
        notify-send "No filename given"
    fi
    exit 1
fi

if [ ! -e "$fn" ]
then
    if [ $interactive = 1 ]
    then
        echo "Invalid filename"
    else
        notify-send "Invalid filename"
    fi
    exit 1
fi

hasext=$(echo "$fn" | sed -e '/\(\.\)\?\(.\)\+\.[a-zA-Z0-9]\+$/! {d}')
if [ -z "$hasext" ]
then
    if [ $interactive = 1 ]
    then
        echo "'$(basename $fn)' has no extension"
    else
        notify-send "'$(basename $fn)' has no extension"
    fi
    exit 1
fi

ext=${fn##*.}

all=$(sed '/^\#/d' "$extlist")
suitable=$(echo "$all" | sed -e "/$delim *\(\([a-zA-Z0-9,]*,\)\?$ext\(,[a-zA-Z0-9,]*\)\?$\)/I! {d}")
if [ "$stdinredirected" = 1 ]
then
    noninteractive=$(echo "$suitable" | sed -e '/^|/! {d}')
    if [ -n "$noninteractive" ]
    then
        suitable="$noninteractive"
    fi
else
    suitable=$(echo "$suitable" | sed -e '/^[^|]/! {d}')
fi

if [ $X = 1 ]
then
    suitable=$(echo "$suitable" | sed -e '/^[^@]/! {d}')
else
    suitable=$(echo "$suitable" | sed -e '/^[%@]/! {d}')
fi

if [ -z "$suitable" ]
then
    if [ $interactive = 1 ]
    then
        echo "No program found for extension '.$ext'"
    else
        notify-send "No program found for extension '.$ext'"
    fi
    exit 1
elif [ -n "$number" ]
then
    if [ $(echo "$suitable" | wc -l) -lt "$number" ]
    then
        if [ $interactive = 1 ]
        then
            echo "Invalid number: '$number' (Not enough options)"
        else
            notify-send "Invalid number: '$number' (Not enough options)"
        fi
        exit 1
    fi
fi

if [ $(echo "$suitable" | grep -e "^ *$delim$delim") ]
then
    if [ "$explicitmode" = 0 ]
    then
        mode="manual"
    fi
fi

namelist=$(echo "$suitable" | cut -d "$delim" -f 1 | tr -s ' ')
if [ "$mode" = "auto" ]
then 
    if [ -z "$number" ]
    then
        number=1
    fi
    command=$(echo "$suitable" | sed -n "$number"p | cut -d "$delim" -f 2 | tr -s ' ')
elif [ "$mode" = "list" ]
then
    if [ -n "$number" ]
    then
        echo "$namelist" | cat -n | sed -n "$number"p | cut -d "$delim" -f 1
        exit 0
    else
        echo "$namelist" | cat -n
        exit 0
    fi
elif [ "$mode" = "manual" ]
then
    if [ $(echo "$namelist" | wc -l) -gt 1 ]
    then
        selection=$(echo "$namelist" | eval $menu -p "Program:")
        if [ -z "$selection" ]
        then
            exit 1
        fi
    else
        selection="$namelist"
    fi
    selectionln=$(echo "$namelist" | grep -xn "$selection" | cut -d "$delim" -f 1)
    if [ "$selectionln" ]
    then
        command=$(echo "$suitable" | sed -n "$selectionln"p | cut -d "$delim" -f 2)
    else
        command="$selection"
    fi
fi

case "$command" in
    *\"\$fn\"*) eval $command;;
    *\$fn*) command=$(echo "$command" | sed 's/\$fn/"\$fn"/g')
        eval "$command";;
    *) eval "$command \"$fn\"";;
esac

The config file looks like this:

# Format = Name:Command:Extensions
#
# Use commas to separate extensions
# Begin a name with % to make it available outside of X
# Begin a name with @ to make it available ONLY outside of X
# Begin a name with | for it to be used when stdin is redirected (implies %)

# Movies
%Mplayer             :  mplayer             :   avi,wmv,asf,mp4
%Mplayer (Fullscreen):  mplayer -fs         :   avi,wmv,asf,mp4
VLC                  :  vlc                 :   avi,wmv,asf,mp4

# Music
%Mplayer             :  mplayer             :   mp3,ogg,flac,wav
%Mp3blaster          :  mp3blaster          :   mp3,ogg
%Aplay               :  aplay               :   wav

# Images
Viewnior             :  viewnior            :   jpg,png
Gimp                 :  gimp                :   jpg,png,xcf
@Fbv                 :  fbv                 :   jpg,png

# Text
Gvim                 :  gvim                :   txt,conf,c,py
@Vim                 :  vim                 :   txt,conf,c,py
%GCC                 :  gcc "$fn" -o a.out  :   c

# HTML
Firefox              :  firefox             :   html
@Links               :  links               :   html

# Redirected input
|Cat                 :  cat                 :   c
|Links Dump          :  links -dump         :   html

# User input will always be required for extensions prefixed with double colons
::avi,c

@ indicates a program that will only be run when not in X.
% indicates a program that doesn't care if X is running or not
| indicates a program that will only be run if the input was originally redirected to the script, eg. "echo foo.bar | open" or "open < input.txt"
For now, these symbols appear in lists and selection menus.
As before, mimetypes aren't handled, behaviour doesn't change based on the path, and the code is a bit hacky. Tested on bash, zsh and ksh.

@hut I had a go at the item on your list where you wanted ": | open foo.bar" to behave differently to "open foo.bar". How would you do that? The only way I can think of is to check for an interactive shell, but then it flags things like gmrun and dmenu_run as non-interactive, which limits what you can do with those tools. I've included a check for whether the input was given as an argument or redirected. That way, "echo foo.html | open" can behave differently to "open foo.html". But my shell scripting skills aren't capable of anything more than that!

Last edited by mutantpineapple (2012-02-16 22:21:30)

Offline

#12 2012-02-16 23:14:23

hut
Member
From: Hanover, Germany
Registered: 2010-03-12
Posts: 569
Website

Re: File Opener

mutantpineapple wrote:

@hut I had a go at the item on your list where you wanted ": | open foo.bar" to behave differently to "open foo.bar". How would you do that? The only way I can think of is to check for an interactive shell, but then it flags things like gmrun and dmenu_run as non-interactive, which limits what you can do with those tools.

Well, that's exactly the point big_smile. If you run open foo.txt from dmenu_run, you don't want "vim foo.txt" to start because there is no terminal. Instead it should start "gvim foo.txt" or "urxvt -e vim foo.txt".

Your program is nice and fast, but I wonder if there are any ideas on how a configuration should look like that implements #5? ("Support determining file types based on multiple factors: mime type, extension, full file name and path")

I came up with this format but it looks somewhat complicated:

# syntax: <function> AND <function> ... AND <function> THEN <command>
# where <function> is one of:
#     extension <regexp>      -- matches the regexp on the file extension
#     path <regexp>           -- matches the regexp on the path
#     mimetype <regexp>       -- matches the regexp on the mimetype
#     has <program name>      -- checks if <program name> is installed
#     X                       -- checks if X runs
#     terminal                -- checks if the shell is interactive
#     description             -- specifies the description

extension x?html? AND X                     THEN firefox -- $f
extension x?html? AND terminal AND has lynx THEN lynx -- $f
extension x?html? AND terminal              THEN elinks -- $f
extension x?html?                           THEN elinks -dump -- $f

mimetype ^video AND       description "Mplayer"              THEN mplayer -- $f
mimetype ^video AND X AND description "Mplayer (Fullscreen)" THEN mplayer -fs -- $f

mimetype ^audio AND path ^/var/music        THEN mpc add $f && mpc play 1 && mpc prev
mimetype ^audio                             THEN mplayer -- $f

Notice how I'm adding a "--" to each command. This allows opening files starting with a minus sign without confusing the program and should be done in your opener too smile

Last edited by hut (2012-02-16 23:21:39)


"hut_" or "h00th00t" in irc.freenode.net #archlinux
Ranger Mailing List: https://lists.nongnu.org/mailman/listinfo/ranger-users

Offline

#13 2012-02-17 11:11:03

Wintervenom
Member
Registered: 2008-08-20
Posts: 1,011

Re: File Opener

I've been working on a local file and URL opener (written in Bash 4) this morning and [came up with with this, hot off the Vim].  Handlers can be defined by both a match of the path and/or a class, which can be the the media (MIME) types, a protocol name, or something you make up and define in a extension for.  If there's anything I can do to improve it (aside from taking a proofread and de-confuse-ifying or two when it isn't 0500 in the morning and finish commenting tongue), I am all ears.

EDIT:  Proofreading and revising done.  Still looking out for more oddities.
x2 EDIT COMBO:  Added XDG and binary launching support, too; handler behavior revised.
You'll want to recreate the configuration file if you were using a previous version (-c).

Last edited by Wintervenom (2012-02-18 04:07:05)

Offline

#14 2012-02-18 17:03:11

ninian
Member
From: United Kingdom
Registered: 2008-02-24
Posts: 726
Website

Re: File Opener

Hmm.. some interesting points and different approaches/ideas arising in this thread.
I decided that using the XDG standards was sensible (rather than using specific extensions, etc), and my Exec script is based on these. Basically, in filemanagers etc, 'Exec' can replace 'Open' and 'Exec -a' can replace 'Open with..'.
wink

Offline

#15 2013-02-14 09:41:53

chickenPie4tea
Member
Registered: 2012-08-21
Posts: 309

Re: File Opener

ninian wrote:

Hmm.. some interesting points and different approaches/ideas arising in this thread.
I decided that using the XDG standards was sensible (rather than using specific extensions, etc), and my Exec script is based on these. Basically, in filemanagers etc, 'Exec' can replace 'Open' and 'Exec -a' can replace 'Open with..'.
wink

The link to your Exec is dead for me smile


You can like linux without becoming a fanatic!

Offline

#16 2013-02-14 11:14:33

ninian
Member
From: United Kingdom
Registered: 2008-02-24
Posts: 726
Website

Re: File Opener

chickenPie4tea wrote:

The link to your Exec is dead for me smile

Webpages updated over the last year so links changed. Exec still available but have a look at the more advanced expro instead (also has AUR package).
wink

Offline

Board footer

Powered by FluxBB