On 2019-08-31 at 10:07, Roberto C. Sánchez wrote: > On Sat, Aug 31, 2019 at 09:26:49AM -0400, The Wanderer wrote: > >> On 2019-08-31 at 09:02, Roberto C. Sánchez wrote: >> >>> The only time you need to change the syntax is to add something >>> before sed. But then, that's why shells have I/O redirection: >>> >>> (sed 's/config=.*$/config=/g' | tr -d '=') <~/test.txt >>>> ~/other_test.txt >> >> This is *far* more complicated and messy, both syntactically and to >> type in, than just having cat at the beginning of a pipeline. >> > That's quite a stretch. > > Your way: > > cat ~/test.txt | sed 's/config=.*$/config=/g' | tr -d '=' > >~/other_test.txt > > A better way: > > (sed 's/config=.*$/config=/g' | tr -d '=') <~/test.txt > >~/other_test.txt > > The better way is actually simpler. It places all the logic for what > is happening at the start of the line and the I/O redirection (which > is basically just fluff) to the right.
I see that as a negative. The input should come in at one end, and the
output should go out at the other end. That's intuitive.
> Your way requires that I look at it for several moments to separate
> the I/O supporting pieces from the actual interesting command logic.
> The better way has a clean visual separation.
I think this is a case of minds working differently.
>> 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?
I actually think this is good behavior. The only obvious places to put
the cursor when doing command history are at the beginning of the line
and at the end, and for convenience-of-editing purposes, the end seems
obviously preferable to the beginning.
What possible shell behavior would you suggest that might be better in
this regard?
>> The further from the rightmost position the part you want to edit
>> is, the less convenient it is to do that editing, especially when
>> doing multiple trial-and-error passes to figure out what syntax
>> will actually produce the desired result.
>
> Again, it sounds like a better shell is in order.
Again, better how?
>> One item to the right of the final command (either redirection to
>> a file, or pipe to a pager) is usually unavoidable, at least with
>> output of any noticeable size; depending on your shell, there may
>> be keybindings for quick movement along the command line which
>> reduce the inconvenience again.
>>
>
> Here is an alternative that places the interesting commands as far
> to the right as possible:
>
> $ i=~/test.txt; o=~/other_test.txt; (sed 's/config=.*$/config=/g' |
> tr -d '=') <${i} >${o}
<snip>
> That minimizes the distance between the end of the processing
> command pipeline and the end of the line. You can add spaces before
> and/or after ';', '(', and ')' to create more explicit word
> boundaries if you like.
That's not a word boundary for the purposes of the keybindings with
which I'm familiar (and which seem to come enabled by default, at least
with bash; I think they actually come from readline). For that purpose,
only alphanumerics count as part of a word, and only the boundary
between a block of alphanumerics and whitespace counts as the edge of a
word.
That means falling back to one-character-at-a-time cursor positioning,
with the arrow keys, rather than being able to jump around in larger
blocks. Doable, but less convenient than not needing to.
(That syntax is also again more complicated to type than the simple form
I tend to use.)
>> But having to jump back several stages along the command line, and
>> not even to a point which is at the edge of a 'word' according to
>> what (at least) the keybindings I'm familiar with recognize, is IMO
>> not worth the tradeoff vs. saving a single process per invocation.
>
> You'll notice that it's not about saving a process. The better way
> involves a subshell '()' which will create a new process.
You're right, I had missed that.
In that case, I fail to see the benefit. As far as I can tell, saving a
process is the entire sum-total benefit of avoiding the use of cat in
this type of context.
>>> $ cat ~/other_test.txt
>>> Test config
>>> Test config
>>> Test config
>>>
>>> Now I can add pipe stages within the sub-shell to my hearts
>>> content and I can even do other things like replace "<~/test.txt"
>>> with "<$(some other command that queries a database)" so that the
>>> input does not even need to come from a real file.
>>
>> Isn't it just as easy to replace 'cat test.txt |' with 'some other
>> command that queries a database |' ?
>
> It is just as easy. However, 'cat' is not a value-added part of the
> processing pipeline. So, why have it at all?
Because of the value which is lost by avoiding it, which including it
preserves.
That value consists of both the convenience of editing from the end of
the line, and the intuitiveness of having the input come in at the start
and the output go out at the end.
You seem to disagree that the latter is beneficial, or even necessarily
intuitive, so of course you prefer different constructs. There's nothing
wrong with that.
I just get tired of having to explain my own preferred constructs
labelled incorrect and inferior, rather than simply suited for different
interpretations of intuitiveness.
>> And that approach preserves the intuitiveness of having the input
>> be specified at the start of the command line, and the output at
>> the end, instead of the input and the output both being specified
>> at the end.
>
> What is intuitive is not always right or best. It is better to
> properly learn the features and functions of the shell or other
> environment so that proper separation can be made between business
> logic and supporting structures.
What makes it "proper"?
As far as I can tell, it's convenience and intuitiveness which define
"proper" in this context.
> If the command being worked on ends up in a script it is much easier
> to make the better form I suggested readable and maintainable than it
> is with the more 'intuitive' version.
Actually, some parts of my position on this come from work in writing
scripts.
I started out one particular script using a form which avoids the use of
cat, with a multi-stage pipeline split onto multiple lines, so that I
could move lines around conveniently with kill-and-yank (and have the
result show up readably in diffs).
Then I discovered that when I needed to insert a new command at the
beginning of the pipeline, I couldn't just kill-and-yank, I had to also
edit the syntax of the previous first line.
So I inserted a cat invocation as that first line, and thereafter I
could move lines around just as intended, without needing to touch the
first line again.
Again: convenience, just in a different area.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
