* Do file descriptors survive to subshell?
@ 2016-09-12 15:29 ` Sebastian Gniazdowski
2016-09-12 16:19 ` Peter Stephenson
0 siblings, 1 reply; 7+ messages in thread
From: Sebastian Gniazdowski @ 2016-09-12 15:29 UTC (permalink / raw)
To: Zsh Users
Hello,
I run subshell (zsh-5.2-dev-1) and there, an exported variable
containing file descriptor works with cat <&$FD. I was first thinking
there's a bug when read -u $FD -t returned true for it, added bunch of
zwarns() to source, and was surprised that (util.c):
ret = select(fd+1, (SELECT_ARG_2_T) &foofd, NULL, NULL, &expire_tv);
returns 1, i.e. one ready fd in set. It is then when I tried to just
cat from the FD, and it worked. Is it expected? How could the FD
survive, maybe because I do flock() (program util-linux/flock, using
call flock()) on it? But the "survive FD" feature should work only for
"exec zsh-5.2-dev-1", not "zsh-5.2-dev-1", shouldn't it ...
Best regards,
Sebastian Gniazdowski
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Do file descriptors survive to subshell?
2016-09-12 15:29 ` Do file descriptors survive to subshell? Sebastian Gniazdowski
@ 2016-09-12 16:19 ` Peter Stephenson
2016-09-12 16:29 ` Sebastian Gniazdowski
0 siblings, 1 reply; 7+ messages in thread
From: Peter Stephenson @ 2016-09-12 16:19 UTC (permalink / raw)
To: Zsh Users
It depends how the FD was opened.
> But the "survive FD" feature should work only for
> "exec zsh-5.2-dev-1", not "zsh-5.2-dev-1", shouldn't it ...
well, if you ran
zsh-5.2-dev-1 3< myfile
you'd be a bit annoyed if FD 3 was closed, wouldn't you?
And of course 0, 1 and 2 are left open.
So for FDs opened by / known to the user, it's expected that they'll
survive; internal FDs used by the shell should be closed. One example
of an FD the shell uses internally is for terminal management --- we
don't do this directly on the user-visible FDs for reasons I don't
think I ever fully understood. Because this is opened early, it's
usualy FD 10, i.e. just outside the easily accessible range (that
traditionally shells keep away from allowing you to manipulate
directly) 0 to 9.
pws
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Do file descriptors survive to subshell?
2016-09-12 16:19 ` Peter Stephenson
@ 2016-09-12 16:29 ` Sebastian Gniazdowski
2016-09-12 18:24 ` Bart Schaefer
0 siblings, 1 reply; 7+ messages in thread
From: Sebastian Gniazdowski @ 2016-09-12 16:29 UTC (permalink / raw)
To: Peter Stephenson; +Cc: Zsh Users
OK, thanks. I was planning to use read -t -u on a descriptor obtained
by exported variable SOMETHING_ID, to differentiate between `exec
zsh-5.2-dev-1` and `zsh-5.2-dev-1`. If it would fail then it's
non-exec, regular start. Now I see that SHLVL should be used to
differentiate that?
BTW., read -t -u seems to succeed as many times as there are lines in
a file (file descriptor), that's rather unexpected, it rather should
do some "read char, put char back" thing, or something not changing FD
position in file I would say
Best regards,
Sebastian Gniazdowski
On 12 September 2016 at 18:19, Peter Stephenson
<p.stephenson@samsung.com> wrote:
> It depends how the FD was opened.
>
>> But the "survive FD" feature should work only for
>> "exec zsh-5.2-dev-1", not "zsh-5.2-dev-1", shouldn't it ...
>
> well, if you ran
>
> zsh-5.2-dev-1 3< myfile
>
> you'd be a bit annoyed if FD 3 was closed, wouldn't you?
> And of course 0, 1 and 2 are left open.
>
> So for FDs opened by / known to the user, it's expected that they'll
> survive; internal FDs used by the shell should be closed. One example
> of an FD the shell uses internally is for terminal management --- we
> don't do this directly on the user-visible FDs for reasons I don't
> think I ever fully understood. Because this is opened early, it's
> usualy FD 10, i.e. just outside the easily accessible range (that
> traditionally shells keep away from allowing you to manipulate
> directly) 0 to 9.
>
> pws
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Do file descriptors survive to subshell?
2016-09-12 16:29 ` Sebastian Gniazdowski
@ 2016-09-12 18:24 ` Bart Schaefer
2016-09-13 8:54 ` Sebastian Gniazdowski
0 siblings, 1 reply; 7+ messages in thread
From: Bart Schaefer @ 2016-09-12 18:24 UTC (permalink / raw)
To: Zsh Users
On Sep 12, 6:29pm, Sebastian Gniazdowski wrote:
}
} BTW., read -t -u seems to succeed as many times as there are lines in
} a file (file descriptor), that's rather unexpected, it rather should
} do some "read char, put char back" thing, or something not changing FD
} position in file I would say
?? That's not how "read" is defined. It either reads a line if it can,
or it returns failure if it can't. The -t option only changes what
"it can't" means, and the -u option only changes where it reads it.
You can change how "a line" is defined, but you can't define "a line"
as nothing.
You might suggest that -k 0 should test whether reading is possible and
return success without actually reading anything, but as currently
defined "read" returns nonzero only when bytes are consumed.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Do file descriptors survive to subshell?
2016-09-12 18:24 ` Bart Schaefer
@ 2016-09-13 8:54 ` Sebastian Gniazdowski
2016-09-14 17:53 ` Bart Schaefer
0 siblings, 1 reply; 7+ messages in thread
From: Sebastian Gniazdowski @ 2016-09-13 8:54 UTC (permalink / raw)
To: Bart Schaefer; +Cc: Zsh Users
On 12 September 2016 at 20:24, Bart Schaefer <schaefer@brasslantern.com> wrote:
> ?? That's not how "read" is defined. It either reads a line if it can,
> or it returns failure if it can't. The -t option only changes what
> "it can't" means, and the -u option only changes where it reads it.
> You can change how "a line" is defined, but you can't define "a line"
> as nothing.
>
> You might suggest that -k 0 should test whether reading is possible and
> return success without actually reading anything, but as currently
> defined "read" returns nonzero only when bytes are consumed.
That's quite regretful, how to check if a read descriptor is valid? To
test if a descriptor is inherited from previous Zsh execution I
switched to write descriptors and use print -u $EXPORTED_FD -n to test
them, this works.
Best regards,
Sebastian Gniazdowski
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Do file descriptors survive to subshell?
2016-09-13 8:54 ` Sebastian Gniazdowski
@ 2016-09-14 17:53 ` Bart Schaefer
2016-09-15 6:41 ` Sebastian Gniazdowski
0 siblings, 1 reply; 7+ messages in thread
From: Bart Schaefer @ 2016-09-14 17:53 UTC (permalink / raw)
To: Zsh Users
On Sep 13, 10:54am, Sebastian Gniazdowski wrote:
}
} That's quite regretful, how to check if a read descriptor is valid?
Under "Conditional Expressions":
[...]
-r FILE
true if FILE exists and is readable by current process.
[...]
In each of the above expressions, if FILE is of the form `/dev/fd/N',
where N is an integer, then the test applied to the open file whose
descriptor number is N, even if the underlying system does not support
the /dev/fd directory.
[...]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Do file descriptors survive to subshell?
2016-09-14 17:53 ` Bart Schaefer
@ 2016-09-15 6:41 ` Sebastian Gniazdowski
0 siblings, 0 replies; 7+ messages in thread
From: Sebastian Gniazdowski @ 2016-09-15 6:41 UTC (permalink / raw)
To: Bart Schaefer; +Cc: Zsh Users
On 14 September 2016 at 19:53, Bart Schaefer <schaefer@brasslantern.com> wrote:
> Under "Conditional Expressions":
>
> [...]
>
> -r FILE
> true if FILE exists and is readable by current process.
>
> [...]
>
> In each of the above expressions, if FILE is of the form `/dev/fd/N',
> where N is an integer, then the test applied to the open file whose
> descriptor number is N, even if the underlying system does not support
> the /dev/fd directory.
>
> [...]
>
Should have just read about all the tests, thanks
Best regards,
Sebastian Gniazdowski
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-09-15 8:17 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CGME20160912160148eucas1p1c7f423821260c611c9b34fbe47bfcf86@eucas1p1.samsung.com>
2016-09-12 15:29 ` Do file descriptors survive to subshell? Sebastian Gniazdowski
2016-09-12 16:19 ` Peter Stephenson
2016-09-12 16:29 ` Sebastian Gniazdowski
2016-09-12 18:24 ` Bart Schaefer
2016-09-13 8:54 ` Sebastian Gniazdowski
2016-09-14 17:53 ` Bart Schaefer
2016-09-15 6:41 ` Sebastian Gniazdowski
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).