On 15Apr2019 08:52, felixs <besteck...@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.
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.
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.
Cheers,
Cameron Simpson <c...@cskk.id.au>
