Subject: FVWM: Re: Exec vs. exec

From: Bob Woodside <[email-masked]>
Date: Thu, 03 Apr 1997 01:53:19 -0500 (EST)

At 06:10 PM 3/28/97 -0800, Nadim Saeed wrote:
>What's the difference between the following two statements
>
>+      Exec xterm -T Local &
>+      Exec exec xterm -T Local &

    None. It *used* to make a difference in version 1, where you had to
specify exec if you wanted it prepended to the command. This is version
2 syntax, however, and version 2 *always* tacks the exec on, if you
didn't specify it. Really, it does.

>Which one is recommended ?

    I'd opt for the former: it makes the fvwmrc syntax look a lot less
cluttered. By the way, it doesn't matter whether you say

           Exec xterm -T Local &

or 

           exec xterm -T Local &

other than stylistically. The "Exec" here is an FVWM builtin command, 
and really ought to be capitalized for readability, but FVWM will
understand either way.

    I've not been following this list too regularly lately, so I've just
noticed this "to exec, or not to exec" thread. Sorry for not piping up
sooner.

   - Bob
    
Exec exec xterm -T Local &

    None. It used to make a difference in version 1, where you had to
specify exec if you wanted it prepended to the command. This is version
2 syntax, however, and version 2 *always* tacks the exec on, if you
didn't specify it. Really, it does.

>Which one is recommended ?

    I'd opt for the former, it makes the fvwmrc syntax look a lot less
cluttered. By the way, it doesn't matter whether you say

           Exec xterm -T Local &

or 

           exec xterm -T Local &

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

---

From: "Randy J. Ray" <[email-masked]>
Date: Thu, 3 Apr 1997 09:37:43 -0700

> didn't specify it. Really, it does.

Sorry, my process table disagrees. Running 2.0.45, any command of the form:

Exec sub-command

versus

Exec exec sub-command

leaves a shell process wrapping sub-command, waiting to it to terminate. By
changing all my "Exec" instances to "Exec exec", I get an immediate savings
of 7 processes when I first login, before I really start to run applications.

Randy
--
===============================================================================
Randy J. Ray -- U S WEST Technologies IAD/CSS/DPDS         Phone: (303)595-2869
                Denver, CO                                     [email-masked]
"It's not denial. I'm just very selective about the reality I accept." --Calvin
===============================================================================
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Kai Grossjohann <[email-masked]>
Date: 03 Apr 1997 19:46:15 +0200

>>>>> Randy J Ray writes:

  Randy> Exec sub-command

  Randy> versus

  Randy> Exec exec sub-command

You're both right.  There are four possibilities:

  1) Exec xterm
  2) Exec exec xterm
  3) Exec xterm &
  4) Exec exec xterm &

1 creates two processes, 2 creates one process.  3 creates two
processes, but the shell immediately exits (because of the "&").  I
don't know about 4.

Seems like 2 is the best, except for complex situations, where one
would prefer 3, I guess.

Any opinions, anybody?

kai
-- 
A large number of young women don't trust men with beards.
(BFBS Radio)

---

From: [email-masked] (David S. Goldberg)
Date: 03 Apr 1997 12:47:59 -0500

>>>>> Bob Woodside writes:

>     None. It *used* to make a difference in version 1, where you had
> to specify exec if you wanted it prepended to the command. This is
> version 2 syntax, however, and version 2 *always* tacks the exec on,
> if you didn't specify it. Really, it does.

I take it you're still using 2.0.42?  This (mis)feature was expunged
in 2.0.43.  Here's the relevant info from the ChangeLog:

2.0.43
       [...]
       16. Removed implicit Exec exec stuff for the time being, until I
           come up with a better way to do it (back to old behavior)
       [...]

2.0.42
       [...]
       9. Made Exec use $SHELL, like mwm, if ExecUseSHELL is specified,
          plus Exec now does an explicit "exec" as the first arg (if it's
          not there already), to eliminate extra processes
       [...]

--
Dave Goldberg
Post: The Mitre Corporation\MS B305\202 Burlington Rd.\Bedford, MA 01730
Phone: 617-271-3887
Email: [email-masked]

---

From: "Randy J. Ray" <[email-masked]>
Date: Thu, 3 Apr 1997 11:15:00 -0700

> Seems like 2 is the best, except for complex situations, where one

Just the opinion I've had since this topic first came up: there should be a
different keyword-- call it ExecNoShell for arguments' sake-- that uses fork 
and execve instead of system() to spawn the process. Then, if you need/want the
shell level (for the sake of variable evaluation perhaps) you can use Exec.

Randy

---

From: Bob Woodside <[email-masked]>
Date: Thu, 03 Apr 1997 21:50:49 -0500 (EST)

On 03-Apr-97 Randy J. Ray wrote:
>
>  ...my process table disagrees. Running 2.0.45, any command of the form:
>
>    Exec sub-command
>
>versus
>
>Exec exec sub-command
>
>leaves a shell process wrapping sub-command, waiting to it to terminate. 

    This is what makes the Unix world so much fun, don't you think? On my 
