Re: ITP: rxvt-W

["Charles Wilson" <cygwin at cwilson dot fastmail dot fm>]

(Sorry about the broken thread; webmail sux)

Corinna sez:
> On Mar 21 10:13, Igor Peshansky wrote:
> > On Tue, 21 Mar 2006, Corinna Vinschen wrote:
> > > ...how do you plan to replace the old rxvt functionality from the user's
> > > perspective?  This I don't see in your description.  So far the user can
> > > call just "rxvt" and gets what the DISPLAY variable suggests.  With
> > > rxvt-unicode you will get two binaries which can't (or rather,
> > > shouldn't) use the same name.  Will "rxvt" in the long term be the X11
> > > version or the W11 version?  Or will rxvt become a wrapper script
> > > calling the "right" version depending on the DISPLAY setting to maintain
> > > the current usability?
> > 
> > That shouldn't be hard.  The current rxvt is pretty simple-minded about
> > when it uses native mode.  In particular, it tests for $DISPLAY (or the
> > -display argument) being empty or exactly ":0", and runs in native mode,
> > otherwise it tries to connect to an X server on that display.  This could
> > be easily implemented in a wrapper script that parses the options and the
> > value of $DISPLAY and exec's rxvt-unicode-W or rxvt-unicode-X.
> 
> Yeah, the technical details aren't on the overly tricky side, I'm just
> asking Charles how he is planning to do it.

As you guessed, a .bat batch script 'urxvt.bat' and a #! shell script
'urxvt' included in rxvt-unicode-common.  I had given it some thought;
it's actually not as simple as ya'll make it sound -- especially if we
want "just like current rxvt.exe" behavior.  Exposition follows.

The batch script would be useful as a symlink target, since the exec'ed
programs would be able to hide the console window created when Windows
executes the .bat.  The shell script would be useful from an existing
interactive shell -- and as there is no additional console in that case
the console-hiding code has no effect and causes no trouble.  Eventually
those names could be migrated to 'rxvt.bat' and 'rxvt'.

I have one concern with that plan, tho: Would the transparent_exe logic
ALSO extend to other PATHEXT extensions?  Does 'foo' conflict with
'foo.bat' (and foo.com, foo.vbs, foo.cmd, foo.wsh, ...) or ONLY with
'foo.exe'?  If so, this is easy to work around but not user-transparent:
the scripts would be 'urxvt.bat' and 'urxvt.sh', and the user would need
to 'alias urxvt urxvt.sh'  (Obviously these same concerns would need
revisiting if the wrappers were eventually renamed to 'rxvt.bat' and
'rxvt[.sh]' -- since the user may still have the current rxvt.exe
installed).  Similar, but slightly different, discussions are possible
concerning urxvtc-X and urxvtd-X.

Actually, right now I have rxvt-unicode-X using the alternatives system,
so the 'urxvt' name is already "taken" by the symlink (/usr/bin/urxvt ->
/etc/alternatives/urxvt -> /usr/bin/urxvt-X.exe).  There's only one
alternative since rxvt-unicode-W doesn't exist yet so that's kinda
useless -- and it's easy to remove the alternatives stuff in the next
iteration of the package, since the existing preremove script is already
there.

There's one other minor issue, too: the batch file (but not the #!
script) would be limited to 9 command-line parameters.  That's not a
huge deal, as most customizations should be in ~/.Xdefaults, and not
passed on the command line.  (If you need multiple flavors, just use the
'-name foo' command line option and specify 'foo*background red' or
'foo*fontname Courier' in ~/.Xdefaults.  You can have any number of
these flavors).

For compatibility, the switching logic would attempt to be identical to
the logic in the current rxvt.exe:

if $DISPLAY is empty or exactly ":0"
  exec native-hosted "$@"
else
  XserverIsAvailable=(??? some mechanism to determine if an Xserver is
  running and will host an app ???) 
  if (XserverIsAvaliable)
     exec X-hosted "$@"
  else
     exec native-hosted "$@"
  fi
fi

The "some mechanism" might just be a five-line application distributed
with rxvt-unicode-common, like:

int main() {
int rc;
Display* dpy = XOpenDisplay(NULL); /* null lets XOpenDisplay handle
querying for $DISPLAY */
rc = !(dpy == NULL);
if (dpy) XCloseDisplay(dpy);
return rc; /* exits with status of 0 if X available */
}

The downside to that is that this little app would require
xorg-x11-bin-dlls; if it were part of rxvt-unicode-common then -common
would depend on X.  Even if the end-user only wanted -common and -W
installed (in which case there's no need of a wrapper at all, but I
can't see an elegant way for the wrapper to fail "gracefully" if
cygX11-6.dll is missing.  Maybe I can avoid the problem by (a) hiding
X-test-app somewhere so end-users won't be tempted to use it, (b)
deliberately NOT require: xorg-x11-bin-dlls in the -common setup.hint,
and (c) use some kludge like this in the wrapper:

if cygcheck -cd | grep xorg-x11-bin-dlls >/dev/null 2>&1 ; then
  if $DISPLAY is empty or exactly ":0"
    exec native-hosted "$@"
  else
    /private/path/to/X-test-app >dev/null 2>&1
    XserverIsAvailable=$?
    if (XserverIsAvailable)
      exec X-hosted "$@"
    else
      exec native-hosted "$@"
    fi
  fi
else
  # X not even installed. Always native.
  exec native-hosted "$@"
fi

I'd also need to fiddle with PATH just-in-case /usr/X11R6/bin isn't in
the system PATH, before running X-test-app or X-hosted, but those are
refinements.  Doing all this in a .bat file will be...interesting.

Just had another thought: instead of the five-line app above, I could
steal a page from current rxvt, and dlopen(cygX11-[6,7,8,9].dll), dlsym
ONLY XOpenDisplay and XCloseDisplay, and THEN do the five lines.  Then
my app really wouldn't explicitly depend on xorg-x11-bin-dlls, AND I'd
avoid needing to call grep and cygcheck from a .bat file, (do pipes work
.bat files?), AND I wouldn't need to "hide" X-test-app.

--
Chuck
--
  Charles Wilson
  cygwin at removespam cwilson dot fastmail dot fm