tag 640272 - patch kthxbye Hi Luca,
Luca Capello wrote: > Mixing the reply I was writing after all my tests, something is probably > useless now, but it was already written. :-) > Here a simple patch, but read below: > > --8<---------------cut here---------------start------------->8--- > --- /usr/bin/conkeror.ORG 2011-07-19 23:13:31.000000000 +0200 > +++ /usr/bin/conkeror 2011-09-04 17:43:37.255077737 +0200 > @@ -34,5 +34,21 @@ > errormsg="`exec $XULRUNNER /usr/share/conkeror/application.ini \"$@\" > 2>&1`" > echo "$errormsg" | sed -e "s:/[^ ]*/xulrunner-bin:$0:; > /-\(width\|height\)/d" 1>&2 > else > - exec $XULRUNNER /usr/share/conkeror/application.ini "$@" > + # loading local file from CLI as w3m/iceweasel > + # <http://bugs.debian.org/640272> > + COMMAND="$XULRUNNER /usr/share/conkeror/application.ini" > + for I in $@; do This needs to be "$@" instead of just $@ (without quotes) to work properly with blanks in parameters. > + # check if the argument is not actually an option > + I_FIRSTCHAR=$(echo "$I" | cut -c 1) > + # check if it is a full URL or not > + I_FULLURL=$(echo "$I" | grep "://") > + if [ "$I_FIRTSCHAR" != - ] && [ ! "$I_FULLURL" ]; then > + # check if it is a relative or absolute path > + if [ "$I_FIRSTCHAR" != / ]; then > + I="$PWD/$I" > + fi > + fi This does not check if a file actually exists. So "conkeror www.google.com" would no more work (but IIRC works with common browsers). > + COMMAND="$COMMAND $I" This will probably also fail with parameters with blanks in it. Due to these three issues (and not having an obvious solution for the last one), I don't consider the patch mature enough, hence the untagging. > + eval "$COMMAND" Is eval really needed here? Wouldn't exec work, too, as in the original script? > NB1, with this patch --help *after* the URL is not anymore recognized > (see #640321), I still fail to understand why :-( Can't tell either... Strange. > NB2, while the Debian Policy allows `test -a/-o` (ยง 10.4), I find that > the other notation is easier to read and it is spotted by > checkbashisms, feel free to change it to be consistent with line 9 Both are fine for me. > > 17:09:26 <retroj:#conkeror> there is a strong reason for not directly > > supporting relative paths, which i have > > documented at various times when this > > question has come up before > > 17:09:52 <XTaran:#conkeror> retroj: Hrm, I think, I have to read them, > > but I suspect, I will disagree. :) > > 17:10:10 <XTaran:#conkeror> retroj: It's definitely a violation of the > > rule of least surprise... > > 17:10:21 <retroj:#conkeror> what conkeror supports that iceweasel etc > > do not is that you can open any url or > > webjump from the command line. supporting > > relative paths introduces ambiguity into > > the system > > Deviating from standard (and old common) behavior is even worse. Well, did conkeror ever work that way? > > 17:12:54 <retroj:#conkeror> it would mean that if you have a file > > called "google" in your home directory, > > you could not use the google webjump from > > the command line > > 17:13:31 <retroj:#conkeror> the solution i'm planning to implement in > > decoupling branch is to add a command line > > flag that allows opening relative file > > paths > > It should be the other way around, i.e. a flag for webjumps. Yeah, I thought about that too, but haven't come to a conclusion yet. > > 17:23:53 <retroj:#conkeror> we have to deal with web addresses, dns > > resolution, and webjumps > > No, a browser has to deal with URLs, full stop. I think he meant that differently. IMHO it was an explanation for this, nothing more: 17:23:30 <retroj:#conkeror> haha, that's a fairly myopic comparison. conkeror is more complex. I.e. conkeror is more complex than emacs because it has to deal withweb addresses, dns resolution, and webjumps; not just with files. > Bingo! Unfortunately, the above still does not work for local files: > > $ /usr/bin/conkeror src/Debian/webwml/english/events/index.en.html > -> <http://www.src.com/Debian/webwml/english/events/index.en.html> > > It seems the only option would have been to implement that in the shell > script as per the patch above. But given all my tests I still think the > problem should be fixed in conkeror upstream, instead, given that > full-path files are opened correctly. Upstream disagrees, thus feel > free to tag it as wontfix and close it. My plan is to play around with url_remoting_fn as suggested by upstream and document that in the bug report as well as in README.Debian. Maybe I'll even let the wrapper script emit a warning based on your patch. It should suffice for that. :-) Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
