Re: exec problem

Re: exec problem

[x x]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

John Buttery wrote:

>* x x <pbyrne76@hotmail.com> [2002-11-26 13:31:25 +0000]:
>
>>In 4.0.4 when I issue an 'exec' and zsh can't find
>>the executable it simply terminates without warning.
>>This is surly not desirable behaviour.
>>
>>[snip function to create a "safe" exec]
>>
>>Shouldn't this be builtin?
>
>
>  My gut feeling is that zsh's behaviour in this regard is correct,
>since I always thought there was a core belief (among UNIX software in
>general, not just zsh) that the software should "do what I say, exactly
>as I say, and not second-guess me".
>  However, having said that, I think your function is quite useful
>and that a lot of people will like/use it (possibly myself included).
>Thanks for taking the time to write it. :)
>

But zsh doesn't do what the user says and certainly
isn't doing what he wants. From a users perspective
an exec has two parts:
1. run a new command without forking
2. terminate the shell

Since zsh cannot complete the first part it should not try to
do the second. More generally if a composite action is composed
of several steps, each of which must be completed in order
for the composite to be completed, then an exception should
be generated if any step fails causing the complete action
to fail gracefully.


_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus

[-- Attachment #2: Type: text/html, Size: 133 bytes --]

Re: exec problem

[John Buttery]

[-- Attachment #1: Type: text/plain, Size: 1593 bytes --]

* x x <pbyrne76@hotmail.com> [2002-11-26 17:41:47 +0000]:
> But zsh doesn't do what the user says and certainly
> isn't doing what he wants. From a users perspective
> an exec has two parts:
> 1. run a new command without forking
> 2. terminate the shell

  My understanding of what exec does must be incomplete then.  I thought
the function of exec was to replace the current shell with a command, in
which case, the shell is already terminated before any actual execution
of the <command> happens.  Is this not how it works?  Or did you
specifically say "from a user's perspective" for a reason? :) If
that's the case, then I don't think the "correct" behaviour should be
changed (to suit users who disagree); the fix for that is to educate the
users.  In this case, the result of the education may be to use your
script, which does the job of providing the behaviour those users are
looking for very well.

> Since zsh cannot complete the first part it should not try to
> do the second. More generally if a composite action is composed
> of several steps, each of which must be completed in order
> for the composite to be completed, then an exception should
> be generated if any step fails causing the complete action
> to fail gracefully.

  Agree.

-- 
------------------------------------------------------------------------
 John Buttery

        If you can't live without me, why aren't you dead yet?

                                     (Web page temporarily unavailable)
------------------------------------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

exec problem

[x x]

In 4.0.4 when I issue an 'exec' and zsh can't find
the executable it simply terminates without warning.
This is surly not desirable behaviour.

In bash the shell first checks to see if the command
is available and executable and if not it issues an
appropriate error message. The following function approximates
the bash bahaviour.

function exec {
  if [[ $# = 0 ]]; then
    builtin exec
  elif [[ -f $1 ]]; then
    if [[ -x $1 ]]; then
      builtin exec $*
    else
      echo "zsh: exec: $1: cannot execute: Permission denied"
    fi
  else
    echo "zsh: exec: $1: cannot execute: No such file or directory"
  fi
}

Shouldn't this be builtin?


Thanks,
Pascal


_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail

Re: exec problem

[John Buttery]

[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]

* x x <pbyrne76@hotmail.com> [2002-11-26 13:31:25 +0000]:
> In 4.0.4 when I issue an 'exec' and zsh can't find
> the executable it simply terminates without warning.
> This is surly not desirable behaviour.
> 
> [snip function to create a "safe" exec]
> 
> Shouldn't this be builtin?

  My gut feeling is that zsh's behaviour in this regard is correct,
since I always thought there was a core belief (among UNIX software in
general, not just zsh) that the software should "do what I say, exactly
as I say, and not second-guess me".
  However, having said that, I think your function is quite useful
and that a lot of people will like/use it (possibly myself included).
Thanks for taking the time to write it. :)

-- 
------------------------------------------------------------------------
 John Buttery

      Fascism should more appropriately be called Corporatism
        because it is a merger of state and corporate power.

                          Benito Mussolini

                                     (Web page temporarily unavailable)
------------------------------------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: exec problem

[Dan Nelson]

In the last episode (Nov 26), x x said:
> In 4.0.4 when I issue an 'exec' and zsh can't find the executable it
> simply terminates without warning. This is surly not desirable
> behaviour.
> 
> In bash the shell first checks to see if the command is available and
> executable and if not it issues an appropriate error message. The
> following function approximates the bash bahaviour.

I think bash is in the minority here (and also seems to be wrong when
run as /bin/sh).  Bourne sh, ksh, zsh, and ash all exit the shell on
exec failure.  See
http://www.opengroup.org/onlinepubs/007904975/utilities/exec.html for
the X/Open description of the exec command.

-- 
	Dan Nelson
	dnelson@allantgroup.com