1

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?

Improve this question
10
  • Did you forget to quote somewhere? A hash in bash starts a comment. Commented Nov 16, 2017 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? Commented Nov 16, 2017 at 15:18
  • Can't duplicate. xdg-open "http://example.com/#123" works exactly as expected. Commented Nov 16, 2017 at 15:19
  • Is the tag in the url in your navigation bar? Commented Nov 16, 2017 at 15:21
  • It does show there. Commented Nov 16, 2017 at 15:26

1 Answer 1

Reset to default
3

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.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.