0

I have a function in a bash script (openWebPage) which I want to open a web page and navigate to an id tag within the page.

The url components are held in variables

PIXPAGE="/home/bu5hman/pix/pixpages/media.bu5hman.2005-.video.htm"
TT="tt0078435"

The call to the function composes the variables

openWebPage "$PIXPAGE#$TT"

Within the function, if I hard code the call to my default browser (seamonkey) directly with a file url which has a tag specified

/home/bu5hman/Installs/seamonkey/seamonkey "file://$1"

the page opens at the required tag, however using

xdg-open "file://$1"

opens the web page at the top but does not navigate to the tag within the page.

When the browser is called directly it opens with the full url and tag in the navigation bar, but when called using xgd-open it opens with the url stripped of the tag (#tt0078435) in the navigation bar.

It appears that xdg-open strips the tag from the url before passing it to the application.

Aside from using a script to interrogate the system for the default browser and composing a direct call, is there a way to either prevent xdg-open from stripping the tag or an alternative cross platform call to open the web page at the tag?

  • Did you forget to quote somewhere? A hash in bash starts a comment. – Ignacio Vazquez-Abrams Nov 16 '17 at 15:12
  • i have tried escaping (\#) to no joy. if I promote to single quotes then the expansion of the variables doesn't happen and the call fails. The point is that the passed url works perfectly when i call it directly from the script with the double quotes but if I use xdg-open the #tt12345678 component is lost. If xdg-open parses a url then my question question remains ..... can I stop it parsing the argument? – bu5hman Nov 16 '17 at 15:18
  • Can't duplicate. xdg-open "http://example.com/#123" works exactly as expected. – Ignacio Vazquez-Abrams Nov 16 '17 at 15:19
  • Is the tag in the url in your navigation bar? – bu5hman Nov 16 '17 at 15:21
  • It does show there. – Ignacio Vazquez-Abrams Nov 16 '17 at 15:26
1

Solution found thanks to pointers from @Ignacio Vazquez-Abrams.

The issue was actually in the way xdg-open passes an argument to the default application.

If the default application is registered in kde desktop so as to expect a url (%u)

/home/bu5hman/Installs/seamonkey/seamonkey %u

then the whole argument passed to xdg-open is used as a url and the browser navigates to the tag.

if the %u is omitted then the argument passed to xdg-open is tested to see if it is a file and then stripped of information from the # in the url (from the xdg-open script)

# If argument is a file URL, convert it to a (percent-decoded) path.
# If not, leave it as it is.
file_url_to_path()
{
    local file="$1"
    if echo "$file" | grep -q '^file:///'; then
        file=${file#file://}
        file=${file%%#*}                                #<----------
        file=$(echo "$file" | sed -r 's/\?.*$//')
        local printf=printf
        if [ -x /usr/bin/printf ]; then
            printf=/usr/bin/printf
        fi
        file=$($printf "$(echo "$file" | sed -e 's@%\([a-f0-9A-F]\{2\}\)@\\x\1@g')")
    fi
    echo "$file"
}

and the page is only opened at the top.

In my case firefox had been registered with %u and seamonkey without, which is why I had different behaviour in the two browsers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.