[Fwd: Re: Send to a Listing]

felixs besteck455 at gmail.com
Mon Apr 15 09:23:29 UTC 2019


Thanks, Cameron. Some coments go in between your comments.

On Mon, Apr 15, 2019 at 05:15:37PM +1000, Cameron Simpson wrote:
> On 15Apr2019 08:52, felixs <besteck455 at gmail.com> wrote:
> > > However, sed can instead accept a list of files on the command line
> 
> Which felixs has tested successfully...
> 
> > > and
> > > it will then read from each in turn, so instead of having the shell
> > > redirect stdin, just put the wildcard path as the trailing argument on
> > > the command line and let the shell expand the wildcard into the list of
> > > individual files:
> > >   sed -ne '/^From: $EMAIL_ADDRESS/p ; /Subject: $SUBJECT/p' path/to/spoolfile/*
> > > 
> > > (The applicable paragraph from the [GNU] sed man page is:
> > >        If no -e, --expression, -f, or --file option is given, then  the first
> > >        non-option  argument  is  taken  as  the  sed script to interpret.  All
> > >        remaining arguments are names of input files; if  no  input files  are
> > >        specified, then the standard input is read.
> > > )
> > > 
> > > 			Nathan
> > 
> > Well, I used the -e option and the first non-option argument is taken as
> > the sed script (on my command line: the regexp), isn't it?. And standard input
> > (redirected to an input path/to/spoolfile/* ) is not read as it (maybe) should.
> 
> If you go:
> 
>  sed ... <path/tospoolfile/*
> 
> and that does not match a _single_ file, then the shell will not do the
> redirection at all (because it can't) and sed doesn't run. This isn't a bug
> in sed or the shell, just that you've asked for something nonsensical.

Well, I simply tried to use the catch-all parameter, which cannot be used
in this case. But it is accepted when having no redirection. That is
what I have learned of it. But there was always ONE match: the one I
searched for using the regexp, knowing beforehand that it's there (in my
example code I actually used no variables but "myemailaddress" and a
"well-known subject line. 
So it seems that it is not that there wasn't any single match. Maybe one can say
that the regexp could not match any message because redirecting input to
a (spool)file directory's files does not work specifying the catch-all
character. Maybe there is a technical reason (beyond the mere statement 
that it is not allowed to invoke bash like that) why you cannot use * with
this kind of redirection.
If I re-read the quote/definition of the bash-hackers-wiki (see one of
the previous mails) I'm not satisfied with the assessment 'invalid invocation'.

> Now, if you _want_ the concatenation of all those files as sed's standard
> into you should first use a command to concatentate their data.  Like "cat".
> Thus:
> 
>  cat path/to/spoolfile/* | sed ...

> Note that for any command where you could just put the filenames as
> arguments to the command without changing the behaviours this is called,
> colloquially, as a "useless cat" - running a cat and the filter flavour of
> the command when the nonfilter flavour would work fine, and a bit faster.

Yes, I noticed when reading several examples in the documentation I use,
that this is a typical command pipe combination: cat ... | sed ... 
Thanks for the "useless cat" term, I hadn't heard of it.

> > Are there any more list members that can confirm that redirecting it in
> > the way I did, does not work/generates an error message?
> 
> The way you did it isn't a legal shell incantation. The problem isn't
> anything to do with sed itself.

The dream of a bash bug report is over. :-)

Cheers,

felixs


More information about the Mutt-users mailing list