* 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).