Subject: changes to fvwm that have not been included in 2.4.5 for unknown reasons

From: Alexander Kotelnikov <[email-masked]>
Date: Mon, 28 Jan 2002 19:29:19 +0300

Hello

--- fvwm/read.c.orig	Tue Jan  8 02:47:05 2002
+++ fvwm/read.c	Tue Jan  8 02:52:40 2002
@@ -140,8 +140,15 @@
       tline[l - 1] = '\0';
 
     if (debugging)
+/* [email-masked] 
+   tline is null  terminated anyway and contains no new-lines 
+ */
+/*
       fvwm_msg(DBG,"ReadSubFunc","Module switch %d, about to exec: '%.*s'",
 	       Module,strlen(tline)-1,tline);
+*/
+      fvwm_msg(DBG,"ReadSubFunc","Module switch %d, about to exec: '%s'",
+	       Module, tline);
 
     old_execute_function(tline, tmp_win, eventp, context, Module, 0, NULL);
     tline = fgets(line, (sizeof line) - 1, f);
or "have you ever run fvwm with -debug?"

--- fvwm/builtins.c.orig	Sun Jan 13 02:04:00 2002
+++ fvwm/builtins.c	Sun Jan 13 04:00:43 2002
@@ -782,6 +782,11 @@
   /* Not everyone has vfork! */
   if (!(fork())) /* child process */
   {
+    if ( setpgrp() == -1 )
+    {
+      fvwm_msg(ERR,"exec_function","setpgrp failed (%s)",strerror(errno));
+      exit(100);
+    }
     if (execl(exec_shell_name, exec_shell_name, "-c", cmd, NULL)==-1)
     {
       fvwm_msg(ERR,"exec_function","execl failed (%s)",strerror(errno));

And two more I've never wrote here:
--- libs/GetFont.c.orig	Tue Dec  5 18:22:40 2000
+++ libs/GetFont.c	Mon Jan 28 10:59:50 2002
@@ -59,38 +59,44 @@
   XFontSet fontset = NULL;
   char **ml;
   int mc;
+  int i;
   char *ds;
 
   if (fontname)
-    fontset = XCreateFontSet(disp,fontname,&ml,&mc,&ds);
-  if (!fontset && fontname)
-  {
-    fprintf(stderr,
+    if (!strcmp("fixed",fontname))
+      fontset = XCreateFontSet(disp,fontname,&ml,&mc,&ds);
+
+  else{
+     fprintf(stderr,
             "[FVWM][GetFontSetOrFixed]: "
-	    "WARNING -- can't get fontset %s, trying 'fixed'\n",
-            fontname);
+	    "WARNING -- fontname is a NULL-string\n");
   }
   if (!fontset)
   {
+    fprintf(stderr,
+            "[FVWM][GetFontSetOrFixed]: "
+	    "WARNING -- can't get fontset '%s', trying '-*-fixed-medium-r-normal-*-14-*-*-*-*-*-*-*'\n",
+            fontname);
     /* fixed should always be avail, so try that */
-#ifdef STRICTLY_FIXED
-    if ((fontset = XCreateFontSet(disp,"fixed",&ml,&mc,&ds))==NULL)
-    {
-      fprintf(stderr,
-	      "[FVWM][GetFontSetOrFixed]: "
-	      "ERROR -- can't get fontset 'fixed'\n");
-    }
-#else
-    /* Yes, you say it's not a *FIXED* font, but it helps you. */
     if ((fontset =
 	 XCreateFontSet(disp,
 			"-*-fixed-medium-r-normal-*-14-*-*-*-*-*-*-*",
 			&ml, &mc, &ds)) == NULL)
     {
       fprintf(stderr,"[FVWM][GetFontSetOrFixed]: "
-	      "ERROR -- can't get fontset 'fixed'\n");
+	      "ERROR -- can't get fontset '-*-fixed-medium-r-normal-*-14-*-*-*-*-*-*-*'\n");
+    }
+  }
+  if (fontset){
+    if (mc > 0) {
+      (void)fprintf(stderr, 
+		    "[FVWM][GetFontSetOrFixed][%s]:"
+		    "The following charsets are missing:\n", fontname);
+      for(i=0; i < mc; i++)
+	fprintf(stderr, " %s", ml[i]);
+      fprintf(stderr, "\n");
+      XFreeStringList(ml);
     }
-#endif
   }
 
   return fontset;
>From its manual page: "Clients should always call XSetLocaleModifiers
with a non-NULL modifier_list after setting the locale before they
call any locale-dependent Xlib routine.

And, please, add 
#! /usr/bin/perl
to utils/fvwm24_convert.in

Thanks for you attention,
-- 
Alexander Kotelnikov
Saint-Petersburg, Russia

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 29 Jan 2002 00:33:33 +0100

> Hello

Content-Description: XSetLocaleModifier should be called on fvwm init in I18N_MB is defined

> call any locale-dependent Xlib routine.

Yes, I will "apply" this patch to 2.5.1 (note that the attached patch
does not concern XSetLocaleModifier, but I will do it).
If you have any plan on the I18N_MB fvwm code say it as I plan to
start to rewrite it next week.

Regards, Olivier
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 28 Jan 2002 22:56:54 +0100

On Mon, Jan 28, 2002 at 07:29:19PM +0300, Alexander Kotelnikov wrote:

> Content-Description: patch to make fvwm survive with SIGTTIN
> (and actually other signals form exec'ed programs)

Wasn't there a portability issue with setpgrp?  I'm willing to
commit a patch if it's clear that it compiles on any platform.

> call any locale-dependent Xlib routine.

Somebody else should commit this patch.  I don't know enough about
internationalisation under X to judge it.
 
> to utils/fvwm24_convert.in

But that would break the script for installations that don't have
perl in /usr/bin.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Mon, 28 Jan 2002 19:46:46 -0500

Dominik Vogt <[email-masked]> writes:
> > (and actually other signals from exec'ed programs)
> 

I think there is.
There are autoconf macros for setpgrp but I really don't understand
how to use them.

> But that would break the script for installations that don't have

I agree.  Whats wrong with the self bootstrapping code thats in there
now, as long as perl is in your path, it should work.

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Alexander Kotelnikov <[email-masked]>
Date: Tue, 29 Jan 2002 07:07:33 +0300

>>>>> On Mon, 28 Jan 2002 19:46:46 -0500
>>>>> "Dan" == Dan Espen <[email-masked]> wrote:
Dan> 
>> But that would break the script for installations that don't have
Dan> 
Dan> I agree.  Whats wrong with the self bootstrapping code thats in there
Dan> now, as long as perl is in your path, it should work.

Really?

7:03 pts/13 sacha@pale:/var/tmp/fvwm_cvs/utils 12> gmake DESTDIR=/tmp/fvwm_inst/ install
7:03 pts/13 sacha@pale:/var/tmp/fvwm_cvs/utils 13> head -n 1 /tmp/fvwm_inst/usr/X11R6/bin/fvwm24_convert
# -*-perl-*-
7:03 pts/13 sacha@pale:/var/tmp/fvwm_cvs/utils 14> which perl
/usr/bin/perl

---

From: Alexander Kotelnikov <[email-masked]>
Date: Tue, 29 Jan 2002 07:12:07 +0300

>>>>> On Tue, 29 Jan 2002 00:33:33 +0100
>>>>> "Olivier" == Olivier Chapuis <[email-masked]> wrote:
Olivier> 
Olivier> If you have any plan on the I18N_MB fvwm code say it as I plan to
Olivier> start to rewrite it next week.

I have already wrote that I am going to remove font field form
FvwmFont when I18N_MB is defiend. I have some problems doing this, but
I hope I will complete this up to Monday (at least in libs/ and
fvwm/).

---

From: Dan Espen <[email-masked]>
Date: Tue, 29 Jan 2002 00:03:12 -0500

> sr/X11R6/bin/fvwm24_convert

That line is in the file in order to make emacs go into perl mode.

---

From: Alexander Kotelnikov <[email-masked]>
Date: Tue, 29 Jan 2002 08:12:23 +0300

>>>>> On Tue, 29 Jan 2002 00:03:12 -0500
Dan> 
Dan> 
Dan> 
>> sr/X11R6/bin/fvwm24_convert
Dan> 
Dan> That line is in the file in order to make emacs go into perl mode.

This line is the firts in /usr/X11R6/bin/fvwm24_convert after
installation even if I have /usr/bin/perl.

---

From: Dan Espen <[email-masked]>
Date: Tue, 29 Jan 2002 08:04:57 -0500

> >> >> > to utils/fvwm24_convert.in
...
> This line is the first in /usr/X11R6/bin/fvwm24_convert after

It is supposed to be the first line.

It is not there to invoke perl.

It is an emacs mode line.

When emacs sees a line containing "-*-" modename "-*-" as the first line,
emacs opens the file using that mode.

---

From: Alexander Kotelnikov <[email-masked]>
Date: Tue, 29 Jan 2002 17:18:26 +0300

>>>>> On Tue, 29 Jan 2002 08:04:57 -0500
Dan> 
>> >> >> > to utils/fvwm24_convert.in
Dan> ...
Dan> 
>> installation even if I have /usr/bin/perl.
Dan> 
Dan> It is supposed to be the first line.

I always thought, that it is supposed, that all scripts have
#! <interpretator>
as the first line

And it is not so even _after_ fvwm24_convert installation

I know quite well what emacs is.

Dan> It is not there to invoke perl.
Dan> 
Dan> It is an emacs mode line.
Dan> 
Dan> When emacs sees a line containing "-*-" modename "-*-" as the first line,
Dan> emacs opens the file using that mode.
Dan> 
Dan> -- 
Dan> Dan Espen
Dan> 444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Dan> Piscataway, NJ 08854                     Phone: (732) 699-5570
Dan> --
Dan> Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
Dan> To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
Dan> body of a message to [email-masked].
Dan> To report problems, send mail to [email-masked]
Dan> 
-- 
Alexander Kotelnikov
Saint-Petersburg, Russia
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Tue, 29 Jan 2002 10:05:45 -0500

> I always thought, that it is supposed, that all scripts have

In the case of Perl, it is not necessary.

The disadvantage of the "#!" line is that it contains a hard-coded
path.  On my HP-UX machine, Perl is not in /usr/bin.

In fvwm24_convert, the lines right after the first line
invoke Perl without a hard-coded path.

---

From: Tim Phipps <[email-masked]>
Date: Tue, 29 Jan 2002 15:26:18 +0000

> invoke Perl without a hard-coded path.

Since fvwm24_convert is generated from fvwm24_convert.in nobody should 
be editing fvwm24_convert. fvwm-menu-* all have the correct path to perl 
inserted by configure. Is it possible to have the Emacs mode magic in 
the .in file and still have #!<path-to-perl appear in the first line of 
the final script?

Cheers,
Tim.

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 29 Jan 2002 16:45:14 +0100

> invoke Perl without a hard-coded path.

Dan,

Why do not use #!@PERL@ as with the other perl scripts?
At least my emacs recognize this. Your do not?

Olivier

---

From: Dan Espen <[email-masked]>
Date: Tue, 29 Jan 2002 10:47:09 -0500

> the .in file and still have #!<path-to-perl appear in the first line of 

Its nice to be in perl mode, even when you are just looking.

Why put #!<path-to-perl into the file when its not needed?

---

From: Dan Espen <[email-masked]>
Date: Tue, 29 Jan 2002 11:19:45 -0500

> At least my emacs recognize this. Your do not?

Mine doesn't but I know how to fix it so it would.
That would still leave other users without automatic perl mode.

I don't see what the problem is, the script works fine as is.

Personally, I think the fvwm24_convert approach to bootstrapping
perl is the better way to go, since it works for any perl I write,
not just the stuff that runs through configure.  Also the location
of perl can change without having to reinstall fvwm.

I don't believe I was the one that put the perl mode line
in there in the first place.  It wasn't in version 1.1.
You can change it if you want, as long as the path isn't
hard-coded.

---

From: "Paul Smith"<[email-masked]>
Date: 29 Jan 2002 12:03:00 -0500

%% Alexander Kotelnikov <[email-masked]> writes:

  ak> I always thought, that it is supposed, that all scripts have
  ak> #! <interpretator>
  ak> as the first line

It's a good idea, but not necessary.  If there is no known magic value
at the beginning of the file then the kernel just gives it to /bin/sh.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]> HASMAT--HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 29 Jan 2002 17:13:22 +0000

> That would still leave other users without automatic perl mode.

If they edit the actual script with /hard/coded/path/to/perl and not the
.in file, there is a perl mode automatically.

> I don't see what the problem is, the script works fine as is.

Fully agree. There are no problems. Hovewer consider these 2 points:

  * it is easier/more standard to add one line to configure so it
    generates a script from .in than to generate it ourselves
  * the script itself looks nicer without a bootsrtapping code

> of perl can change without having to reinstall fvwm.

Well, the following is even better if we want the first perl in $PATH:

  #!/usr/bin/env perl

> You can change it if you want, as long as the path isn't

Having hard-coded path is good, not bad, this ensures everything will
work as tested on instalation stage. Having to reinstall after some
required part is changed is good too using the same reason.

And you may always run a script like:

  /any/other/perl a_script

or even

  perl a_script

Regards,
Mikhael.

---

From: "Paul Smith"<[email-masked]>
Date: 29 Jan 2002 13:14:42 -0500

%% Mikhael Goikhman <[email-masked]> writes:

  mg> Well, the following is even better if we want the first perl in $PATH:

  mg>   #!/usr/bin/env perl

Unfortunately you can't rely on env always being in /usr/bin.  There
most assuredly are systems where it isn't.

Catch-22.

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 29 Jan 2002 18:19:17 +0000

> most assuredly are systems where it isn't.

configure would do it for such rare systems. This was not my point.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 29 Jan 2002 21:21:34 +0100

> There are autoconf macros for setpgrp but I really don't understand

Well, the info page on autoconf says:

 - Macro: AC_FUNC_SETPGRP
     If `setpgrp' takes no argument (the POSIX.1 version), define
     `SETPGRP_VOID'.  Otherwise, it is the BSD version, which takes two
     process ID as arguments.  This macro does not check whether
     `setpgrp' exists at all; if you need to work in that situation,
     first call `AC_CHECK_FUNC' for `setpgrp'.

And the setpgrp man page:

  int setpgrp(void);

  ...

  In  the  Linux  DLL  4.4.1  library,  setpgrp simply calls
  setpgid(0,0).

So it seems clear to me what to do:

If setpgid is present, use

  setpgid(0, 0);

If setpgrp is present and has no parameters use

  setpgrp();

If setpgrp is present and has two parameters, use

  setpgrp(0, 0);

Actually, I'm guessing that setpgrp with 2 parameters takes the
same arguments as setpgid.  I don't have any documentation about
that version.  Can anybody help me out here?

I've written the necessary configure.in stuff and a replacement
fvwm_setpgrp in libs/setpgrp.[ch].  I'll apply the patch using
that new function.

Bye

Dominik ^_^  ^_^

---

From: Alexander Kotelnikov <[email-masked]>
Date: Wed, 30 Jan 2002 00:05:59 +0300

>>>>> On 29 Jan 2002 12:03:00 -0500
>>>>> "Paul" == Paul Smith <Paul> wrote:
Paul> 
Paul> %% Alexander Kotelnikov <[email-masked]> writes:
ak> I always thought, that it is supposed, that all scripts have
ak> #! <interpretator>
ak> as the first line
Paul> 
Paul> It's a good idea, but not necessary.  If there is no known magic value
Paul> at the beginning of the file then the kernel just gives it to /bin/sh.

kernel? shell I think. Always great to get perl script passed to sh.

---

From: Alexander Kotelnikov <[email-masked]>
Date: Wed, 30 Jan 2002 00:39:19 +0300

>>>>> On Tue, 29 Jan 2002 10:47:09 -0500
Dan> 
Dan> Why put #!<path-to-perl into the file when its not needed?

Because not putting it in is out of standards. E.g. you are not able
to call exec funcitions on this script.

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 29 Jan 2002 21:49:22 +0000

> to call exec funcitions on this script.

This is not correct. It is standard for unux kernels to pass a text
executable script to /bin/sh by default.

Regards,
Mikhael.

---

From: Alexander Kotelnikov <[email-masked]>
Date: Wed, 30 Jan 2002 01:13:09 +0300

>>>>> On Tue, 29 Jan 2002 21:49:22 +0000
>>>>> "Mikhael" == Mikhael Goikhman <[email-masked]> wrote:
Mikhael> 
Dan> 
>> to call exec funcitions on this script.
Mikhael> 
Mikhael> This is not correct. It is standard for unux kernels to pass a text
Mikhael> executable script to /bin/sh by default.

LIE. Read standards, please.

---

From: "Paul Smith"<[email-masked]>
Date: 29 Jan 2002 17:33:04 -0500

ak> kernel? shell I think.

I don't know what you mean.  It's the kernel, typically, that interprets
magic numbers (the first two bytes of a file) and invokes interpreters
if #! is given.  This happens when you run one of the exec*(2) system
calls.  I suppose sometimes it might be implemented in a userspace
wrapper for the exec() system call, but typically it's the kernel.

  ak>  Always great to get perl script passed to sh.

Yes, in this case it _is_ great.

The script is a perl script with some sh code at the top to invoke Perl,
without specifying where it is (so the shell uses $PATH to locate it).
If the script is running in Perl, that code is ignored (through some
tricky hacks).  If the script is running in sh, the code is invoked to
start Perl.

This is a _very_ common idiom for all kinds of interpreters which don't
have predefined locations (Perl, TCL, Python, etc. etc.)

---

From: "Paul Smith"<[email-masked]>
Date: 29 Jan 2002 18:19:06 -0500

Mikhael> This is not correct. It is standard for unux kernels to pass
  Mikhael> a text executable script to /bin/sh by default.

  ak> LIE. Read standards, please.

Single UNIX says:

    If the process image file is not a valid executable object, execlp()
    and execvp() use the contents of that file as standard input to a
    command interpreter conforming to system(). In this case, the
    command interpreter becomes the new process image.

I can't recall any UNIX in the last 10+ years that didn't do this.

For example, from various exec* man pages:

    If the header of a file isn't recognized (the attempted execve
    returned ENOEXEC), these functions will execute the shell with the
    path of the file as its first argument.  (If this attempt fails, no
    further searching is done.)

Or:

    If the new process file is not an executable object file, execlp()
    and execvp() use the contents of that file as standard input to the
    shell.

---

From: Alexander Kotelnikov <[email-masked]>
Date: Wed, 30 Jan 2002 10:43:44 +0300

>>>>> On 29 Jan 2002 18:19:06 -0500
Paul> 
Paul> %% Alexander Kotelnikov <[email-masked]> writes:
Mikhael> This is not correct. It is standard for unux kernels to pass
Mikhael> a text executable script to /bin/sh by default.
Paul> 
ak> LIE. Read standards, please.
Paul> 
Paul> Single UNIX says:
Paul> 
Paul>     If the process image file is not a valid executable object, execlp()
Paul>     and execvp() use the contents of that file as standard input to a
Paul>     command interpreter conforming to system(). In this case, the
Paul>     command interpreter becomes the new process image.

are execlp and execvp all exec's you know?

---

From: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Wed, 30 Jan 2002 12:49:24 +0600

> that version.  Can anybody help me out here?

	From OpenBSD 2.7 setpgid(2):

COMPATIBILITY
     setpgrp() is identical to setpgid(), and is retained for calling conven-
     tion compatibility with historical versions of BSD.

	BSD/OS 3.1 has a similar statement.

	BTW, I've checked OSF1 4.0 and Solaris 2.5.1 (both are
POSIX-compliant and have setpgrp(void)), and from their manpages setpgrp()
has the same effect as setpgid(0,0).

	_________________________________________
	  Dmitry Yu. Bolkhovityanov
	  The Budker Institute of Nuclear Physics
	  Novosibirsk, Russia

---

From: "Paul Smith"<[email-masked]>
Date: 30 Jan 2002 09:26:52 -0500

Paul> Single UNIX says:
  Paul> 

  ak> are execlp and execvp all exec's you know?

For heaven's sake.  The standard doesn't say that _only_ these exec's
must work that way, it says _at least_ these exec's must work that way.

I've been using UNIX systems of various flavors for 17+ years and I
can't remember _ever_ using one that didn't handle this properly (where
if you invoked a script from a shell and the script didn't have a legal
"#!" interpreter line, it wasn't given to sh).

The current code works, and works everywhere it's been tried.  If you
have a situation where it doesn't work, file a bug.  If you just don't
like the way it looks, get over it.

---

From: Alexander Kotelnikov <[email-masked]>
Date: Wed, 30 Jan 2002 17:46:22 +0300

>>>>> On 30 Jan 2002 09:26:52 -0500
Paul> 
Paul> %% Alexander Kotelnikov <[email-masked]> writes:
ak> LIE. Read standards, please.
Paul> 
Paul> Single UNIX says:
Paul> 
Paul> If the process image file is not a valid executable object, execlp()
Paul> and execvp() use the contents of that file as standard input to a
Paul> command interpreter conforming to system(). In this case, the
Paul> command interpreter becomes the new process image.
Paul> 
ak> are execlp and execvp all exec's you know?
Paul> 
Paul> For heaven's sake.  The standard doesn't say that _only_ these exec's
Paul> must work that way, it says _at least_ these exec's must work that way.
Paul> 
Paul> I've been using UNIX systems of various flavors for 17+ years and I
Paul> can't remember _ever_ using one that didn't handle this properly (where
Paul> if you invoked a script from a shell and the script didn't have a legal
Paul> "#!" interpreter line, it wasn't given to sh).

You are about "this works", and I am about "this is wrong". Shell is
not the one program who exec.

Paul> The current code works, and works everywhere it's been tried.  If you
Paul> have a situation where it doesn't work, file a bug.  If you just don't
Paul> like the way it looks, get over it.

Damn, I do. Before distributing fvwm24_convert in debian fvwm package
I add #! line.

BTW just tried to execl'ed and failed with "Exec format error".

---

From: "Paul Smith"<[email-masked]>
Date: 30 Jan 2002 10:27:59 -0500

ak> You are about "this works", and I am about "this is wrong". Shell
  ak> is not the one program who exec.

"It works" is far more important to us than "it follows the standard".

There are many situations out there where "following the standard"
yields results that don't work, on at least some systems.  We are
developing a portable window manager (that means it works on more than
just Linux!) not trying to force everyone to change their operating
system to adhere to the standard.

In FVWM we run into more of that than most tools: you wouldn't believe
how many hacks we've had to add to work around this or that misuse or
abuse of X, Motif, or whatever on various systems.

  ak> Damn, I do. Before distributing fvwm24_convert in debian fvwm
  ak> package I add #! line.

That's your prerogative.  This is free software.  Do what you like.  In
Debian you always know where Perl is, so hardcoding it is a very
reasonable thing to do.  We are not creating a Debian package, or a
Linux package--or even a POSIX package.  We are creating a _portable_
window manager package.

The fact that you want to make that change in the Debian package is
_not_ a bug in FVWM.  A bug in FVWM would be that it doesn't _work_ when
used as expected.

  ak> BTW just tried to execl'ed and failed with "Exec format error".

If you can think of any reasonable excuse to invoke the fvmwrc converter
script using execl(), we can talk further.

Allowing the script to work in a wide variety of situations is far more
important than making it work with some cobbled-up example that no one
would ever use in real life.

Hardcoding the path is _wrong_ in a number of situations.  The installer
of FVWM is not always the user of FVWM, and the installer and user may
well not have the same environment.  The Perl program that configure
finds during installation might well not be available to user.

For example: I build FVWM for Solaris and install it on an NFS-mounted
"shared tools" partition.  There's no Perl standard on Solaris (at least
not the versions we're using).  On my system, I've installed Perl in
/usr/local/bin because I'm testing a newer version of Perl; most people
don't have a /usr/local/bin/perl.  If configure finds my
/usr/local/bin/perl and hardcodes that into the convert script, and I
install it, then no one can run that script but me.