Re: run-1.3.3-1: Unicode text and empty args

[Achim Gratz <Stromeko at nexgo dot de>]

Martin Anantharaman writes:
> I have been trying to use run (current version 1.3.3-1) to launch
> emacsclient-w32 from the desktop via SendTo without having a console-window
> pop up. It does work, but I have found two problems that prevent this from
> working in certain cases:
> 1) Unicode text arguments: If I pass arguments to run with non-ANSI text
> (German Umlaute in my case), they arrive at the called program (in my case
> emacsclient-w32) garbled.

As you found out, run isn't designed to do that.  Even with your
changes, I'm not sure it does the right thing: I think that Windows
might deliver those strings according to the current codepage and not
UTF-8.  For german umlauts that happens to be the same codepoint, but
for other languages it might not be.

> 2) Empty args: There ARE cases where we want to do this, e.g. pass the -a ""
> option to emacsclient, but this does not work even with the --quote option
> to run - the empty arg is silently "swallowed".

Yes, but that's easily fixable.  I guess run shouldn't care if the
application deals correctly with that.

> The changes I propose are contained in the attachment 3, which was created
> by running "cygport run package" (after modification and compilation, of
> course). Apart from fixing the 2 problems above I also updated the man-page,
> borrowing from the run2 man-page. I did not touch NEWS, ChangeLog, etc.
> though. I hope this change can be adopted by the kind maintainers:-)

Thanks for the patches, I'll have a closer look later.

> My testing showed some other issues I do not consider urgent, but are worth
> mentioning:
> 1) run DOES handle symlinks, but only if one passes the program-name with an
> absolute path or the symlink has a name with the right suffix (e.g. .exe) -
> which unfortunately is not the case with the symlinks provided (e.g. for
> emacs and emacsclient) via the alternatives system. This would require
> fixing the symlinks in packages using alternatives - or fixing run to
> process the program-name in the same way as the spawn/exec family of
> functions.

That problem of some programs looking for an explicit .exe suffix shows
up in some other places, too.  So I'd think the fix should be applied to
the alternatives system independently of whether or not run tries to
work around it.

> 2) run does not execute scripts as of now - on the other hand since the
> exec/spawn functions do so, it should in principle be possible to layer run
> on an extended form of those functions. That would really simplify creating
> desktop-shortcuts by placing all complexity in a shell-script and using the
> runprogram mechanism to call it - rather than packing a complex command-line
> (typically using bash) into the shortcut.

PTC.  You could also check if the wrapper script that Andrey Repin
posted some time ago does what you want.


In any case, if Chuck Wilson was still with us he'd probably tell you
that these things were supposed to be implemented in run2 and that run
should be retired.  I'll certainly fix bugs in run where possible, but
I'd rather avoid adding on functionality that it wasn't designed for.
So please consider getting run2 up to speed instead and become the
maintainer.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple