zsh-users
 help / color / mirror / Atom feed
* Odd behavior using MULTIOS
@ 2020-11-11 16:25 Clinton Bunch
  2020-11-11 16:42 ` Peter Stephenson
  0 siblings, 1 reply; 5+ messages in thread
From: Clinton Bunch @ 2020-11-11 16:25 UTC (permalink / raw)
  To: zsh-users

Is this the expected behavior?

% cat /etc/system-release
CentOS Linux release 8.2.2004 (Core)
% uname -a
Linux cdblinux.cfhp.com 4.18.0-193.14.2.el8_2.x86_64 #1 SMP Sun Jul 26 
03:54:29 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
% echo $ZSH_VERSION
5.5.1
% cat test.zsh
#!/bin/zsh

setopt MULTIOS

{
print -u3 "Testing"
print  "Second Testing"
} 3>&1 3>/tmp/test
% zsh test.zsh
Second Testing
Testing
% cat /tmp/test
Testing
%



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Odd behavior using MULTIOS
  2020-11-11 16:25 Odd behavior using MULTIOS Clinton Bunch
@ 2020-11-11 16:42 ` Peter Stephenson
  2020-11-11 17:11   ` Clinton Bunch
  0 siblings, 1 reply; 5+ messages in thread
From: Peter Stephenson @ 2020-11-11 16:42 UTC (permalink / raw)
  To: zsh-users


> On 11 November 2020 at 16:25 Clinton Bunch <cdb_zsh@zentaur.org> wrote:
> Is this the expected behavior?
> 
> setopt MULTIOS
> {
> print -u3 "Testing"
> print  "Second Testing"
> } 3>&1 3>/tmp/test
> % zsh test.zsh
> Second Testing
> Testing

You mean the ordering?  Yes, as documented "the shell opens the file descriptor as a pipe
to  a process that copies its input to all the specified outputs".  So this isn't
synchronous within the current shell and you can't rely on ordering.  You'll note
there's nothing there to determine whether the downstream pipe component performs
a write to the terminal before the main shell does --- think of it a bit like

{ print Testing; print "Second Testing" >/dev/tty } | tee /dev/tty /tmp/test

--- although I'm not guaranteeing they're identical and clearly there's room
for lots of things in the two processes to affect the ordering.

pws


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Odd behavior using MULTIOS
  2020-11-11 16:42 ` Peter Stephenson
@ 2020-11-11 17:11   ` Clinton Bunch
  2020-11-11 17:25     ` Peter Stephenson
  0 siblings, 1 reply; 5+ messages in thread
From: Clinton Bunch @ 2020-11-11 17:11 UTC (permalink / raw)
  To: zsh-users

Another thing I noticed is that MULTIOS doesn't appear to work with exec

i.e.

exec 3>/tmp/test1 3>/tmp/test2

causes the script to hang.

I'm not sure why.  Am I just being dense today?

On 11/11/2020 10:42 AM, Peter Stephenson wrote:
>> On 11 November 2020 at 16:25 Clinton Bunch <cdb_zsh@zentaur.org> wrote:
>> Is this the expected behavior?
>>
>> setopt MULTIOS
>> {
>> print -u3 "Testing"
>> print  "Second Testing"
>> } 3>&1 3>/tmp/test
>> % zsh test.zsh
>> Second Testing
>> Testing
> You mean the ordering?  Yes, as documented "the shell opens the file descriptor as a pipe
> to  a process that copies its input to all the specified outputs".  So this isn't
> synchronous within the current shell and you can't rely on ordering.  You'll note
> there's nothing there to determine whether the downstream pipe component performs
> a write to the terminal before the main shell does --- think of it a bit like
>
> { print Testing; print "Second Testing" >/dev/tty } | tee /dev/tty /tmp/test
>
> --- although I'm not guaranteeing they're identical and clearly there's room
> for lots of things in the two processes to affect the ordering.
>
> pws
>


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Odd behavior using MULTIOS
  2020-11-11 17:11   ` Clinton Bunch
@ 2020-11-11 17:25     ` Peter Stephenson
  2020-11-11 17:36       ` Clinton Bunch
  0 siblings, 1 reply; 5+ messages in thread
From: Peter Stephenson @ 2020-11-11 17:25 UTC (permalink / raw)
  To: zsh-users


> On 11 November 2020 at 17:11 Clinton Bunch <cdbunch@zentaur.org> wrote:
> Another thing I noticed is that MULTIOS doesn't appear to work with exec
> 
> i.e.
> 
> exec 3>/tmp/test1 3>/tmp/test2
> 
> causes the script to hang.
> 
> I'm not sure why.  Am I just being dense today?

That sounds like a real bug.  The implementation is going to be a little
different for this case, indeed we effectively get a coprocess so anyone
fixing it may have their work cut out, but I'm not aware of any actual
expectation that it doesn't work, and certainly not that it hangs.

pws


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Odd behavior using MULTIOS
  2020-11-11 17:25     ` Peter Stephenson
@ 2020-11-11 17:36       ` Clinton Bunch
  0 siblings, 0 replies; 5+ messages in thread
From: Clinton Bunch @ 2020-11-11 17:36 UTC (permalink / raw)
  To: zsh-users

Ok.  Well I got the same result on 4.3.17 on HP-UX 11.31 and 5.5.1 on 
Centos Linux 8.  So if it's a bug, it's been there a while.

Although my original use case was to create a file descriptor that 
printed both to stderr and a log file, where simple messages would be 
printed to both while more details could be sent to the logfile without 
doubling the print statements for the simple messages. So the ordering 
problem I initially posted about would affect this use case as well, 
making it, for me at least, moot.

On 11/11/2020 11:25 AM, Peter Stephenson wrote:
>> On 11 November 2020 at 17:11 Clinton Bunch <cdbunch@zentaur.org> wrote:
>> Another thing I noticed is that MULTIOS doesn't appear to work with exec
>>
>> i.e.
>>
>> exec 3>/tmp/test1 3>/tmp/test2
>>
>> causes the script to hang.
>>
>> I'm not sure why.  Am I just being dense today?
> That sounds like a real bug.  The implementation is going to be a little
> different for this case, indeed we effectively get a coprocess so anyone
> fixing it may have their work cut out, but I'm not aware of any actual
> expectation that it doesn't work, and certainly not that it hangs.
>
> pws
>


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-11-11 17:37 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-11 16:25 Odd behavior using MULTIOS Clinton Bunch
2020-11-11 16:42 ` Peter Stephenson
2020-11-11 17:11   ` Clinton Bunch
2020-11-11 17:25     ` Peter Stephenson
2020-11-11 17:36       ` Clinton Bunch

zsh-users

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/zsh-users

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-users zsh-users/ http://inbox.vuxu.org/zsh-users \
		zsh-users@zsh.org
	public-inbox-index zsh-users

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.users


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git