Odd behavior using MULTIOS

Odd behavior using MULTIOS

[Clinton Bunch]

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
%

Re: Odd behavior using MULTIOS

[Peter Stephenson]

> 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

Re: Odd behavior using MULTIOS

[Clinton Bunch]

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
>

Re: Odd behavior using MULTIOS

[Peter Stephenson]

> 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

Re: Odd behavior using MULTIOS

[Clinton Bunch]

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
>