zsh-workers
 help / color / mirror / code / Atom feed
* Possibly missing explanation on difference between '&>' and '> word 2>&1' with multios in manual
@ 2021-10-19 15:24 Jett Husher
  2021-10-19 21:53 ` Bart Schaefer
  0 siblings, 1 reply; 5+ messages in thread
From: Jett Husher @ 2021-10-19 15:24 UTC (permalink / raw)
  To: zsh-workers

Greetings!

I was reading zshmisc(1) on Redirections and stumbled upon the following
notice (`&> word` or `>& word` part):

> Note that this does not have the same effect as `> word 2>&1' in the presence
> of multios (see the section below).

aand then I never found the explanation how `&>` differs from `> word 2>&1`
with multios. I have read several times and multiple sections below as well.

Did I miss something or is the explanation really not present?

- Jett


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

* Re: Possibly missing explanation on difference between '&>' and '> word 2>&1' with multios in manual
  2021-10-19 15:24 Possibly missing explanation on difference between '&>' and '> word 2>&1' with multios in manual Jett Husher
@ 2021-10-19 21:53 ` Bart Schaefer
  2021-10-21 14:49   ` Daniel Shahaf
  2021-10-22  4:43   ` Jett Husher
  0 siblings, 2 replies; 5+ messages in thread
From: Bart Schaefer @ 2021-10-19 21:53 UTC (permalink / raw)
  To: Jett Husher; +Cc: zsh-workers

On Tue, Oct 19, 2021 at 8:25 AM Jett Husher <jetthusher@pm.me> wrote:
>
> Did I miss something or is the explanation really not present?

It's not precisely missing, it's just implicit.  Excerpts:

"Note that the shell opens all the files to be used in the multio process
immediately, not at the point they are about to be written."

"Note also that redirections are always expanded in order.  This happens
regardless of the setting of the MULTIOS option, but with the option in
effect there are additional consequences."

It's not that "&>word" all by itself is not the same as ">word 2>&1"
alone, it's that "&>word" when combined with other redirections is not
the same as ">word 2>&1" combined with other redirections.


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

* Re: Possibly missing explanation on difference between '&>' and '> word 2>&1' with multios in manual
  2021-10-19 21:53 ` Bart Schaefer
@ 2021-10-21 14:49   ` Daniel Shahaf
  2021-10-22  4:43   ` Jett Husher
  1 sibling, 0 replies; 5+ messages in thread
From: Daniel Shahaf @ 2021-10-21 14:49 UTC (permalink / raw)
  To: zsh-workers; +Cc: Jett Husher

Bart Schaefer wrote on Tue, Oct 19, 2021 at 14:53:50 -0700:
> On Tue, Oct 19, 2021 at 8:25 AM Jett Husher <jetthusher@pm.me> wrote:
> >
> > Did I miss something or is the explanation really not present?
> 
> It's not precisely missing, it's just implicit.  Excerpts:
> 
> "Note that the shell opens all the files to be used in the multio process
> immediately, not at the point they are about to be written."
> 
> "Note also that redirections are always expanded in order.  This happens
> regardless of the setting of the MULTIOS option, but with the option in
> effect there are additional consequences."
> 
> It's not that "&>word" all by itself is not the same as ">word 2>&1"
> alone, it's that "&>word" when combined with other redirections is not
> the same as ">word 2>&1" combined with other redirections.

So, s/not have the same effect as/not equivalent to/?

(regex to be applied to the docs sentence Jett quoted)

Cheers,

Daniel


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

* Re: Possibly missing explanation on difference between '&>' and '> word 2>&1' with multios in manual
  2021-10-19 21:53 ` Bart Schaefer
  2021-10-21 14:49   ` Daniel Shahaf
@ 2021-10-22  4:43   ` Jett Husher
  2021-10-25 19:36     ` Daniel Shahaf
  1 sibling, 1 reply; 5+ messages in thread
From: Jett Husher @ 2021-10-22  4:43 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-workers

It took me some time and a lot of testing to finally get what the difference
is. It gets very tricky very quick with multiple multios, I think.

While testing, I also noticed that zsh opens files in multio regardless of
the access mode being used (manual says only writing counts). That is,
`<>file*` or even `<file*` will use multio, given they are big enough.

- Jett


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

* Re: Possibly missing explanation on difference between '&>' and '> word 2>&1' with multios in manual
  2021-10-22  4:43   ` Jett Husher
@ 2021-10-25 19:36     ` Daniel Shahaf
  0 siblings, 0 replies; 5+ messages in thread
From: Daniel Shahaf @ 2021-10-25 19:36 UTC (permalink / raw)
  To: Jett Husher; +Cc: zsh-workers

Jett Husher wrote on Fri, Oct 22, 2021 at 04:43:15 +0000:
> While testing, I also noticed that zsh opens files in multio regardless of
> the access mode being used (manual says only writing counts).

Well, not quite.  That section begins:
.
    If the user tries to open a file descriptor for writing more than once,
.
but there is actually a paragraph, buried halfway through that section,
that reads:
.
    If the user tries to open a file descriptor for reading more than once,

So, the information is there, but it's not clearly organized.  Again,
anyone wants to take a stab at that section?  The sources are in Doc/Zsh/.

Thanks, Jett.

Daniel


> That is, `<>file*` or even `<file*` will use multio, given they are
> big enough.


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

end of thread, other threads:[~2021-10-25 19:36 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-19 15:24 Possibly missing explanation on difference between '&>' and '> word 2>&1' with multios in manual Jett Husher
2021-10-19 21:53 ` Bart Schaefer
2021-10-21 14:49   ` Daniel Shahaf
2021-10-22  4:43   ` Jett Husher
2021-10-25 19:36     ` Daniel Shahaf

Code repositories for project(s) associated with this 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).