zsh-workers
 help / Atom feed
* [PATCH] respect nullglob given multios
@ 2019-10-10  1:18 ` Joe Rice
  2019-10-10 16:40   ` Peter Stephenson
  0 siblings, 1 reply; 5+ messages in thread
From: Joe Rice @ 2019-10-10  1:18 UTC (permalink / raw)
  To: zsh-workers

[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]

This patch makes multios behave less surprisingly with nullglob.

Currently, multios throws a file not found error when a nullglob is given. This patch inserts /dev/null into the redirection list when the glob returns empty with no errors.

Is this a behavior that would interest anyone else? I find myself using the `cat /dev/null *(N.)` idiom quite a bit and I thought the behavior made sense for the null case in multios.

Joe

diff --git a/Src/glob.c b/Src/glob.c
index 92fd64e7c..a708dfb9a 100644
--- a/Src/glob.c
+++ b/Src/glob.c
@@ -2116,8 +2116,11 @@ xpandredir(struct redir *fn, LinkList redirtab)
     /* ...which undergoes all the usual shell expansions */
     prefork(&fake, isset(MULTIOS) ? 0 : PREFORK_SINGLE, NULL);
     /* Globbing is only done for multios. */
-    if (!errflag && isset(MULTIOS))
+    if (!errflag && isset(MULTIOS)) {
        globlist(&fake, 0);
+       if (empty(&fake) && !errflag && !badcshglob)
+           addlinknode(&fake, dupstring("/dev/null"));
+    }
     if (errflag)
        return 0;
     if (nonempty(&fake) && !nextnode(firstnode(&fake))) {

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

* Re: [PATCH] respect nullglob given multios
  2019-10-10  1:18 ` [PATCH] respect nullglob given multios Joe Rice
@ 2019-10-10 16:40   ` Peter Stephenson
  2019-10-11  0:25     ` Philippe Troin
  0 siblings, 1 reply; 5+ messages in thread
From: Peter Stephenson @ 2019-10-10 16:40 UTC (permalink / raw)
  To: zsh-workers

On Thu, 2019-10-10 at 01:18 +0000, Joe Rice wrote:
> This patch makes multios behave less surprisingly with nullglob.
>
> Currently, multios throws a file not found error when a nullglob is
> given. This patch inserts /dev/null into the redirection list when the
> glob returns empty with no errors.
>
> Is this a behavior that would interest anyone else? I find myself
> using the `cat /dev/null *(N.)` idiom quite a bit and I thought the
> behavior made sense for the null case in multios.

This does seem a logical effect, though it ought to be documented.

pws

diff --git a/Doc/Zsh/redirect.yo b/Doc/Zsh/redirect.yo
index 13496d8d3..76bc23efe 100644
--- a/Doc/Zsh/redirect.yo
+++ b/Doc/Zsh/redirect.yo
@@ -277,7 +277,10 @@ all the specified inputs to its output in the order specified, provided
 the tt(MULTIOS) option is set.  It should be noted that each file is
 opened immediately, not at the point where it is about to be read:
 this behaviour differs from tt(cat), so if strictly standard behaviour
-is needed, tt(cat) should be used instead.
+is needed, tt(cat) should be used instead.  If the option tt(NULL_GLOB)
+is set and filename generation produces no files, redirection is
+instead performed from tt(/dev/null), so that there is a valid, but
+empty, input stream.
 
 Thus
 


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

* Re: [PATCH] respect nullglob given multios
  2019-10-10 16:40   ` Peter Stephenson
@ 2019-10-11  0:25     ` Philippe Troin
  2019-10-11  6:46       ` Joe Rice
  0 siblings, 1 reply; 5+ messages in thread
From: Philippe Troin @ 2019-10-11  0:25 UTC (permalink / raw)
  To: zsh-workers

On Thu, 2019-10-10 at 16:40 +0000, Peter Stephenson wrote:
> On Thu, 2019-10-10 at 01:18 +0000, Joe Rice wrote:
> > This patch makes multios behave less surprisingly with nullglob.
> > 
> > Currently, multios throws a file not found error when a nullglob is
> > given. This patch inserts /dev/null into the redirection list when
> > the
> > glob returns empty with no errors.
> > 
> > Is this a behavior that would interest anyone else? I find myself
> > using the `cat /dev/null *(N.)` idiom quite a bit and I thought the
> > behavior made sense for the null case in multios.
> 
> This does seem a logical effect, though it ought to be documented.

I am not sure if it's that logical.
What about if the pipeline on left of the redirection is something
expensive?
I'd rather have the command fail than starting a long-running job whose
output will be lost.

Also, conceptually, this introduces a difference between the behaviors
of an explicitly empty redirection and an empty redirection after
filename expansion.

Compare:
   % zsh -f
   % echo $ZSH_VERSION
   5.7.1
   % print nosuchfileprefix*(N)

   % print

   % print > nosuchfileprefix*(N) # Implicitly sends to /dev/null
   % print > 
   zsh: parse error near `\n'
   % 

I'd argue that the behavior should be the same: both should send to
/dev/null or not.

Incidentally, and as a completely separate issue, on an unpatched 5.7.1
zsh (Fedora 30 stock package), the command above succeeds and creates a
file:
   % print > nosuchfileprefix*(N)
   % ls nosuchfileprefix*(N)
   'nosuchfileprefix'$'\207\210''N'$'\212'

Is that expected?

Phil.


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

* Re: [PATCH] respect nullglob given multios
  2019-10-11  0:25     ` Philippe Troin
@ 2019-10-11  6:46       ` Joe Rice
  2019-10-11  8:33         ` Peter Stephenson
  0 siblings, 1 reply; 5+ messages in thread
From: Joe Rice @ 2019-10-11  6:46 UTC (permalink / raw)
  To: zsh-workers

> On Thu, 2019-10-10 at 16:40 +0000, Peter Stephenson wrote:
>
> > On Thu, 2019-10-10 at 01:18 +0000, Joe Rice wrote:
> >
> > > This patch makes multios behave less surprisingly with nullglob.
> > > Currently, multios throws a file not found error when a nullglob is
> > > given. This patch inserts /dev/null into the redirection list when
> > > the
> > > glob returns empty with no errors.
> > > Is this a behavior that would interest anyone else? I find myself
> > > using the `cat /dev/null *(N.)` idiom quite a bit and I thought the
> > > behavior made sense for the null case in multios.
> >
> > This does seem a logical effect, though it ought to be documented.
>
> I am not sure if it's that logical.
> What about if the pipeline on left of the redirection is something
> expensive?
> I'd rather have the command fail than starting a long-running job whose
> output will be lost.

For the case of expensive pipelines on the left side, running with a global nullglob and expecting it to never be null already seems like a risky proposition, and if they were using an explicit qualifier, then I think they would have sufficiently acknowledged that behavior.

Clear acknowledgement of behavior:

% setopt nullglob
... few lines ...
% expensive > *

% expensive > *(N)

Concerning unexpected behavior:

% setopt nullglob
... many lines ...
% expensive > *

This can be addressed explicitly by toggling nullglob off on this line with (N).

> Also, conceptually, this introduces a difference between the behaviors
> of an explicitly empty redirection and an empty redirection after
> filename expansion.
>
> Compare:
> % zsh -f
> % echo $ZSH_VERSION
> 5.7.1
> % print nosuchfileprefix*(N)
>
> % print
>
> % print > nosuchfileprefix*(N) # Implicitly sends to /dev/null

I think these three are very different in the user's mind:

% print *
Should list the files in the current directory.

% print
Should print only a newline, which happens to be the same output as listing an empty directory.

% print > *
Should truncate and write a single newline to each file in the current directory.

The only difference this patch makes is that the latter now writes "to nothing" when the nullglob is enabled.

> % print >
> zsh: parse error near `\n'
>
> I'd argue that the behavior should be the same: both should send to
> /dev/null or not.

I think this is the most different, as multios doesn't have a conceptual effect on normal use of single redirections. Redirections are conceptually (#)(<|>)(target) anywhere on the line so changing behavior on multios seems odd. Consider this case:

% > * grep ...

'>' is not pulling the next resolved tokens and testing if that is empty. It's pulling the pattern and testing if that is resolves as empty.

% print >

Offers no such pattern.

> Incidentally, and as a completely separate issue, on an unpatched 5.7.1
> zsh (Fedora 30 stock package), the command above succeeds and creates a
> file:
> % print > nosuchfileprefix*(N)
> % ls nosuchfileprefix*(N)
> 'nosuchfileprefix'$'\207\210''N'$'\212'
>
> Is that expected?

That is expected with the current implementation (5.7.1), this patch would intentionally resolve it as `print > /dev/null` instead.

Another bit that seems relevant is how this patch handles brace expansion under multios:

% setopt nomultios
% empty=()
% print > ${^empty}
zsh: no such file or directory:
% setopt multios
% print > ${^empty}

Which is desirable (I think).

% ls
foo.a
% grep < *.{a,b,c}(N)

Resolves as:

% grep < {*.a(N),*.b(N),*.c(N)}
% grep < foo.a < /dev/null < /dev/null

Which should be functionally the same and seems to fit in with how brace expansion and patterns interact.

Joe

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

* Re: [PATCH] respect nullglob given multios
  2019-10-11  6:46       ` Joe Rice
@ 2019-10-11  8:33         ` Peter Stephenson
  0 siblings, 0 replies; 5+ messages in thread
From: Peter Stephenson @ 2019-10-11  8:33 UTC (permalink / raw)
  To: Joe Rice, zsh-workers

> On 11 October 2019 at 07:46 Joe Rice <jsrice@protonmail.com> wrote:
> > On Thu, 2019-10-10 at 16:40 +0000, Peter Stephenson wrote:
> > > On Thu, 2019-10-10 at 01:18 +0000, Joe Rice wrote:
> > >
> > > > This patch makes multios behave less surprisingly with nullglob.
> > > > Currently, multios throws a file not found error when a nullglob is
> > > > given. This patch inserts /dev/null into the redirection list when
> > > > the
> > > > glob returns empty with no errors.
> > > > Is this a behavior that would interest anyone else? I find myself
> > > > using the `cat /dev/null *(N.)` idiom quite a bit and I thought the
> > > > behavior made sense for the null case in multios.
> > >
> > > This does seem a logical effect, though it ought to be documented.
> >
> > I am not sure if it's that logical.
> > What about if the pipeline on left of the redirection is something
> > expensive?
> > I'd rather have the command fail than starting a long-running job whose
> > output will be lost.
> 
> For the case of expensive pipelines on the left side, running with a global nullglob
> and expecting it to never be null already seems like a risky proposition, and if they
> were using an explicit qualifier, then I think they would have sufficiently acknowledged
> that behavior.

I tend to agree with your analysis here.  Philippe's argument seems to boil down to that
nullglob should somehow behave like not having nullglob in case you don't want nullglob
behaviour?  But maybe others have views.

pws

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

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CGME20191010011901epcas4p3219be0dd0e02bc7168787305e4e1dcf6@epcas4p3.samsung.com>
2019-10-10  1:18 ` [PATCH] respect nullglob given multios Joe Rice
2019-10-10 16:40   ` Peter Stephenson
2019-10-11  0:25     ` Philippe Troin
2019-10-11  6:46       ` Joe Rice
2019-10-11  8:33         ` Peter Stephenson

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


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