jonbakke / boredserf

Fork of surf; minimalist WebKitGTK web browser.
MIT License
2 stars 0 forks source link

Suggestion: 'protocol://' insertion if not in marks and open-boredserf.sh extension #5

Open communistkiro opened 2 years ago

communistkiro commented 2 years ago

With 6c351c9631c7f66172ee07f2dbc636f7fa745610, entering a URL sans 'https?://' results in the last of my marks becoming the URI. I can fix and facilitate that via the my bsf script (below), an extension of open-surf.sh.

#!/bin/zsh
emulate -LR zsh;
xidfile=/tmp/tabbedboredserf.xid;
xid=$(<${xidfile});
uri=file:///root/.config/startpage/ss1.htm;
cd /tmp;

[[ -n ${xid} ]] && xprop -id ${xid} | grep -q tabbedboredserf || {
  tabbed -dn tabbedboredserf -c -r 2 boredserf -e '' ${uri} > ${xidfile} &;
  wait;
  xid=$(<${xidfile});
};

for uri ( ${@} ) {
  if     [[ ${(M)uri#?} == / && -r ${uri} ]] {
    uri=file://${uri};
  } elif [[ -r ${OLDPWD}/${uri} ]] {
    uri=file://${OLDPWD}/${uri};
 #} elif [[ ${uri} == *\ * ]] {
 #  q=${uri%%[[:space:]]*};
 #  for w ( ${(f)"$(<~/.config/surfraw/cache)"} ) { [[ ${w} == ${q} ]] && break } &&
 #    uri=$(surfraw -p -- ${q} ${uri#*[[:space:]]})
  } elif { q=${uri%%[[:space:]]*}; for w ( ${${(f)"$(<~/.config/boredserf/marks | cut -d: -f2)"}%\?} ) { [[ ${q} == ${w} ]] && break } } {
  } else {
    [[ ${uri} == http(|s)://* ]] || uri=https://${uri};
  };
  boredserf -e ${xid} ${uri} &;
};
wait;
cd ${OLDPWD};

This should be possible albeit more clunky or verbose with dash only, the first if hopes one's given an absolute path rather than an identically named file in /tmp. I cannot get it to work, if you can, or know somebody who could, this would be an upgrade.

#!/bin/sh
xidfile=/tmp/tabbedboredserf.xid;
[ -f ${xidfile} ] && xid=$(cat ${xidfile}) || xid=;
uri=file:///root/.config/startpage/ss1.htm;
cd /tmp;
[ -n ${xid} ] && xprop -id ${xid} | grep -q tabbedboredserf || {
  tabbed -dn tabbedboredserf -c -r 2 boredserf -e '' "${uri}" > ${xidfile} &
  wait;
  disown;
  xid=$(cat ${xidfile});
};

set -x
for uri in "${@}"; do
#1
  if   [ -r "${uri}" ]; then
    uri=file://"${uri}";
  elif [ -r "${OLDPWD}/${uri"} ]; then
    uri=file://"${OLDPWD}/${uri}";
  elif q="${uri%%[[:space:]]*}" && for w in "${$(cat ~/.config/boredserf/marks | cut -d: -f2 | tr -d \?)}"; do [ "${q}" == "${w}" ] && break; done; then
    true;
  else then
    echo "${uri"} | grep -Eq '^https?://' || uri=https://"${uri}";
  fi;
#2
  [ -r "${uri}" ] && uri=file://"${uri}" ||
  [ -r "${OLDPWD}/${uri"} ] && uri=file://"${OLDPWD}/${uri}" ||
  q="${uri%%[[:space:]]*}" && for w in "${$(cat ~/.config/boredserf/marks | cut -d: -f2 | tr -d \?)}"; do [ "${q}" == "${w}" ] && break; done ||
  echo "${uri"} | grep -Eq '^https?://' || uri=https://"${uri}";
  boredserf -e ${xid} "${uri}" &
done;
wait;
disown;
cd "${OLDPWD}";
jonbakke commented 2 years ago

At a quick glance, it looks like those scripts test if the given input is a filename, then test if it matches a mark, and if it fails those a 'https' scheme is prepended. Ah, and it looks for surfraw targets.

