date:20180427

Re: Pushing/restoring a file descriptor for a compound command

2018-04-27 Thread Stephane Chazelas

2018-04-28 00:23:51 +0200, Martijn Dekker:
[...]
> That said, do you have any opinion on whether something like
>{ ... ; } 3>&-
> should push/restore a closed file descriptor if it's already closed, so that
> the effect of exec-ing that descriptor within the compound command is local
> to that compound command?
[...]

Actually, in my list of "issues" I plan to some day raise to the
Austin Group, I had:

sh -c '{ exec > a; } > b; echo x' > c

which sounds like it's the same.

Do we honour the compound command asking for stdout to be
redirected, or do we honour the "> b" redirection being
temporary and apply only to the command substitution?

I'm undecided here, though I'd tend to lean the same way as you
do.

The problem can also be expressed as:

redir_stdout() {
  exec > "$1"
}

redir_stdout file1 > file2

Or:

close() { eval "exec $1>&-"; }
close 1 > file

f() {
  close 1
  redir_stdout file
  echo  foo
  close 1
}

f > /dev/null

POSIX could arbitrate based on the number of implementations
that go one or the other way. Or leave it unspecified (I've not
checked what it currently says)..

-- 
Stephane

Re: Pushing/restoring a file descriptor for a compound command

2018-04-27 Thread Robert Elz

Date:Sat, 28 Apr 2018 03:53:12 +0200
From:Martijn Dekker 
Message-ID:  <81b93245-e42f-ad62-4005-8ad676733...@inlv.org>

  |  How does NetBSD sh handle this?

This isn't really the best place for code samples, but ...

"fd" is the file descriptor in question:

if ((flags & REDIR_PUSH) && !is_renamed(sv->renamed, fd)) {
INTOFF;
if (big_sh_fd < 10)
find_big_fd();
if ((i = fcntl(fd, F_DUPFD, big_sh_fd)) == -1) {
switch (errno) {
case EBADF:
i = CLOSED;
break;
case EMFILE:
case EINVAL:
find_big_fd();
i = fcntl(fd, F_DUPFD, big_sh_fd);
if (i >= 0)
break;
/* FALLTHRU */
default:
i = errno;
INTON;/* XXX not needed here ? */
error("%d: %s", fd, strerror(i));
/* NOTREACHED */
}
}
if (i >= 0)
(void)fcntl(i, F_SETFD, FD_CLOEXEC);
fd_rename(sv, fd, i);

CLOSED is < 0 

fd_rename() does (aside from bookkeeping)

rl->orig = from;
rl->into = to;

The "sv" arg is the data struct where all this is
saved (rl is alloc'd memory, linked to it).

and then later, when things are being restored

if (rl->into < 0)
close(rl->orig);
else
movefd(rl->into, rl->orig);

movefd() ends up translating into dup2() with
error, and close-on-exec handling.

The FreeBSD sh is similar, but simpler - they don't deal
with user fd's >= 10, which makes the data structs needed
simpler, and much easier to avoid user fd's stepping all
over the shell's internal fds - we allow user fds to be anything
the system allows, and the shell makes sure it moves its
own fds around if needed to avoid issues.

The EINVAL and EMFILE handling is dealing with the
consequences of the user/script playing with ulimit, or
at least as much as is possible.

  | If it's a bug, surely it would meet that requirement.

Not for me to say, but it it doesn't have to be different
(rather than just would be nicer if it was different) then
it can be hard to justify making changes.

kre

Re: Pushing/restoring a file descriptor for a compound command

2018-04-27 Thread Martijn Dekker

Op 28-04-18 om 01:55 schreef Robert Elz:

Date:Sat, 28 Apr 2018 00:23:51 +0200
From:Martijn Dekker
Message-ID: <8800d6d5-67ea-fad4-19c3-dac4bbfd8...@inlv.org>

| That said, do you have any opinion on whether something like
| { ... ; } 3>&-
| should push/restore a closed file descriptor if it's already closed,

I suspect that it is just a bug, the usual way to do this is

saved_fd = fcntl(3, F_DUPFD, BIG_NUM);
close(3);

and later

dup2(saved_fd, 3);
close(saved_fd);

Which works fine, provided fd 3 is open at the beginning, otherwise
all of those fail with EBADF, which tends to just be ignored (and the
dup2() failing leaves fd 3 with whatever it was set to in between.)

It works fine on NetBSD sh though, and on every other ash derivative I
know of except dash -- even for a file descriptor 3 that is closed at
the beginning. How does NetBSD sh handle this?

Fixing it means adding code - as I understand it, in dash, that is
something they avoid unless it is absolutely essential

If it's a bug, surely it would meet that requirement.

- and if no-one
can show where POSIX requires it, probably just won't happen.

The closest thing I've found is the first sentence of POSIX 2.7
Redirection: "Redirection is used to open and close files for the
current shell execution environment (see Shell Execution Environment) or
for any command."

The first part of that sentence refers to exec'ing it, so is irrelevant
here. The relevant bit is "or for any command". This includes compound
commands.

I claim that this implies that a redirection added to a compound command
should always cause the specified descriptor to be saved and restored,
no matter the initial state of it, or the state initialised by the
redirection.

The alternative seems inherently broken: the effect of an 'exec 3&- redirection for the same FD creates a reasonable
expectation that it should restore that FD's state when leaving the
compound command.

Moreover, every current POSIX-compliant shell I know of works as I would
expect, except bash and dash. The behaviour of dash appears to be unique
for current ash derivatives, as FreeBSD sh, NetBSD sh, and Busybox ash
also work as I would expect. I think that's further evidence that the
behaviour of bash and dash should be considered a bug.

45 matches

Mail list logo