bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] doc: mention more about ksh cloexec behavior


From: Stefano Lattarini
Subject: Re: [PATCH] doc: mention more about ksh cloexec behavior
Date: Tue, 14 Jun 2011 10:04:51 +0200
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

Hi Eric.  I have some minor issues with this patch ...

On Tuesday 14 June 2011, Eric Blake wrote:
> * doc/autoconf.texi (File Descriptors): Clarify that only the exec
> builtin suffers from cloexec issues, and consolidate example to
> show both /bin/sh and ksh pitfalls at once.
> 
> Signed-off-by: Eric Blake <address@hidden>
> ---
> 
> How does this look?
> 
>  ChangeLog         |    7 +++++
>  doc/autoconf.texi |   78 +++++++++++++++++++++++++---------------------------
>  2 files changed, 45 insertions(+), 40 deletions(-)
> 
> diff --git a/ChangeLog b/ChangeLog
> index 1fca7bb..c2e11d0 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,10 @@
> +2011-06-13  Eric Blake  <address@hidden>
> +
> +     doc: mention more about ksh cloexec behavior
> +     * doc/autoconf.texi (File Descriptors): Clarify that only the exec
> +     builtin suffers from cloexec issues, and consolidate example to
> +     show both /bin/sh and ksh pitfalls at once.
> +
>  2011-05-05  Eric Blake  <address@hidden>
> 
>       doc: document dash bug with positional parameters
> diff --git a/doc/autoconf.texi b/doc/autoconf.texi
> index 7ff693f..5571c2c 100644
> --- a/doc/autoconf.texi
> +++ b/doc/autoconf.texi
> @@ -15435,53 +15435,51 @@ File Descriptors
>  Don't rely on file descriptors 0, 1, and 2 remaining closed in a
>  subsidiary program.  If any of these descriptors is closed, the
>  operating system may open an unspecified file for the descriptor in the
> -new process image.  Posix says this may be done only if the subsidiary
> -program is set-user-ID or set-group-ID, but HP-UX 11.23 does
> -it even for ordinary programs.
> -
> -Don't rely on open file descriptors being open in child processes.  In
> address@hidden, file descriptors above 2 which are opened using
> +new process image.  Posix 2008 says this may be done only if the
> +subsidiary program is set-user-ID or set-group-ID, but HP-UX 11.23 does
> +it even for ordinary programs, and the next version of Posix will allow
> +HP-UX behavior.
> +
> +If you want a file descriptor above 2 to be inherited into a child
> +process, then you must use redirections specific to that command or a
> +containing subshell or command group, rather than relying on
> address@hidden in the shell. In @command{ksh} as well as HP-UX
> address@hidden, file descriptors above 2 which are opened using
>  @samp{exec @var{n}>file} are closed by a subsequent @samp{exec} (such as
>  that involved in the fork-and-exec which runs a program or script).
> -Thus, using @command{sh}, we have:
> -
> address@hidden
> -$ @kbd{cat ./descrips}
> -#!/bin/sh -
> -echo hello >&5
> -$ @kbd{exec 5>t}
> -$ @kbd{./descrips}
> -$ @kbd{cat t}
> -hello
> -$
> address@hidden example
> -
> address@hidden
> -But using ksh:
> -
> address@hidden
> -$ @kbd{exec 5>t}
> -$ @kbd{./descrips}
> -hello
> -$ @kbd{cat t}
> -$
> address@hidden example
> -
> address@hidden
> -Within the process which runs the @samp{descrips} script, file
> -descriptor 5 is closed.
> 
>  Don't rely on duplicating a closed file descriptor to cause an
>  error.  With Solaris @command{/bin/sh}, when the redirection fails, the
>  output goes to the original file descriptor.
> 
> address@hidden
> -$ @kbd{bash -c 'echo hi >&3' 3>&-; echo $?}
> -bash: 3: Bad file descriptor
> -1
> -$ @kbd{/bin/sh -c 'echo hi >&3' 3>&-; echo $?}
> -hi
> -0
> +Demonstrating these last two points, note how the child @command{sh} (in
> +this case, Solaris 10 @command{/bin/sh}) leaks output to standard output
> +when file descriptor 5 is closed, and how the parent @command{ksh}
> +refuses to pass file descriptor 5 to the child via @command{exec}:
> +
> address@hidden
> +$ @kbd{echo 'echo hello >&5\n' >k
>
Why the `\n' here?

> +$ @kbd{sh -c 'exec 5>t; echo -`sh ./k`-`cat t`-'}
> +--hello-
> +$ @kbd{sh -c ':>t; exec 5>&-; echo -`sh ./k`-`cat t`-'}
> +-hello--
> +$ @kbd{ksh -c 'exec 5>t; echo -`ksh ./k`-`cat t`-'}
> +./k[1]: 5: cannot open [Bad file number]
> +---
> +$ @kbd{ksh -c ':>t; exec 5>&-; echo -`ksh ./k`-`cat t`-'}
> +./k[1]: 5: cannot open [Bad file number]
> +---
> +$ @kbd{ksh -c '(echo -`ksh ./k`-`cat t`-) 5>t'}
> +--hello-
> +$ @kbd{ksh -c '{ echo -`ksh ./k`-`cat t`-; } 5>t'}
> +--hello-
> +$ @kbd{ksh -c 'echo -`5>t ksh ./k`-`cat t`-'}
> +--hello-
> +$ @kbd{bash -c 'exec 5>t; echo -`bash ./k`-`cat t`-'}
> +--hello-
> +$ @kbd{bash -c ':>t; exec 5>&-; echo -`bash ./k`-`cat t`-'}
> +./k: line 1: 5: Bad file number
> +---
>  @end example
>
I'd reorder and rework the above examples as follow:

  $ @kbd{bash -c 'exec 5>&-; echo -`bash ./k`-'}
  ./k: line 1: 5: Bad file number
  --
  $ @kbd{ksh -c 'exec 5>&-; echo -`ksh ./k`-'}
  ./k[1]: 5: cannot open [Bad file number]
  --
  $ @kbd{sh -c 'exec 5>&-; echo -`sh ./k`-}
  -hello-

  $ @kbd{sh -c 'exec 5>t; echo -`sh ./k`-`cat t`-'}
  --hello-
  $ @kbd{bash -c 'exec 5>t; echo -`bash ./k`-`cat t`-'}
  --hello-
  $ @kbd{ksh -c 'exec 5>t; echo -`ksh ./k`-`cat t`-'}
  ./k[1]: 5: cannot open [Bad file number]
  ---
  $ @kbd{ksh -c '(echo -`ksh ./k`-`cat t`-) 5>t'}
  --hello-
  $ @kbd{ksh -c '{ echo -`ksh ./k`-`cat t`-; } 5>t'}
  --hello-
  $ @kbd{ksh -c 'echo -`5>t ksh ./k`-`cat t`-'}
  --hello-

At this point, the above might as well be broken in two distinct
examples, which can thus be kept nearer to the descripton of the
issues they demonstrate.

Note that I'm just saying this makes things clearer *for me*, but
I don't know if it does for other people too; so your call in the
end.

Thanks,
  Stefano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]