The current behavior is to look for common schemes (https, http, file ... maybe a few others), otherwise to treat the input as a possible mark, and if it doesn't match a mark then it should be given a 'http://'. Not a solution I like much, either.

Functionally, it looks like you want (1) better testing for local files and (2) a configurable fallback scheme. Is that about right? Those both sound good to me. I think I can get them done sooner than the rest of my boredboard interface, and they'll be reused there so it won't just be an interim tool.

communistkiro commented 2 years ago

Somehow my surf config had gotten to a point of not being able to open local files, it just downloaded them to pwd, which is also which I change to /tmp before starting either surf or boredserf up. This was fixed the the second or third contentfilter diff file (could've'n a mistake on my part in copy-pasting chunks or hunks since git apply didn't work).

Regarding functionally,

  1. both surf and boredserf currently open directories and (plain text) files with the file:// prepended, so that's my blunder; that and if the files exists in pwd, it opens it, as I've just tested even without the file:///path/to/file;
  2. application layer protocols abound, but save the rare ftp, or gopher with its dying down hype---how often does anything else get used to not have http as a fallback?
  3. thing the script does is allow multiple tabs to be opened in the same tabbed instance: script 'wikipedia duck' 'wiktionary hello' 'archlinux window manager' ./local/file I do always have it open on a self-made homepage with a few links. To anybody with a keybound dmenu_run from dmenu, this would substitute n tab openings, go prompt spawns, and enters for n pairs of quotes (or escapes seqeunces), n-1 spaces, and 1 enter.

If you can later use it, all the better.

jonbakke commented 2 years ago

re 1: I've had local files not open as expected ... it works sometimes, just not reliably.

re 2: the main question is https vs http. I strongly believe that all web traffic should be https these days, but requiring it still breaks many sites, and that should be transparent to the user save some passive notification that the connection is not encrypted. Hm. If I recall, there is a WebKit function to "upgrade to https if possible"... I should see if I can find that, and if that does what I think it should. And, along with the http/https question, I doubt http(s) will remain dominant forever, which is an example of why hard-coding these values is just lazy.

re 3: You've hit two issues here, I think. First: tabs. I think tabs should be handled by the window manager; that's why I use sway/i3 rather than dwm. I'm happy to try to keep boredserf working with tabbed, but it isn't something I use ... so please do open issues if I break it. Second: opening multiple pages with multiple command-line arguments. I think the reason this doesn't work is the arg.h argument parsing used by surf/boredserf. It is neat, compact, and utterly unmaintainable code, not that the standard methods are much better (being, from what I've seen: sprawling, antiquated, and utterly unmaintainable). But that does deserve an issue so I won't forget about it again. And I could be entirely wrong in blaming arg.h.

By the way, in the /bin/sh version, there are several instances of "${uri"} that should probably be "${uri}". The curly braces just distinguish the variable name from surrounding text, so if test="hello ", you could echo ${test}world, whereas echo $testworld would only print a blank line because it couldn't find the variable $testworld. The quotes are there to maintain differences between arguments ("words" in shell lingo) -- usually, to allow spaces within arguments without them being broken up into multiple arguments. So, pairs of curly braces around variables should always be inside a given pair of quotes.

communistkiro commented 2 years ago

In Firefox at least, the URI bar sports a 'hey, this page inside secure'-tool-tipped red X, if I recall correctly. Surf already disallows pages with improper certificates from loading via strict TLS. Testing somehow if a URL doesn't render properly would be helpful, and if it were possible add in an indicator after the 'T' (for strict TLS) to signify https or a dash for http. And if that is not so easy, perhaps an https/http toggle (maybe the letter 'S' should be for 'SSL' rather than (java)script, which 'J' should signify)?

My bad in assuming everybody would be using tabbed, or any of the other suckless programs. And the dash is so annoyingly bad at everything, I tapped out after 1.5h. My script handles multiple arguments fine; opening up multiple boredserfs from the boredboard presently worked on, may seem unintuitive or unnecessary, and calling the script isn't that much of a hassle; I can't comment upon arg.h, it looks arcane.