Re: cat and pipelines, mostly (was Re: Delete all after a pattern)

[David Wright <deblis@lionunicorn.co.uk>]

On Sat 31 Aug 2019 at 11:19:38 (-0400), Roberto C. Sánchez wrote:
> On Sat, Aug 31, 2019 at 10:02:43AM -0500, David Wright wrote:
> > On Sat 31 Aug 2019 at 10:07:01 (-0400), Roberto C. Sánchez wrote:
> > > On Sat, Aug 31, 2019 at 09:26:49AM -0400, The Wanderer wrote:
> > > 
> > > > It also loses an important benefit when building and tweaking such
> > > > pipelines by hand: convenience of editing. In most shells with which I
> > > > have any experience, command history will place the cursor at the end of
> > > > the remembered line.
> > > > 
> > > 
> > > So, get a better shell?
> > 
> > You're not serious, are you. Learn another shell just to avoid a
> > "useless cat".
> 
> Not sure how you got that.  I clearly meant "get a better shell that
> places your cursor more conveniently."  In a scenario where one is
> tweaking a command, executing, going back to that command in history,
> tweaking again, etc. then a shell that remembers the cursor position
> when the command was executed and places the cursor there when you
> return to that command in history would be "better."

Not in my book, as explained in my other post.

> > So, using my example from earlier, I carefully type this into the
> > command line¹:
> > 
> > $ i=/tmp/sudsa; o=/dev/stdout; (sed 's/ 1/ /g' | tr -d '9') <${i} >${o}
> >  0 1 2 3 4
> > $ 
> > 
> > and then I remember there are a couple of files I'm interested in:
> > 
> > $ i=/tmp/suds?; o=/dev/stdout; (sed 's/ 1/ /g' | tr -d '9') <${i} >${o}
> > bash: ${i}: ambiguous redirect
> > $ 
> > 
> > Oops.
> > 
> > Who wants to have to reorganise the line while you're just doodling
> > about what patterns to use, on which files, and so on, at the command line.
> > 
> I don't follow.  You can't redirect a single file descriptor in from more
> than one file or out to more than one file.  In fact, if you want to
> concatnate the contents of more than one file, you use ... cat.

Exactly; so
    cat afile | some-filter …
is just the degenerate of the general case
    cat somefiles* | some-filter …
where there happens to be only one filename matching somefiles*.
So if you start prototyping some complicated command line by typing
for example:

cat some-directory/… |

you don't have to think about whether said directory might contain a
single file or several, and instead just concentrate on the problem
in hand, after the pipe.

It seems senseless to me to try and write polished scripts every time
you type into the commandline. Not having to is one of the benefits
of interactive interpreters. Anyone remember IBM's JCL?

Cheers,
David.