Linux (2.0.27) system, I get no such thing. Kai Grossjohann quite reasonably
suggested that it depends on whether you end your command string with an 
ampersand, but I think it depends a lot more on which flavor of Unix and which
command shell you're using - and the complexity of the sub-command string, of 
course.

    - Bob

---

From: Bob Woodside <[email-masked]>
Date: Thu, 03 Apr 1997 18:42:35 -0500 (EST)

On 03-Apr-97 David S. Goldberg wrote:
>  in 2.0.43....
>       16. Removed implicit Exec exec stuff for the time being...

    Bummer. Actually, I've been using 2.0.45 since it came out, but I had 
overlooked that note in the ChangeLog. Maybe that'll teach me to read mailing 
lists at 2:00 a.m. But probably not. 

    Hmmm...was there any other problem with the (mis)feature than a tendency to
trip over leading blanks and try to Exec  exec  exec....? If not, then this 
little patch should fix it up.

-------------------------------------------------------------------------------
*** fvwm-2.0.45/fvwm/builtins.c Wed Jan 22 08:37:28 1997
--- patched/builtins.c  Thu Apr  3 21:14:07 1997
***************
*** 843,851 ****
  
    /* if it doesn't already have an 'exec' as the first word, add that
     * to keep down number of procs started */
!   /* need to parse string better to do this right though, so not doing this
!      for now... */
!   if (0 && mystrncasecmp(action,"exec",4)!=0)
    {
      cmd = (char *)safemalloc(strlen(action)+6);
      strcpy(cmd,"exec ");
--- 843,851 ----
  
    /* if it doesn't already have an 'exec' as the first word, add that
     * to keep down number of procs started */
!   /* Skip leading spaces, don't Exec  exec  exec... */
!   GetNextToken(action, &cmd);
!   if ( mystrncasecmp(cmd,"exec",4)!=0)
    {
      cmd = (char *)safemalloc(strlen(action)+6);
      strcpy(cmd,"exec ");
-------------------------------------------------------------------------------

    - Bob

                              exec is exec is exec
                                  - gertrude stein

---

From: [email-masked] (David S. Goldberg)
Date: 04 Apr 1997 08:48:14 -0500

>     Hmmm...was there any other problem with the (mis)feature than a
> tendency to trip over leading blanks and try to Exec exec exec....?
> If not, then this little patch should fix it up.

The problem for me was mostly that I use ;s in a couple of commands.
exec causes the second command to get lost.  Obviously I could run sh
-c "command1 ; command2", and frankly that would have been OK by me,
though it would have been nice if I'd been warned someplace other than
the ChangeLog (I don't even recall any discussion about it before the
2.0.42 release).  A better solution, IMO, would be to have two
Exec's, one that uses the shell, one that directly forks and exec's
the given command.

---

From: Stig <[email-masked]>
Date: Wed, 16 Apr 1997 23:42:08 -0700

> Exec's, one that uses the shell, one that directly forks and exec's

I'm somewhat late into this thread, but I think that the two primitives
should be:

    Shell	makes a subshell

    Exec	forks a subshell with an implicit 'exec', or even just fork
		a process with no shell at all.  The fvwm command should
		mirror the behavior of the shell command by that name,
		because that's what people will expect it to do.

3 is overkill, but one is not enough.

    Stig

---

From: David Nugent <[email-masked]>
Date: Thu, 17 Apr 1997 23:34:37 +1000

> 3 is overkill, but one is not enough.

What about "Exec (commands)"?

The bracketed command syntax is a reasonably well-known feature
for make and most UNIX shells.

Regards,

David Nugent - Unique Computing Pty Ltd - Melbourne, Australia
Voice +61-3-9791-9547  Data/BBS +61-3-9792-3507  3:632/348@fidonet
[email-masked] [email-masked] http://www.blaze.net.au/~davidn/
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "Randy J. Ray" <[email-masked]>
Date: Thu, 17 Apr 1997 11:29:24 -0600

> 3 is overkill, but one is not enough.

This would be disastrous, as it would break existing rc files that use Exec
expecting it to spawn a shell as it has done thus far. *If* a new keyword is
added, it has to reference the new functionality, not break the existing
functionality.

Randy

---

From: Stig <[email-masked]>
Date: Thu, 17 Apr 1997 10:48:13 -0700

> added, it has to reference the new functionality, not break the existing

SO WHAT!  This is the reason that 2.0.x is labelled BETA.  Breaking people's
configurations is not sufficient reason to prevent a design change.  It
should be announced prominently, but people using beta software can be
reasonably expected to make small (or even large) changes to their
configuration files in the interest of having better quality in a RELEASE.

    Stig

---

From: "Randy J. Ray" <[email-masked]>
Date: Thu, 17 Apr 1997 11:52:35 -0600

> configuration files in the interest of having better quality in a RELEASE.

No, you make sweeping changes in alpha. When you've reached the beta stage,
you have to consider the scope and impact of your changes much more carefully.
In addition, 2.0.45 may be labelled "beta", but it has also been in circulation
for quite a while now, and has an established user base.

Randy